FL II

introduction

FL II is a project of simulating NPCs evolution. The project will evolve around the concept of Settlers. The project will have a form of a computer game.

Idea

Any one remembers Settlers II? There you had a map, all made up from linked graph nodes. Each line in a graph had a worker. A little nice blue man, who could carry goods from one node to another only his line. If you had to build woodcuter, so the four planks and 3 stones would have to be travelled through a graph by as many workers, as there are nodes -1. This of course was not the most efficient way (the total length walked by workers was twice bigger than needed) and in settlers IV there was no graph based map. However, the workers still not worked in the most efficient manner. I mean if a house was to be built in 5 seconds, the worker did not take immediately the tool and walked towards the house so he could start working as soon as the house was finished. Insteat, the worker waited till the house was actually read, only then he started his long journey to his job-place.

The very very ground idea of FL II was to advance this still not efficient working style. The idea would satisfactory me, as a development and very rational-based person. When I played civilization (no matter the first one, second or third one), what i liked to do most is to develope the civilization ant not kill others. It is boresome to kill others, and not at all fun. I see no goal in destructive-forms of activities. They are useless, since the desctruction leads to end. The destruction initiates the reverse rotation of a wheel, compared to the ever-rotating circle of creativity (or life, or whatever you name it). The reverse wheel is stopping the evolutionary (or creativy) circle, thus, it is possible that in the best extreme both wheels are stopped. I can not argue 100% that the evolutionary wheel does exist and live on its own and that on the contrary the destruction wheel can only coexist if other wheels a present. I can not guarantee that these charachteristic are true, but if they are, then the conclusion is simple - what is causing the destruction wheel to rotate faster is meant for death at some time. Or simply put - destruction is "bad". chi chi :).

Idea II

So in the previous paragraph i already tapped in the much broader area than only building a clone of Settlers where the workers work in the efficient way. It is much more. I mean. we can make it much more. Or we can limit it.  (It's not up you).

As it is written in the introductin, the game is meant to be of simulating purpose. Relating to wheels of death and creativity - the game can simulate the evolution of these little workers and satisfy us showing how they evolve, in what way , etc. Of course the term evolution here implies the need for term intelligence. Em, probably Artificcial Intellingence (AI).

The heart or the philosophy

So what is the heart of the game? Vertical pigs you say? ( listen how FSOL plays vertical pigs . Read what is a vertical pig ). Ok, lets start not from far flung philosphies, but from real world questions and... eee.. "truths" ;)

1. The perfection is reached when you do not have anything to remove, not when you keep adding things.
   
2. Necessity is the mother of invention. Or simply put - the demand drives the supply.
   Demand must be smart.
3. There is no "good" or "bad" evaluations. There are no marks. There is only evolution in time. Unless we set some objective constrained by time, miliseconds loose any influence.
   When computers get faster and faster, compressing data even with help of individual bits looses its weight. In ten years we will have hard-drives of ten terabytes size, so whats the point of saving data? If hertzes in CPUs are rising if not exponentially, but at least linearly, whats the point of wasting our precious time (we still have a limit of 60 or 100 potatoe years).
   
4. There is single truth.
   One can count how many seeds are in one apple, but now how many apples are in one seed (c) smbdy
   Truth is seed.

The gameplay idea

This is the idea of how everything might possibly one day look like

1. Story The overall gameplay will be a mix of many different sagas. As for the very beginning, the saga will be about something funny and of my own friends, so i can attract at least their attention.
   The saga will be a list of events which must happen for the same storyline as in real life to happen. For example, I can program, so the goal of my character in game will be to get a programming skill and do programming. Then another rule will be for example that if I have a passion for Bjork, i meet another sugar girl, and she also will like Bjork. And so on.
   
2. Many Sagas To have fun, many sagas will be created, and those sagas will not know directly about each other, but if happens, that some things correlate, than a new story will emerge. Maybe fun.
   
