| Friday, November 20, 2009 |
 Declarative Declarations |
Posted - 11/20/2009 9:32:22 AM | I haven't had much time to code this past week, but I have thought quite a bit about how the different parts of the game will fir together. Right now I am sorting out the logic of re-creating a biosphere from scratch, and how the elements of propagation and evolution will fit in. Research has led me in some interesting directions; I picked up a college text-book on botany, and spent a good long time browsing Wikipedia, specifically looking at Ecological Succession. I also grabbed a book called Where Our Food Comes From: Retracing Nikolay Vavilov's Quest to End Famine. Put together, these sources prompted me to change the focus of my game, from re-starting a global ecology, to something much more local - create a regional ecosystem, over the course of some decades or centuries, which will ultimately be (a) self-sustaining, and (b) be able to support a population of recently-thawed humans. Yeah, the basic story/plot is kind of weak at the moment, but the technical issues with putting such a game together are quite interesting.
Because I have no experience in ecology, biology or botany, I found myself at a loss as to where to begin. So I have started an exercise which has previously helped me make sense of information architecture problems: make a long list of simple, declarative statements, then order them, add to them, and flesh them out, until I have a design document. Here is my "ecology" list at the moment:
- All plants require sunlight.
- All plants more complex than algae require a solid surface for growing
- All plants have chlorophyll, which reacts with sunlight to create nutrients
- Algae scattered on ice will trap sunlight, and heat up enough to melt ice
- Lichen can grow on bare rock
- Moss can grow on bare rock and in minimal soil
- Plants growing on bare rock will begin to erode the rock, creating sand.
- When plants die, they mix with the sand to create soil
- The more complex the plant, the more nutrients it needs to grow
- The larger the plant, the stronger its root system needs to be.
- Taller plants need deeper roots.
- The more surface area a plant has, the more sunlight it collects.
- More leaves mean the plant needs to be either wider or taller
- Faster growth means faster propagation
- Faster growth means shorter life
- Faster growth means more fragile plant
- Plants can propagate by water, wind, or mechanical means
- Plants which propagate by water can only propagate downstream
- Plants which propagate by air can only propagate in the direction of the wind
- Plants which propagate by air can disperse to a wider area
- Plants which propagate by water propagate more densely in any given area
- Fitness is the likelihood that an individual will produce viable offspring
- Plants need to reach a certain maturity before they can reproduce
- Plant populations need to reach a certain density before they can effectively propagate
- plants need to reach a level of complexity where they create fruit before they can be considered food plants
- plants which contain sufficient nutrients to be worthwhile as food must get nutrients from the soil
Obviously this list is simplified to meet the needs of the game. I am sure any botanists reading this are shaking their heads.
Anyway, I consider it a good start. More updates to follow.
| |
| Tuesday, November 10, 2009 |
 4e7-ish, or UFEC! |
Posted - 11/10/2009 10:14:12 AM | Wow, has it been a long time since I posted here.
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.
| |
|
| S | M | T | W | T | F | S | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
OPTIONS
Track this Journal
ARCHIVES
November, 2009
March, 2009
January, 2009
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
February, 2008
December, 2007
November, 2007
October, 2007
September, 2007
July, 2007
June, 2007
March, 2007
February, 2007
January, 2007
December, 2006
August, 2006
July, 2006
June, 2006
|