Off to Eureka, MT for a short vacation. Perhaps some genius will strike me while there?
See you next week!
Thursday, June 30, 2011
Monday, June 27, 2011
Player Inventory, Hypothermia, and More!
Player Inventory
I finally started tackling one of the systems I was dreading: Player Inventory. It's a system I'm anxious to play with in-game, but it requires so many subsystems to be in place that it was a bit daunting to start developing. But in the spirit of Agile Project Management, I decided to tackle the big risk right now. It's one of the more crucial gameplay mechanics, so it makes sense to deal with it sooner than later.
So far, the player is able to enter the inventory screen by pressing "I." While it shares some traditional RPG behavior, I do deviate a little from the norm. In it, the player is presented with a list of categories such as "left hand," "right hand," "back," and "torso." Each of these represents a place to carry or equip stuff. Here's a peek:
In this screenshot, the left side shows the item in the player's left hand. The right side shows the item on the player's torso. In this case, we see the player is holding a can of soup, and wearing a t-shirt. The center shows a list of other areas that can have items equipped. The player can change the left or right display areas to show any of the categories by clicking the appropriate arrow alongside each category. Yellow arrows show the currently selected category for each side.
I haven't yet added it, but the bottom of each side of the screen is meant to show available storage space in the object depicted at the top. For example, the shirt may have pockets, which would show up as an empty set of boxes below the t-shirt image. If the pockets had anything in them, they would appear in the boxes below the t-shirt.
Once this system is complete, the player would be able to drag items from one side to the other. In this case, perhaps the player wanted to free up his left hand, so they could drag the soup can from the hand into the (not yet depicted) pocket space below the shirt. A more traditional example might be to equip a backpack in the "Back" category, and store lots of stuff in the ample space it has. And to equip an object, the player would drag an item from one side into the "socket" of an empty category.
Right now, we only see parts of the body in the list of categories. But I would also like to include an "On the Ground" option, which allows the player to drop and pick up items in the current hex. I will probably also dynamically add a "Trader" category when the player is bartering with an NPC. Crafting may also factor into this UI, but I'd like to get it inserted into the gameplay loop and tested before I build much more into it.
Will this be intuitive, or will people hit it like a brick wall? That's the question I'd like to answer through testing before settling on this approach.
Class Naming Tidiness and FlashDevelop Refactor
As the project grows more complex, class names are starting to become an issue. I'm already starting to think some class names are going to need rewriting, or perhaps even grouping and subfolders. Things like my GUI-related classes seem like a logical set to group either in a folder or with a "GUI" prefix.
I haven't sweated it yet, as the classes are still few enough to keep track of, and I thought it'd be a cinch to just refactor the class names in FlashDevelop. That stopped being true Friday, when I tried to refactor a classname due to a class's change in purpose. Turns out, FlashDevelop doesn't yet (v3.3.4) support class refactoring. It's slated for the next release, but that was a bit of a shock. It's probably not a huge deal, as search and replace should probably cover it. Still, I was surprised to discover that feature missing.
Hypothermia and Hyperthermia
NEO Scavenger now supports hypothermia and hyperthermia (heat exhaustion). The player has a normal range of temperatures wherein they maintain a healthy core temperature without clothes. If the player is in a temperature cooler than that range, their core temperature starts to drop, until symptoms of hypothermia start to appear, and eventual death by freezing. Similarly, above that temperature range, heat exhaustion, stroke, and eventually organ failure, occur.
It's not terribly sophisticated yet, as the symptoms are primarily descriptive. However, the really severe cases do cause a reduction in movement rate. And player conditions are built to support penalties to any player attribute down the road.
Clothing
I also added rudimentary clothing to the game. The player can endure wider (or shifted) temperature ranges depending on which clothing is equipped, and each clothing item also changes the rate of core temperature loss/gain when outside that range. So far, my limited testing of a t-shirt-wearing player in winter and summer seem to work. As this ties into the inventory system above, full testing will have to wait until they're both working in concert.
FlxGroup Revive Override
One minor task I tackled was overriding the revive() method on FlxGroup in flixel. As of the May 20, 2011 revision, FlxGroup's revive() defaulted to FlxBasic, and would therefore skip all member sprites that were added to it. Since some of my GUIs use the FlxGroup and need to switch on and off, I added an overridden revive() which behaves a lot like the override for kill().
I only mention this in case any other flixel devs are out there and plan to use kill/revive on groups.
Webserver SVN
Finally, I've used SVN to check-out php and image files into my localhost's webserver. Until now, I had been using the old copy+paste after each edit to update my webserver. But with SVN, that was made easier via check-out.
I finally started tackling one of the systems I was dreading: Player Inventory. It's a system I'm anxious to play with in-game, but it requires so many subsystems to be in place that it was a bit daunting to start developing. But in the spirit of Agile Project Management, I decided to tackle the big risk right now. It's one of the more crucial gameplay mechanics, so it makes sense to deal with it sooner than later.
So far, the player is able to enter the inventory screen by pressing "I." While it shares some traditional RPG behavior, I do deviate a little from the norm. In it, the player is presented with a list of categories such as "left hand," "right hand," "back," and "torso." Each of these represents a place to carry or equip stuff. Here's a peek:
 |