3. Unpredictable Environment To have more fun observing sagas, the environment in the game must have influence on the characters. Thus somehow someway global rules must be created, or we could call it "global saga". As the very simpliest rule imagine food. No food - characters die. Simple, and not interesting.
   Imagine another rule - somehow characters develope "awareness" to the level that they can understand that there is now "objective" reality. Or in other way, as far as now I am aware, the reality is directly related to awareness, or to conciousness. So taking this rule, two characters in saga could meet and become friends. But as it is said already in bible, people have free will and at the same time must obey rules.
   So if one character aquires necessary awareness level (through a means which i will describe somewhere later), he does not see conflict in another characters actions, even they might seem contradictive at the first glance. So this effectively becomes a prerequisite for the two friends to actually become friends in the game.
   If the awareness level is not reached, they will strive (since the Saga will instruct them to do so) to "seek" something. They will not know what they seek until they will be triggered and carried onto wider awareness level.
   Confused?
   yes, me too :) But at least it is worth my precious time.
4. Triggers Can you answer this simple question (for example write a mathematical function):
   If you have a candy in your pocket (or a gum, or a cigarette), and you a walking somewhere for some reason, and the wind of gust blows and touched your hair.
   What's the chance that a though will come to your mind and you will think about eating candy, smoking a cigarette or chewing a gum?
   A stupid example, but this might be a trigger for thoughts.
   I do not know what is awareness, but let's try talking about it's manifestations. How to enhance our awareness? To take it simple, knowledge might increase awareness. But is it so? only so? Some scientists could have ten doctor degrees and still not be aware of what is happening around him.
   I do not know the answer, but as we live in a holographic universe , let's assume everythings is somehow connected with everything. (This assumption will give us more possibilities to make fun, than without making this assumption. Is it true or not is your own choice). With this the stupid example with wind makes sense, and the wind mind actually be a trigger.
   So in the game there will be triggers. And triggers will drive characters forward, as the fallen apple drove Newton to write some wise sayings.
   Of course, triggers must have a system. A system. Damn, i do not know for now what and how possibly this system might work. One day.
5. Frequencies and waves Everything is a vibration. Sound is a vibration. Light is a wave. Colour is nothing but a length of a wave.
   What about touching?
   This game is a computer program. And computer was invented by humans. I want to point out that it is not possible to write a computer simulation, where characters will feel everythings as waves and vibrations. But it would make sense.
   Perhaps i have to wait for a few decades, so scientists can understand more reality and develope a little more faster computers.
   Nevertheless, this point should not be overlook.
6. i can decide what i give
   but it's not up to me
   what i get given
   
   Bjork is good.
7. All these accidents that happen
   follow the dot
   coincidence makes sense
   only with you
   you don't have to speak - I feel
   
   Especially will make sense when two not connected sagas will meet :)

Freedom

The project is free

The project mus be free. As Andrius Kulikauskas at the Minciu Sodas (see also Open Leader ) explained to me, if you bring your toys to the sandbox you do not say - "here are my toys and you can play with them only this way and no other way". If you bring your toys, then you let others play with them as they please.
Do not limit.

The project is licenced under the GPL licence from the Free Software Foundation . The writing hereby is covered by GNU Free documentation licence .

Gaming systems to use in project

1. The graphics engine
   Ogre 3D is a good starting point.
2. The scripting system
   Scripting might be made with LUA . There are other projects like Luabind or toLua .
3. Reproducability The kernel of the game (aka gameloop) should exhibit a feature of reproducability.
   Reproducability means that taken the same action sequence the result should be the same on any computer running the same software. Imagine you play some car racing game and you save a replay. Then you go to another computer (or even the same), but the replay shows different things. This is not a difficult thing, though should be kept in mind. read more at gamasutra
4. Artificial Intelligence JOONE Java Object Oriented Neural Engine brings us the ability to build neural networks with synapses and neural network training features in one system.
   Sounds good, eh?
   Generation 5 - Lots of articles.
5. Sound FMOD and Open AL . Or even OpenAL ++
6. GUI (Graphical User Interface) system CEGUI .

Design Ideas

