The Unofficial Four Elements Contest ("UFEC") brought me out of hibernation, and has inspired me to put together a casual game.
Here are the specs, thus far:
Title: Thaw
Platforms: PC/Mac/Linux
Technology: Adobe Flash
Requirements: Flash Player 10, for web release version.
Genre: Simulation/Strategy
Type: 2d/top down
Players: 1
Story (at the moment):
You have been awakened from cryo after a cold snap which left the planet encased in ice for a great many years. Using what is left of your technology, you need to start seeding the planet with the basic necessities to re-start the global ecology, starting with the simplest of plants and working up to a self-sustaining biosphere which can support humans. Along the way you need to establish local ecologies which can flourish in a post ice age/apocalypse environment. This includes specifics like creating energy sources, melting through the ice, discovering caches of seeds and DNA remnants, engineering new species for the new climate, and finding out why things ar eso much worse than the Powers That Be expected them to be when they put you in the freezer.
I am still working out the fine points of this. I want it to be story driven as much as it is even driven, with the plot unfolding as the player makes decisions and begins to alter the environment. It might be much too big a game for a five month contest, but with appropriate use of procedurally- and user- generated content, I should be able to get something done.
This will be the third Four Elements competition for which I have started a game. I will be taking ideas from those projects, plus myriad code snippets from several years of experiments and projects, and see if I can get something together by the end of March which people will want to play.
My first step - and the only one, so far - is to set up a structure which keeps the event listeners to an absolute minimum, so I can eliminate the possibility of conflicts before the first screen is created. To that end, I have created two simple delegation methods - one which listens for timer updates and the other which listens for keyboard input. These functions receive the events, figure out the current state of the game, and forward the event to the appropriate manager. Code is here:
private function mainLoop(e:TimerEvent):void { switch(GAME_STATE) { case "travel": worldManager.update(); break; case "manage": technologyManager.update(); break; case "fight": combatManager.update(); break; case "dialogue": storyManager.update(); break; default: break; } e.updateAfterEvent();}private function onKeyEvent(e:KeyboardEvent):void { switch(GAME_STATE) { case "travel": worldManager.receiveKeyboardEvent(e); break; case "manage": technologyManager.receiveKeyboardEvent(e); break; case "fight": combatManager.receiveKeyboardEvent(e); break; case "dialogue": storyManager.receiveKeyboardEvent(e); break; default: break; }}With that simple structure in place, I don't have to worry about different parts of the game falling out of synch, or constantly turning listeners on and off in different parts of the game, depending on what the user is doing at any given moment. It is easy to expand this system as the game becomes more complex, and debugging is greatly simplified. Also, it requires a lot less code.
One caveat: I have not actually built a system like this before, so I don't know if there are any hidden traps in this approach. Time will tell.
I occasionally post screen shots in the UFEC screenshot thread, and will post updates to the progress of the game itself in its own thread. More development-specific updates will be posted here.
Well, heck. I will probably just post everything here.
