Edit: Don't pay any attention to this post. It is left over from when this forum was used for something else, and has nothing to do with Casual Quest.
This is a work in progress. I'll post this as a file as soon as I have some personal file space somewhere on the internet, or I have a membership; whichever. You'll notice several "Open Issues". These are aspects of gameplay I havn't decided on yet. You can help by suggesting your own take on the issue. You may also think up some open issues I missed, or notice that I'm not clear on some points. Please point these out. If you have suggestions for features, those are welcome, too.
Note: This is a functional spec, not a technical spec. It defines what the game will be (what the player will see and interact with), not how it will be make. Technical notes are welcome, though.
And now, the main event:
Title: Action Adventure Space Game, Functional Specification.
Version: 1.01
Maintained by: IainPeregrine
Short description: A game for 1 primary player and up to two secondary players. Overhead view point with action based combat similar to The Legend of Zelda or The Secret of Mana. Core gameplay should be fun and challenging, and replay value should be high. Genre is "Space Station": the player(s) are alone in an expansive yet individually confined series of rooms and corridors, surrounded by advanced technology and all sorts of munchy platforms, and under constant threat from mysterious aliens, chilling bio-experiments, facist company controlled robots, and loopy AI. Players must work with the various systems onboard the spacestation (spaceship, in this case) to advance, and must solve various environment and information based puzzles.
--------------------------------------
Three Player gameplay:
- The game is based around one central player whose presence is required in order for gameplay to continue. Other players may drop out at any time, or join in appropriate "safe" rooms.
- The camera is shared, and must be smart and intuitive. Technical suggestion: The camera should be located at the mean of the extremes of both axes.
- The camera sees all; there are no opaque objects.
- Once a player (central or secondary) reaches the exit of a map, all players are removed to the new map. This can create the odd experience of a player, who cannot logically reach the exit from their current position, is trapped, or is engaged in combat, being warped out of their position because another player has touched an exit. Exits should be padded with buffer areas for this reason. Some logically inconsistent warping is acceptable, though, just so long as a puzzle doesn't depend on it.
- Rooms should be large enough to comfortably fit three players. This will also help with the "warping" issue mentioned earlier in this section.
--------------------------------------
Combat:
- Combat takes place in real time on the regular map. There is no distinction between combat gameplay and regular gameplay (such as a change of view, camera fixation, or change of music), even during boss battles. This establishes a realistic and immersive feel (note: similar to boss battles from the NES Metroid).
- There are two types of combat phenomenon: Characters and Projectiles.
- Characters are potentially mobile entities which can engage in combat, though they may remain stationary.
- Characters' movement may be hindered by dense parts of the environment, or they may "fly" unobstructed.
- Characters can potentially attack via touch.
- Characters may be immune to attack from certain sides or when in certain states, or they may be completely immune to attack (where they function as an active part of the environment).
- Characters are not dense to other characters, but are pushed back if they are hurt by touching an enemy character (Popisfizzy). Technical Note: This project does not use BYOND's standard dense variable.
- The players are characters.
- Characters may attack by producing projectiles.
- Projectiles are transient mobile entities which cause damage when they strike an enemy character.
- Projectiles movement may be hindered by dense parts of the environment, but usually are not.
- Projectiles which are hindered by dense parts of the environment may explode once obstructed. Technical note: An exploding projectile is probably just a projectile which remains stationary while increasing its size and playing an animation.
- Projectiles cease to exist once they are no longer visible by the camera.
- The player character, and perhaps some NPCs, may have access to melee weapons. Technical note: A melee weapon may be accomplished simply by shooting a projectile which ceases to exist at a very short range.
- Characters will have varying numbers of hit points, in the general range of 1-10. The player should have an instictive feel for the amount of damage each character can take, rather than having to count or rely on hud numbers. !This is not an RPG, no large numbers ever.
- !Imperative: NPCs will be made interesting or difficult via their behavior, not via their stats.
--------------------------------------
Items:
- Items may be collected from storage in the environment or from transient item drops from defeated NPCs.
- Players may collect transient items by moving their character over the item on the ground. If they can carry the item, it will be added to their inventory.
- Players may collect a stored item by interacting with its environmental container (like a treasure chest or crew member's locker).
- Items may be used immediatly upon collection (hearts, energy refills), or they may be stored in the player's inventory (bombs, ammunition). Technical note: Ideally, a player with full health or ammo should not be able to collect an item they don't need.
- Certain items may be selected to be used as a weapon.
- Weapons determine the type of attack the player character is capable of performing. Technical note: In other words, weapons determine what projectile the player produces.
- Weapons may need ammunition in order to operate.
- Once a weapon is collected it is usable by any player. However, only as many players can use the item as there are weapons in inventory. So if two Fusion Pistols have been collected, and two secondary players are currently using Fusion Pistols, the central player cannot use a Fusion Pistol until one of the secondary players has switched to a different weapon.
- ?Open issue: Should ammunition be held in common (or "pooled") or stored individually with each character? If stored individually, should a mechanism be implemented to share ammo? If so, how will that work?
- Some rare items are armor, and will be applied to the player character immediatly upon collection.
- Armor will effect the amount of damage taken by attacks.
- Armor may provide immunity from attacks from certain angles, or from certain types, or from any combination thereof. Technical note: I smell bit flags (directional, and damage type) and bit masks (on the armor).
- ?Open issue: Some special types of items do not fit nicely into these categories, such as an item which allows you to survive in low oxygen areas so long as your oxygen supply does not run out, or a "hard vacuum suit". How will these be implemented in a user interface?
--------------------------------------
Environment:
- The environment will consist of rooms filled with environmental objects (EOs) and characters.
- Rooms are regions of map which have a set arrangement of environmental objects and characters, and other characteristics.
- Rooms will have specific music. Technical note: If the music a room specifies is the same music as the room the player entered from, do not change music, just continue to play the previous room's music.
- ?Open issue: Should rooms be allowed to have no defined music, in which case the music of the previous room simply plays?
- Rooms may have low (read: no) oxygen.
- ?Open issue: Should hard vacuum be an attribute of some rooms? If so, how will it work?
- ?Open issue: Should exits be placed as actual objects on a map, or handled as the player approaches the room's bounds?
- Environmental objects are tile based, stationary, and may be interactive.
- EOs may be dense or non-dense. Dense EOs will obstruct the movement of any any character or projectile which does not "fly".
- EOs may be interactive in a wide variety of ways.
- EOs may be storage containers which open up and provide items when interacted with in the standard way.
- EOs may be power stations which refill various aspects of the player character's stats (such as health or oxygen) when interacted with in the standard way.
- EOs may be obstructions which are removed once interacted with in the standard way (doors).
- EOs may be obstructions which are removed once attacked in a specific way (such as with explosives).
- EOs may have a state change triggered by other EOs, such as a door opening or closing because of the action of a switch, or an oxygen refill going offline as a result of the player destroying a terminal.
- EOs may change state as the result of a player character performing a standard interaction while in possession of a certain item, such as a terminal requiring a data disk.
- ?Open issue: Should there be any "pushable" EOs? If not tile based, does this mean we need a whole new class of object?
--------------------------------------
Saving:
- Saved game data will be recorded on the central player's server.
- Character data saved will include items in inventory and ammunition amounts.
- ?Open issue: Should health or oxygen be saved?
- Game state data saved will include various flags related to the state of the ship, perhaps including some of the following: Oxygen and hard vacuum status in effected areas, power restoration to different areas, states of doors and other blockages, (de)activation of security mechanisms.
- ?Open issue: More discussion is needed with level designers and plot writers before this can be determined.
--------------------------------------
Non-gameplay interface:
- Once the game has been booted, but before gameplay has begun, the player will be presented with a title screen.
- The title screen will display the name of the game, and optionally the name of the "production company", and year of publication.
- The title screen will display several choices, and allow the central player to select one via a moving cursor.
- The title screen will offer the choice to load a saved game, or a start a new game.
- ?Open issue: Are other choices needed here? For instance, a survival mode or a sound test?
- If the player chooses to start a new game, then an introductory movie may start. At the end of the intro, or if an intro isn't used, the player will then be given control of a player character and the game will begin.
- If the player chooses to load a saved game he will be presented with an OS specific file browsing window so that he may locate a file of his choosing. If the selected file is not in the proper format, a message saying so will be presented to the user, and the title screen will be redisplayed. If the user canceled the file browse, the title screen will the redisplayed. If the user selects an appropriate file then that file will be loaded, the user will be given control of a player character, and the game will begin.
- ?Open issue: Once gameplay begins, how will the user be given the opportunity to open a port and begin hosting the game for others to join? How will the central player be given the option of who to allow to join? How will the central player remove a secondary player from his server?
--------------------------------------
Server Issues
- ?Open issue: Once all the players die (game over) what happens? Do we go back to the title screen? If so, how are the connected players handled? My first thought is that after a game over occurs, and once the central player presses "Confirm" that game starts from the last save, with all the secondary players already loaded into the game.
- ?Open issue: If the central player decides to go back to the title screen, how does he do this, and how are the connected players handled?
- ?Open issue: Once the final boss has been defeated and the ending movie has been played, what happens next? Are all the secondary players disconnected, or placed in limbo until the central player begins a new game? Does the game just sit there at "The End" and wait for the central player to close it?
--------------------------------------
Interface:
- !Imperative: Interface does not mean a BYOND interface! Interface refers to how the players interact with the game.
- There will be a standard key mapping scheme, and there will also be provided a means to remap commands to different keys.
- ?Open issue: How will that keymapping take place? Technical note: I'd suggest loading the keymapping from a simple text file, and directing the user to edit it as plain text if they want to change mappings.
- ?Open issue: How will each player be allowed to edit their own keybindings? Technical note: Good question.
- There will be four keys used to control movement. The standard mapping for these will be the arrow keys.
- There will be a Confirm key used in all places needing a "Yes", "Confirm", or "Activate" message. The standard mapping for this key will probably be V.
- The Confirm key will be used to innitiate a standard interaction on interactable environment objects.
- There will be a Cancel key used in all places needing a "No" or "Cancel" message. The standard mapping for this key will probably be C.
- There will be two sets of two keys used to cycle through the player character's primary and secondary weapons, one each for back and forward. The standard mapping for these keys will probably be A and S for primary, and Z and X for secondary.
- There will be a Primary key used to fire the player character's primary weapon. The standard mapping for this key will probably be F.
- There will be a Secondary key used to activate the player character's secondary item. The standard mapping for this key will probably be D.
- ?Open Issue: Can I has Cheeseburger? Technical note: Yes.
--------------------------------------
Required items, as mentioned in above spec:
Central Player
Two secondary players
Camera
Characters
Projectiles
Projectiles, Exploding
Items
Items, transient
Items, Weapons
Items, Ammunition
Items, Armor
Rooms
Rooms, Safe (for secondary players to join in)
Environmental Objects
Environmental Objects, Dense and non-dense
Environmental Objects, Interactive and non-interactive.
ID:287839
 Jul 27 2009, 10:15 am (Edited on Nov 21 2010, 12:52 am)
|
|
Zaole wrote:
- ?Open issue: Should exits be placed as actual objects on a map, or handled as the player approaches the room's bounds? Good point, I don't know how I overlooked that. Saving: The issue of what to save is a bit more complicated than it seems at first. Imagine that at the very start of the game the player only has access to deck 8, and must activate life support to all decks in order to progress. After that, life support cannot be turned off. Now the player can access deck 9 and 10, but must turn off the security lazers in order to continue to other decks. One these are disabled they can never be turned back on, either. Now, what's better? Store the state of both the life support and the lazers as two separate values, or have one counter which goes up every time one of these missions is completed. The answer depends entirely on how linear the game is. To make things even more confusing, the game as a whole can have linear advancement (there's a clear beginning, middle, endgame) but each part can have non-linear goals that need to be saved across sessions. Now you have one value which you increment whenever the player has achieved a major task, and a separate set of variables which hold information pertaining to the subtasks (these variables are probably reused in each "chapter" of the game; again, I'm smelling bit flags). So what exactly needs to be saved is very much dependent on the plot and level design. I imagine the plot will determine the overall sequence of "chapters" and what the goal and setting of each is, while the level design will determine how that chapter is laid out internally. - ?Open issue: Should ammunition be held in common (or "pooled") or stored individually with each character? If stored individually, should a mechanism be implemented to share ammo? If so, how will that work? I was leaning toward pooled ammo, too, but then I started thinking about the recent Resident Evil game which I played with my brother (note: it sucked). I enjoyed how each of us felt like we owned our guns and ammo, and how we frequently stopped to argue who would pick up what ammo and why that was best for the team. Side note: I almost always got the hand gun ammo, and passed the shotgun ammo to my brother; pistols rule. I kinda like the idea of ammo being a personal thing, but there being a button you can press to spread your ammo evenly among everyone currently using a gun that uses that ammo. All this may make things needlessly complicated, though. - ?Open issue: Some special types of items do not fit nicely into these categories, such as an item which allows you to survive in low oxygen areas so long as your oxygen supply does not run out, or a "hard vacuum suit". How will these be implemented in a user interface? That could work. It only pops up when it's needed. - ?Open issue: Should there be any "pushable" EOs? If not tile based, does this mean we need a whole new class of object? EOs will be tile based, characters and projectiles will not. Most characters, including all player characters, will be one tile large (at least graphically), though. There will be some larger characters (mostly bosses) and some smaller characters. Projectiles will mostly be smaller, on the half tile scale. As for pushable EOs, the way I think I'd include them is as an object that you walk up to and press the Confirm key, and the object will then move into place. I can't see adding all sorts of checks whenever a player moves, just to see if he's trying to push a block. I don't see how many push-block puzzles are going to make sense in this setting, either. That's not really my department or area of expertise, though. | |
The issue of what to save is a bit more complicated than it seems at first. Imagine that at the very start of the game the player only has access to deck 8, and must activate life support to all decks in order to progress. After that, life support cannot be turned off. Now the player can access deck 9 and 10, but must turn off the security lazers in order to continue to other decks. One these are disabled they can never be turned back on, either. Now, what's better? Store the state of both the life support and the lazers as two separate values, or have one counter which goes up every time one of these missions is completed. The answer depends entirely on how linear the game is.
To make things even more confusing, the game as a whole can have linear advancement (there's a clear beginning, middle, endgame) but each part can have non-linear goals that need to be saved across sessions. Now you have one value which you increment whenever the player has achieved a major task, and a separate set of variables which hold information pertaining to the subtasks (these variables are probably reused in each "chapter" of the game; again, I'm smelling bit flags). So what exactly needs to be saved is very much dependent on the plot and level design. I imagine the plot will determine the overall sequence of "chapters" and what the goal and setting of each is, while the level design will determine how that chapter is laid out internally. i'm neutral on how the overall build of levels of should be-- whatever's easiest to save and keep glitch-free would be best. you've also got to keep in mind that you don't want to overflow the player with confusing information and mapping, either. as such, a highly linear map sounds best, aside from some small 'hub' type locations that allow the player easy access to all the necessary areas I was leaning toward pooled ammo, too, but then I started thinking about the recent Resident Evil game which I played with my brother (note: it sucked). I enjoyed how each of us felt like we owned our guns and ammo, and how we frequently stopped to argue who would pick up what ammo and why that was best for the team. Side note: I almost always got the hand gun ammo, and passed the shotgun ammo to my brother; pistols rule. I kinda like the idea of ammo being a personal thing, but there being a button you can press to spread your ammo evenly among everyone currently using a gun that uses that ammo. All this may make things needlessly complicated, though. i enjoyed RE5 :P (and i too was a handgun whore) creating the ability to pass ammo and other items between players would add some complications to what would otherwise appear to be a simple, user-friendly game as far as the interface is concerned. i think pooling all items is a friendly compromise between "hey don't grab that item, i need it and we can't trade" and "hold on let's sit around for 5 or 10 minutes and try to figure out how to trade all this stuff" also, have you done any deliberation on the characters themselves? will it be 3 highly unique characters and you can choose any of the 3 regardless of how many people are playing? or will it be more of a "bob the main hero" that player #1 always has to play and then the other two sidekicks? also, will they each have different playstyles or have no differences other than appearance? | |
also, have you done any deliberation on the characters themselves? will it be 3 highly unique characters and you can choose any of the 3 regardless of how many people are playing? or will it be more of a "bob the main hero" that player #1 always has to play and then the other two sidekicks? also, will they each have different playstyles or have no differences other than appearance? I've put some thought into the visual style of the characters, but nothing to in depth. I don't see the characters' identities as being important to the story. Imagine that you've just woken up in a defrosted cryogenics pod. The power seems to have gone out and the pods have all shut down. Some of them opened up as a safety measure, yours was one of those. Others didn't open properly, and the people inside seem to have died of either hypothermia or suffocation. Some of them look like they were attacked by something... messy. Most are simply open and vacant. Of the rest, you found two others who's occupants are alive and well, once you helped them escape and defrost. There's a lot of questions, perhaps the biggest being "why was I in a cryogenics pod in the first place?" All that is my own musing on the project, though. The story itself isn't my department. For now I've just been assuming that each of the three characters would have a set appearance, and the central player would always play as "Jane", the second guy to join would always get "Bob", and the third guy would get "Stinky the wonder opossum". All three would play exactly the same. Another way I'm open to doing it would be to allow each player to choose one of three character types, where each character plays differently, and there is no set "main" character. Another related idea is to allow each person to choose a character, but after that point no one else can choose that character (so at any one time there's only one wonder opossum). Because the game has to be completable by one person playing alone, we can't rely on puzzles that take three people to complete (though we may still have those scattered about encourage co-op play, or provide extra content). I guess we have to think of the extra players as an expansion of combat ability, and not an expansion of puzzle solving combinations. | |
they should probably be handled as actual objects on the map. that'll allow more freedom as far as level design goes (such as exits in locations other than just the edge of the room)
Saving:
- Saved game data will be recorded on the central player's server.
- Character data saved will include items in inventory and ammunition amounts.
- ?Open issue: Should health or oxygen be saved?
- Game state data saved will include various flags related to the state of the ship, perhaps including some of the following: Oxygen and hard vacuum status in effected areas, power restoration to different areas, states of doors and other blockages, (de)activation of security mechanisms.
- ?Open issue: More discussion is needed with level designers and plot writers before this can be determined.
what are you asking to discuss here? the ship's condition (pushed buttons, pulled levers, etc etc) should indeed be saved, otherwise a lot of strange issues could arise; health, oxygen, and-- if it is a possible scenario-- 'dangerous, temporary' conditions of the ship should not be saved so that players don't get stuck in a permanently futile save state.
- ?Open issue: Should ammunition be held in common (or "pooled") or stored individually with each character? If stored individually, should a mechanism be implemented to share ammo? If so, how will that work?
i really like the idea of making all inventory items, including ammo, pooled together in a single inventory that everyone uses simultaneously. sure, one guy could use up all the bullets, but this is a very interpersonal game, so if that happens it's not a case of "attacked by a random griefer", it's "our buddy is dicking around and wasting our ammo, let's yell at him for it"
- ?Open issue: Some special types of items do not fit nicely into these categories, such as an item which allows you to survive in low oxygen areas so long as your oxygen supply does not run out, or a "hard vacuum suit". How will these be implemented in a user interface?
depending on what exactly the item is, it could just pop up like a temporary extraneous bar (such as in a reserved space alongside one's health bar) or as a little buff icon on the screen; there could be one section of the interface reserved for these 'temporary status' or 'key item' things, so that the player can quickly see what they do or don't have
- ?Open issue: Should there be any "pushable" EOs? If not tile based, does this mean we need a whole new class of object?
i think it'd help a lot with puzzle creation to have pushables, considering there are a lot of puzzle concepts that can't be included majorly because they could be trivialized by having more than 1 person, yet we can't add any puzzles that would mandate having more than 1 person. they should be tiled based, as should pretty much everything else (aside from projectiles?), in order to avoid confusion and messy glitches