| Player Inventory showing the contents of their left hand and torso slots. |
I haven't yet added it, but the bottom of each side of the screen is meant to show available storage space in the object depicted at the top. For example, the shirt may have pockets, which would show up as an empty set of boxes below the t-shirt image. If the pockets had anything in them, they would appear in the boxes below the t-shirt.
Once this system is complete, the player would be able to drag items from one side to the other. In this case, perhaps the player wanted to free up his left hand, so they could drag the soup can from the hand into the (not yet depicted) pocket space below the shirt. A more traditional example might be to equip a backpack in the "Back" category, and store lots of stuff in the ample space it has. And to equip an object, the player would drag an item from one side into the "socket" of an empty category.
 |
| Here, the right foot has nothing equipped yet. |
Right now, we only see parts of the body in the list of categories. But I would also like to include an "On the Ground" option, which allows the player to drop and pick up items in the current hex. I will probably also dynamically add a "Trader" category when the player is bartering with an NPC. Crafting may also factor into this UI, but I'd like to get it inserted into the gameplay loop and tested before I build much more into it.
Will this be intuitive, or will people hit it like a brick wall? That's the question I'd like to answer through testing before settling on this approach.
Class Naming Tidiness and FlashDevelop Refactor
As the project grows more complex, class names are starting to become an issue. I'm already starting to think some class names are going to need rewriting, or perhaps even grouping and subfolders. Things like my GUI-related classes seem like a logical set to group either in a folder or with a "GUI" prefix.
I haven't sweated it yet, as the classes are still few enough to keep track of, and I thought it'd be a cinch to just refactor the class names in FlashDevelop. That stopped being true Friday, when I tried to refactor a classname due to a class's change in purpose. Turns out, FlashDevelop doesn't yet (v3.3.4) support class refactoring. It's slated for the next release, but that was a bit of a shock. It's probably not a huge deal, as search and replace should probably cover it. Still, I was surprised to discover that feature missing.
Hypothermia and Hyperthermia
NEO Scavenger now supports hypothermia and hyperthermia (heat exhaustion). The player has a normal range of temperatures wherein they maintain a healthy core temperature without clothes. If the player is in a temperature cooler than that range, their core temperature starts to drop, until symptoms of hypothermia start to appear, and eventual death by freezing. Similarly, above that temperature range, heat exhaustion, stroke, and eventually organ failure, occur.
It's not terribly sophisticated yet, as the symptoms are primarily descriptive. However, the really severe cases do cause a reduction in movement rate. And player conditions are built to support penalties to any player attribute down the road.
Clothing
I also added rudimentary clothing to the game. The player can endure wider (or shifted) temperature ranges depending on which clothing is equipped, and each clothing item also changes the rate of core temperature loss/gain when outside that range. So far, my limited testing of a t-shirt-wearing player in winter and summer seem to work. As this ties into the inventory system above, full testing will have to wait until they're both working in concert.
FlxGroup Revive Override
One minor task I tackled was overriding the revive() method on FlxGroup in flixel. As of the May 20, 2011 revision, FlxGroup's revive() defaulted to FlxBasic, and would therefore skip all member sprites that were added to it. Since some of my GUIs use the FlxGroup and need to switch on and off, I added an overridden revive() which behaves a lot like the override for kill().
I only mention this in case any other flixel devs are out there and plan to use kill/revive on groups.
Webserver SVN
Finally, I've used SVN to check-out php and image files into my localhost's webserver. Until now, I had been using the old copy+paste after each edit to update my webserver. But with SVN, that was made easier via check-out.
Tuesday, June 21, 2011
Back in the Saddle Again
Porting to flixel: Complete
It's been almost a week since adopting flixel, but it's paying off. It took only a day or two to convert most code to flixel-friendly FlxSprites and FlxGroups, and it was a huge win already. Adopting flixel meant I had a game state structure already built, as well as many helpful functions for input handling, graphics, and audio. The one shortcoming was the hexmap. flixel supports square-grid tilemaps out of the box. But hex grids are another story.
After trying to make a hexmap out of multi-layered FlxSprites/FlxGroups, and seeing the resulting framerate drop, I decided to try my hand at extending flixel's tilemap classes to support a hex grid. That was a few days in itself, but the results are astounding. Performance is back up to 30 solid fps, regardless of scrolling or any other activity. I had to make a few architectural changes to the hexes, including pre-baking the graphics for each state, rather than layering dimmed and blacked-out states overtop. That approach is probably more sensible, though. It makes sense to do the (already minimal) graphics lifting up front, and save the processor time for things the artist can't do.
With that in place, I'm back to adding features from the backlog. Only much faster now!
Player Status
As described in earlier posts, part of the game involves surviving in the post-apocalyptic wilderness with nothing but raw character abilities, scavenged items, and the player's wits. With map navigation, visibility, and weather in place, it seems like a good time to add one of the game's obstacles/antagonists: metabolism.
The player now has hunger and sleep status fields. Each time a turn ends, time advances a few hours, and the player's character gets hungrier and more tired. Hunger gives way to weakness, and if unchecked long enough, the player can now die.
Sleep is also going to be important, but for now, is a text-based descriptor-only. These two conditions are the first in a series of conditions, including exposure and disease, which the player must monitor and address to stay alive.
Item Database Prototyped
As part of the above player status work, I also prototyped an item database so I could test food items. Right now, the database is little more than an item table with an entry in it flagged as food category. If the player has an item in their inventory that corresponds to the food category, they eat it at the end of their turn if they are hungry or worse. The food item's mass is used to calculate how much hunger is satisfied, the item is removed, and the player's hunger status is updated for the next turn.
As part of this item database prototype, I've also created several fields to address the crafting component of the game, to be built later. Items have properties such as group info, for use in algorithms like the food check above, as well as for use in crafting substitutions. Items also have weight and volume information, for the inventory management activity mentioned in the design doc. Finally, items have properties which help describe the durability of each item. Some of these are related to crafting, as durability may suffer if the crafter uses poor substitutions. Others are part of a nice-to-have feature list, which includes items perishing in heat, freezing in the cold, or being affected by water (heavier to carry, reduces body heat, etc.).
New Hex Art
One nice thing about being a jack-of-all-trades solo dev is that one can switch to a completely different discipline for a break, and still be productive. After days spent monkeying around in flixel's guts, I needed a breather from code. So I picked up my Wacom stylus, and tried my hand at pixel art.
Up until now, my hexes have been top-down, in a simple two-tone line-art style. Much like the old wargaming and TSR Greyhawk maps. However, I've seen some really nice pixel art hexes out there, particularly the isometric ones, and I wondered if I should go that route. Here's what I came up with:
Upon first glance, it's not quite the effect I was hoping for. Ignoring the out-of-date highlight and person graphics, the hexes look too muddled, and possibly too big. Both the Uniwar and Greyhawk hexes linked above seem more deliberate, beefy, and satisfying. So next revision may be scaled down a bit. And possibly more cartoonish.
The isometric effect is nice, though. I kinda like the way the hex art overlaps. It might end up being more headache than it's worth, in the end, but it warrants some more tinkering.
SVN
I finally started using version control today. In the past, the project was simple enough to just periodically copy into a backup folder. But it's quickly growing branches with vastly different code (flixel vs. no, iso hex art vs. top-down), and I'm not far from losing track of which version is where. Not to mention, I'm getting more fearful of major code revisions each time, in case I need to revert.
So enough of that. SVN it is. FlashDevelop integrates with it easily, and it's free, so no excuses!
Whew! That's a whole morning spent documenting/blogging, and setting up SVN branches. There's still a few hours left, so let's see if we can get some more work done. Cold weather exposure is probably next, maybe heat exhaustion, and adding movement penalties for said conditions. I may also have to tackle basic inventory soon.
It's been almost a week since adopting flixel, but it's paying off. It took only a day or two to convert most code to flixel-friendly FlxSprites and FlxGroups, and it was a huge win already. Adopting flixel meant I had a game state structure already built, as well as many helpful functions for input handling, graphics, and audio. The one shortcoming was the hexmap. flixel supports square-grid tilemaps out of the box. But hex grids are another story.
After trying to make a hexmap out of multi-layered FlxSprites/FlxGroups, and seeing the resulting framerate drop, I decided to try my hand at extending flixel's tilemap classes to support a hex grid. That was a few days in itself, but the results are astounding. Performance is back up to 30 solid fps, regardless of scrolling or any other activity. I had to make a few architectural changes to the hexes, including pre-baking the graphics for each state, rather than layering dimmed and blacked-out states overtop. That approach is probably more sensible, though. It makes sense to do the (already minimal) graphics lifting up front, and save the processor time for things the artist can't do.
With that in place, I'm back to adding features from the backlog. Only much faster now!
Player Status
As described in earlier posts, part of the game involves surviving in the post-apocalyptic wilderness with nothing but raw character abilities, scavenged items, and the player's wits. With map navigation, visibility, and weather in place, it seems like a good time to add one of the game's obstacles/antagonists: metabolism.
The player now has hunger and sleep status fields. Each time a turn ends, time advances a few hours, and the player's character gets hungrier and more tired. Hunger gives way to weakness, and if unchecked long enough, the player can now die.
 |