1. Documentation Please refer more to source documentation (generated with Doxygen ) as i am working on project all the time and (at least now), there appears many ground breaking and mind shatter'ing code interface changes.
2. PlugIns Objects are designed in such a way, that in the best case they can be extended (in the sense of functionality served) during runtime. For example a player could switch between object-dragging-mode to flying-with-a-spaceship mode. Probably, in the base case it would be object, which could change it's behaviour without re-materializ'ing itself (i mean without re-creating itself ;) ).
   I have created something similar to a Plug-in system. Yes, it is named "Plug-in", but in fact it is merely a way to structure code. Very similar to microsoft installer packages. The idea is that a plugin, upon install, executes some statements, and upon removal executes some other statements, which probably de-execute what was happening in install. The idea is very blurry at the moment, something is working, but still must be refactores and recoded many many times.
3. MailBoxes
   MailBoxes is a solution for an event system.
   Why? - I needed to have both an immediate and postponed event system.
   Somehow i value a postponed event system. Can not pin-point exactly why, but some of the features are really useful. Imagine a situation where a human has many AI plugins. With postponed event system, it would be easy to say that - do not use more than 10 ms in one second to think. This would be easily achieved by simply fetching events in the next second. Another good point is that the point of fetching an event can be controlled, whereas in immeadiate system the event gets executed exactly at the point it is generated. This might be not what we want, for example if a graphic object generate an event to AI. In this case, it is not as good to execute event in graphic phase as would be in AI phase. I think postponed system will be used mainly as plugins do not need immediate execution.
   Immediate event system , on the other hand, sometimes is a must have. This, for example, is very necessary when a an uninstallation of a plugin occurs. In this case, the dependants must take some immediate actions, or the program might occur in a bad state. Imagine a graphical system get uninstalled but the plugins, who have images made by this system still do not know what catastrophy just happened and still try to draw those pictures. Not good, right?
   How? There is a onw mailbox receiver, which accepts both immediate and postponed events. There will be one special immediate mail message - Check_Your_Mail. Upon receive, the holder of this mailbox will have to check all his not immediate messages, stored in an array.
   The MailDispatcher will be of two tipes - a normal (i.e. the slow, postponed) and MailDispatcherImmediate. The subscriber will subscribe to a MailDispatcher completely not knowing is it immediate or a post-poned mailbox.
   For each event, there will be one event dispatcher (check documentation for *more* details). Each mailbox will be able to subscribe to as many mail dispatcher as one needs, so all events will be sent to one place.
   Mail
   Mail class will have a class Class, which will indiferently identify it. All mails will be subclassed from root Mail class. Based on the mail class, the plugin will be able to down_cast to needed Mail subclass.
4. GameObjects, Plugins and PluginReceivers
   Plugin is a a class with two methods - selfInstall and selfUninstall. In these methods, plugins execute code. Logically, the uninstall method should undo what install method did. Practically, method Install will create one or many instances of GameObject
   PluginReceiver is a class, which hold a list of plugins. This way, the plugins can be logically grouped to form logical entities.
   GameObject is a class which has a reference to a PluginReceiver. GameObject will query plugin receiver for allready installed plugins, and attach to PluginReceiver events system to get notified about the installation/ uninstallation of the plugins it depends on.
   

Development Roadmap

1. Resolve Opal physics bug
   Somehow the dimensions of opal body and the draw on the screen body do not match
   started
2. Integrate Opal and OpenSteer to work together
   Opal and OpenSteer uses independent coordinate systems, so create a controller to integrate both.
   started
3. Mail-boxes and related interface braking changes
   
   under-heavy-development
4. "Advanced" movement of ships and cars - collision
   OpenSteer library needs a different approach to collision than that used in Opal library. Collision will have to be implemented in terms of SphericalObstacles using arrays or some spatial database. Kad tave kur šimtakojis nuneštu!
   not started
5. 
   
   
6. 
   
   

Download

After MailBoxes are finished and i sit back again to code plugins, and not the system upon which plugins work ;)
The project is not meant to be done in any specific time. The projects is meant to be evolved and nourished until it is worth to. I am working alone. Ideas, help, anything - please mail.