Farm (FirstThought Advanced Reality Machine)

Speaking about interactive contents development, many strategies are possible. You can go from “low-level” development using some real programming language like Visual Basic or C++ and powerful multimedia libraries, up to development with specific software packages called “authoring systems”. All of these ways has advantages and trade-offs, which can be seen as the result of  proportionality between complexity and time to develop. Basically, you can do anything in a long time using “real” programming, and somewhat less than anything in a shorter time using authoring systems. In a field like VR, or “highly interactive three-dimensional real-time” applications like nowadays console games, the complexity can be very high. Also, the development cycle is very prone to changes, because of the somewhat “artistic” nature of good games, so it must be easy to experiment new ideas. Unless you have unlimited financial resources so that you can hire as many “low-level” skilled programmers as you like and have them change their code a lot of times, you must use some high level authoring system.

Farm is an authoring system born with these basic ideas:

1)	Handle all “artistic” development somewhere out. Graphics, sounds and so on can be seen as “resources” or “assets” of the game/application, and all is done with external, third-party programs.
2)	Concentrate upon interactions. Farm is a tool to give behaviors to resources and to coordinate them. The idea is to turn “resources” into “actors” and give them “behaviors”.
3)	Recycle. Farm itself is a non-portable Windows application developed using Win32/DirectX, but is built upon a pure C++ library which encapsulate all the aspects of typical realtime 3D games (collision detection and response etc). In this way, Farm is used to prototype and develop in a very easy and interactive way your application, which is then monolithically exported toward some platform-specific “loaders” which are a port of the core library plus some operative-system-dependant bindings (typically, graphics sub-system) on the target machine.
4)	Let everybody change his or her mind. Many times you do something and then realize that you do not like it, or that it could be done in a more effective way etc. Farm does not keep you from having this kind of approach.
5)	Promote group work. Farm easily integrates different scenarios developed separately.
6)	Do not rely too much on technical knowledge of programmers. Farm will have a script language and a logical behaviors programming environment, which is much easier to use than C++. Is easier and less expensive to instruct junior programmers than to find good “low-level” (typically C++) programmers.

Why develop Farm? Is it not a too-complex work?

1)	Farm enables you to change graphics and behaviors in an independent fashion. The “artistic” and “programming” teams does not need to wait for each other to test their changes, opposed to situations where you have at least to recompile everything. This decoupling itself is important enough to pay for Farm extra time development. 
2)	Farm is easy to use. Non programmers (artists) can prototype easy interactions, so that they have some “look and feel” before the programmers start to develop the more complex “core” interactions.
3)	75% of Farm must anyway be developed for a game. Collision Detection and Response, Dynamics Engine, a mechanism for message passing between characters etc is anyway needed. In Farm, all of this is made in C++ and can be recycled. What Farm has more than a game is some user interface and editing abilities, which are encapsulated in the huge and well-known Microsoft Foundation Classes library.
4)	Development tools are very advanced on PCs. This is very good for debugging the core library. Also, you can add “debug” capabilities to Farm itself, enabling you to trace behaviors and characters of your application. This is unneeded in the release version of the game and then can be removed before exporting the game on the target loader (or you just instruct the loader to ignore the extra info).
5)	To run Farm you just need an ordinary PC, not a target machine. You can start develop your new game without your new hardware. You just know that you will need to port a small universal loader on your target machine, so that becomes a somewhat “secondary” and absolutely decoupled problem.
6)	A lot of already-done work can be found on the Net. Very good C++ source code libraries for many aspects of Farm development are public domain.

Bottom line: you can see Farm as a universal game editor. It is obviously less powerful than writing directly in C++ your game, but trading this sky-high complexity and power of pure C++ programming with much faster development times, you are free to experiment and optimize your application in a way otherwise impossible.

Why not use something similar out-of-the-box? Are there authoring systems similar to Farm?

1)	Yes, there are. But they cost a lot and bound yourself with royalties upon loaders (Motion Factory Motivate/Superscape), they tend to be  bugged and monolithic (Superscape), they are not powerful enough for real stand-alone game development (a lot of them are based upon Java/VRML, which is slow and Internet-targeted), and they are not portable.
2)	By writing it yourself, you owe nothing to anybody. If you find a bug, you can fix it. You can move development toward areas you believe interesting. You have the rights do give away the loaders. You can sell Farm itself.

So, why nobody wrote Farm before than First Thought? 

1)	I don’t know. Sure, it is not so easy; you need deep knowledge of what is needed to create virtual environments, and good ideas about how to implement everything in a easy-understandable way. The main goal of Farm is exactly this: have a program that (at least at his basic level) is so easy to use that even a non-programmer will be able to create interesting contents.
2)	Because we are much smarter and faster than everybody else, including Autodesk, Microsoft etc etc.

The Farm Crew