| Game Over - Player died of: Starvation |
Sleep is also going to be important, but for now, is a text-based descriptor-only. These two conditions are the first in a series of conditions, including exposure and disease, which the player must monitor and address to stay alive.
Item Database Prototyped
As part of the above player status work, I also prototyped an item database so I could test food items. Right now, the database is little more than an item table with an entry in it flagged as food category. If the player has an item in their inventory that corresponds to the food category, they eat it at the end of their turn if they are hungry or worse. The food item's mass is used to calculate how much hunger is satisfied, the item is removed, and the player's hunger status is updated for the next turn.
As part of this item database prototype, I've also created several fields to address the crafting component of the game, to be built later. Items have properties such as group info, for use in algorithms like the food check above, as well as for use in crafting substitutions. Items also have weight and volume information, for the inventory management activity mentioned in the design doc. Finally, items have properties which help describe the durability of each item. Some of these are related to crafting, as durability may suffer if the crafter uses poor substitutions. Others are part of a nice-to-have feature list, which includes items perishing in heat, freezing in the cold, or being affected by water (heavier to carry, reduces body heat, etc.).
New Hex Art
One nice thing about being a jack-of-all-trades solo dev is that one can switch to a completely different discipline for a break, and still be productive. After days spent monkeying around in flixel's guts, I needed a breather from code. So I picked up my Wacom stylus, and tried my hand at pixel art.
Up until now, my hexes have been top-down, in a simple two-tone line-art style. Much like the old wargaming and TSR Greyhawk maps. However, I've seen some really nice pixel art hexes out there, particularly the isometric ones, and I wondered if I should go that route. Here's what I came up with:
Upon first glance, it's not quite the effect I was hoping for. Ignoring the out-of-date highlight and person graphics, the hexes look too muddled, and possibly too big. Both the Uniwar and Greyhawk hexes linked above seem more deliberate, beefy, and satisfying. So next revision may be scaled down a bit. And possibly more cartoonish.
The isometric effect is nice, though. I kinda like the way the hex art overlaps. It might end up being more headache than it's worth, in the end, but it warrants some more tinkering.
SVN
I finally started using version control today. In the past, the project was simple enough to just periodically copy into a backup folder. But it's quickly growing branches with vastly different code (flixel vs. no, iso hex art vs. top-down), and I'm not far from losing track of which version is where. Not to mention, I'm getting more fearful of major code revisions each time, in case I need to revert.
So enough of that. SVN it is. FlashDevelop integrates with it easily, and it's free, so no excuses!
Whew! That's a whole morning spent documenting/blogging, and setting up SVN branches. There's still a few hours left, so let's see if we can get some more work done. Cold weather exposure is probably next, maybe heat exhaustion, and adding movement penalties for said conditions. I may also have to tackle basic inventory soon.
Thursday, June 16, 2011
Phil, Henry, I believe I owe each of you a beer
Beer #1: FlashDevelop
First of all, to Phil, for tipping me off about FlashDevelop. After using CS4's IDE for a few generations, FD is a serious breath of fresh air. Code completion, context tool-tips, actual real-time debugging and watching of variables...it's like AS3 grew out of it's awkward high school living arrangement in CS IDE's basement, got a job, and moved into a swanky flat. I haven't even cracked some of the auxiliary features such as tasks/todo, refactoring, and source-control. It's just flat-out awesome, and I think my development is going to kick into high gear as a result. Thanks Phil!
Beer #2: flixel
And to Henry, a beer for recommending flixel. Right off the bat, flixel showed itself to be so much of what a new game needs to get off the ground quickly. Built-in libraries for sprite blitting, tilemaps, game objects, game states, on-screen text, button handling, physics, audio, you name it. It's a fantastic package to work with, and I've used a lot of game libraries, from Allegro back in the day, to Torque, Axiom, XNA, and Ogre.
The real question was, would it work as NEO Scavenger's top-down, hex-map-based engine? I was dubious for the first two days. Trying to make the map myself, using FlxGroups and FlxSprites, produced performance below that of vanilla Flash. However, yesterday, I think I achieved a breakthrough. After subclassing FlxTilemap and family to support hex-based maps, performance improved drastically. I still have some work to do, before it completely replicates the map functionality I had before, but it's looking promising.
Regardless of how that turns out, flixel will at least be extremely valuable in some future games I've jotted down in my backlog, so thanks Henry!
In Other News
Indie life in the mountains continues to go well. I've been chugging away with my aforementioned two new favorite tools. I get the occasional rainstorm, bird calls, or coyote howl to add to my audio library. I've started some work on a new style of hex art I want to try. And I even got some hands-on time with my PC's guts, replacing a dying exhaust fan. Good times!
First of all, to Phil, for tipping me off about FlashDevelop. After using CS4's IDE for a few generations, FD is a serious breath of fresh air. Code completion, context tool-tips, actual real-time debugging and watching of variables...it's like AS3 grew out of it's awkward high school living arrangement in CS IDE's basement, got a job, and moved into a swanky flat. I haven't even cracked some of the auxiliary features such as tasks/todo, refactoring, and source-control. It's just flat-out awesome, and I think my development is going to kick into high gear as a result. Thanks Phil!
Beer #2: flixel
And to Henry, a beer for recommending flixel. Right off the bat, flixel showed itself to be so much of what a new game needs to get off the ground quickly. Built-in libraries for sprite blitting, tilemaps, game objects, game states, on-screen text, button handling, physics, audio, you name it. It's a fantastic package to work with, and I've used a lot of game libraries, from Allegro back in the day, to Torque, Axiom, XNA, and Ogre.
The real question was, would it work as NEO Scavenger's top-down, hex-map-based engine? I was dubious for the first two days. Trying to make the map myself, using FlxGroups and FlxSprites, produced performance below that of vanilla Flash. However, yesterday, I think I achieved a breakthrough. After subclassing FlxTilemap and family to support hex-based maps, performance improved drastically. I still have some work to do, before it completely replicates the map functionality I had before, but it's looking promising.
Regardless of how that turns out, flixel will at least be extremely valuable in some future games I've jotted down in my backlog, so thanks Henry!
In Other News
Indie life in the mountains continues to go well. I've been chugging away with my aforementioned two new favorite tools. I get the occasional rainstorm, bird calls, or coyote howl to add to my audio library. I've started some work on a new style of hex art I want to try. And I even got some hands-on time with my PC's guts, replacing a dying exhaust fan. Good times!
Friday, June 10, 2011
Game Design Document
As promised, I've spent some time working on a human-consumable design document for my game. Up until now, I've had a pile of Google documents and text files that provided a nearly complete picture of what I was building, but I'm not sure anyone would've made sense of it without some guidance.
What follows, then, is a sort of high-level summary of the major ideas for the game. It leans heavily towards gameplay rather than setting and plot, since I want to get that prototyped and start playtesting it before hanging too much set dressing on it. I have a lot of ideas cooked up for setting and plot too, but how that takes shape will depend on how the game plays.
So without further adieu, I present draft one of my game design, working title NEO Scavenger.
NEO Scavenger Design Document
Gameplay Activities
N.E.O. Scavenger is a game composed of five Gameplay Activities: Exploration, Inventory Management, Crafting, Solving Encounters, and Character Development. The player practices each of the above activities in the Game World until an Endgame State is reached.
Exploration
Exploration works like the Civilization V early game/exploration phase. Players navigate a hex-based map of variable terrain types in a turn-based fashion. Each hex has a movement cost, and the player has a limited number of moves per turn. Unexplored areas are obscured by a fog of war, and the player reveals new hexes as they move, depending on vision range, elevation, and line of sight. Each turn causes time to pass in the game world, advancing various conditions such as player hunger, thirst, chance of random Encounter, fatigue, exposure to the elements, diseases, and injuries.
Inventory Management
Inventory Management is the process of deciding which loot is worth taking, and finding/making space for it in the player’s inventory. It behaves like the looting in games such as Silent Storm or S.T.A.L.K.E.R. Efficiently packing loot, in particular, feels a lot like Tetris.
Loot value is subjective, and depends on the player’s situation. Loot can be valuable due to immediate usefulness, as with binoculars. It can also be valuable due to indirect usefulness, such as an axe handle which can be later used to craft an axe. Finally, it could be valuable later in Solving Encounters, or as currency.
The amount of loot a player can carry is limited by both space and weight. Space is handled via a grid system, and each item requires a certain number of grid squares. In order to be carried, an item must fully fit into the available space, and must not increase the weight carried by the player beyond the player’s carrying capacity. If there is not enough space or carrying capacity, the loot must either be left behind, or else something in the player’s inventory discarded to make space.
Crafting
Crafting works in a manner similar to Minecraft, where the player can combine various items they've collected to create other items. Items can be crafted by fulfilling recipes, which are combinations of the correct skills, abilities, and requisite material components. Recipes must be discovered by the player either via Encounters, or trial and error. Unlike Minecraft, the components will likely not need to be arranged in specific visual patterns to create objects.
Recipes will support substitutions, so that items, skills, or abilities with similar properties can be used as substitutes to create the same item. Items will support quality levels, dependent on the substitutions used, and these quality levels will affect item longevity and/or effectiveness.
Solving Encounters
Solving Encounters is a creative problem solving activity. It consists of the player being notified of an Encounter, after which the player must select a Response composed of character skills, abilities, and equipment to deal with the Encounter. The Response combined with the Encounter produces a Result, which can be a change to the game world or the player. Encounters can include people, places, and things. Encounters can also include situations, which might be conditions in the game world (e.g. snowfall) or in the player (e.g. hunger). Results are predetermined by the game designer, and encounters can have many valid Responses and Results.
For example, an Encounter might say “A lone figure approaches in the distance, but does not see you yet.” One valid Response is to choose the character’s “hiding” skill, combined with a “camouflaged blanket” from their inventory. The Result would say something like “You dash from the road and hide in the trees. The figure passes, oblivious to your presence.” If the player had included both “hiding” and the “blanket” from above, as well as “binoculars” from their inventory, they would see “You dash from the road and hide in the trees. The figure passes, oblivious to your presence. Through careful observation, you notice he is carrying the following items: spear, boots, cloak, satchel.”
Character Development
Character Development consists of creating the player’s character, and growing that character over time through Gameplay. When starting a game, the player may opt to customize which skills and abilities their character has, or choose a default character. Skills include proficiencies such as hiding, lockpicking, computers, and navigation, while abilities might include night vision, technology aptitude, or harmless looking. The skills and abilities a character has increases the chances that a certain Responses to an Encounter are successful.
Players will be able to add new skills and abilities to their characters through Solving Encounters. Each time a player Responds to an Encounter, there is a chance of gaining a new skill or ability. For example, if the player did not have lockpicking skills, and was confronted with a locked door, and Responded to the Encounter with a screwdriver, they might obtain the basic lockpicking skill.
Endgame States
Play in the game continues until an Endgame State is reached. Upon reaching an Endgame State, the player’s stats are recorded to the game’s records, and the player can choose to begin another game, or view the game’s records.
Failure States
Failure Endgame States include permanent incapacitation and death of the player. The former can occur through Results such as imprisonment or paralysis. The latter can occur through Results such as starvation, dehydration, violence, exposure, or disease.
Victory States
Victory Endgame States include a list of Results predetermined by the game designer. They typically revolve around the concept of achieving stability and relative safety. Victory States include such Results as finding refuge and acceptance in a stable community or escape from the world. There will be five or more Victory States, each a bit different, to allow for replay.
Setting
The setting for the game is a post-apocalyptic, near-future Earth where supernatural activity abounds. Technology is sufficiently advanced so as to allow for things such as powered armor, hover vehicles, and (once) commonplace intra-solar system space travel, but a combination of supernatural activity and human warfare have fragmented mankind into pockets of civilization struggling to survive in wild and dangerous lands.
So there you have it! It's a work in progress, obviously. A lot of the above sounds good in my head, but without building and playtesting it, I won't know for sure. The above is enough to guide me for now, and keep me busy for a while, and I'll make adjustments as necessary.
If you have any feedback about the doc, or notice any glaring omissions, let me know. And thanks again for the nudges to get this doc going!
Thursday, June 9, 2011
Oh Sweet Internet
The Shaw guy just hooked us up. After a week and a half on the road, we're once again plugged-in and reaching out. And how wonderful it is. We're bathing in the warmth of information on-demand now.
Cellphone coverage is still an issue, and we may need new phones to work with the non-Rogers towers in our area. At the moment, our Montreal number still works, but I have to kneel by the dining room window to get a signal.
Seriously. Only if I kneel.
Which I guess is fair, given this is our front yard:
It's about a 30 minute drive into town, so we're pretty out there. But it's gorgeous. And ripe with wilderness-y sounds for my game!
There are some minor moving in tasks left to do. Some pictures to hang. Some miscellaneous items to find homes for. But we're just about unpacked now, and game development should resume no later than Monday. See you then!
Cellphone coverage is still an issue, and we may need new phones to work with the non-Rogers towers in our area. At the moment, our Montreal number still works, but I have to kneel by the dining room window to get a signal.
Seriously. Only if I kneel.
Which I guess is fair, given this is our front yard:
It's about a 30 minute drive into town, so we're pretty out there. But it's gorgeous. And ripe with wilderness-y sounds for my game!
There are some minor moving in tasks left to do. Some pictures to hang. Some miscellaneous items to find homes for. But we're just about unpacked now, and game development should resume no later than Monday. See you then!
Wednesday, June 1, 2011
Still On the Road
Gamedev Mega-demanagement déménagement continues. Four provinces and two time zones later, we're now taking a brief respite with some family, and ETA at our new home is Sunday!
Haven't really cracked open the laptop yet. Our first night allowed for a tweet, the second night was with a wonderful host, and the third night was in a Saskatchewan hostel without internet access (or any energy to stay awake).
That said, a lot of people are asking about what the heck this game is all about, and what they should expect in the future. Some friends in Montreal at first, then Gareth in the last post's comments, now friends and family here. I'm getting better at explaining it each time, but this is telling me I need to get my act together and put some sort of design doc together soon. So once we're settled in BC, I think that'll be a next task.
That, and as Brook pointed out, some damned vidcaps so he can see the snow animating instead of imagining it ;-)
Haven't really cracked open the laptop yet. Our first night allowed for a tweet, the second night was with a wonderful host, and the third night was in a Saskatchewan hostel without internet access (or any energy to stay awake).
 |
| Mmmm, dinner! |
That said, a lot of people are asking about what the heck this game is all about, and what they should expect in the future. Some friends in Montreal at first, then Gareth in the last post's comments, now friends and family here. I'm getting better at explaining it each time, but this is telling me I need to get my act together and put some sort of design doc together soon. So once we're settled in BC, I think that'll be a next task.
That, and as Brook pointed out, some damned vidcaps so he can see the snow animating instead of imagining it ;-)
Subscribe to:
Posts (Atom)