The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
[Make On] The Journey to Write a Game.
Valkun
Registered User regular
Registered User regular
Given our particular love of games, it is no surprise that we get a ton of threads by dreamers looking to make a game of their very own. Often times, their hopes are summarily snuffed out as they get hounded by the more experienced people on the forums and they realize just how involved of an endeavor it actually is. Hopefully I can use this project as a means to provide an example for those that wish to follow this particular craft. I know exactly what I'm getting myself into, it is a long, arduous process that will likely see me crash and burn before the project reaches completion. But if I never try, I can never succeed.
A little background on me, I have just recently graduated with a bachelor's in Computer Science and have produced simple games before. What does this mean? I actually know how to program and have managed large, team based software projects. However, this will be a solo endeavor.
Although I always keep a few ideas bouncing around for day dreaming, I was recently struck with inspiration and I'd like to run with it while it's still searing hot. What I have in mind is a science fiction rogue-like taking place on the ruined remains of an abandoned hulk. This obviously requires minimal art and music assets which I find tedious to create. Admittedly, the idea borrows heavily on games like Space Station 13, numerous science fiction stores, and other rogue-likes. For the time being, the game will be written from scratch using Java.
The Plan:
1. Figure out the requirements
2. Create a Prototype
3. Create Design Documents detailing the underlying architecture
4. Write Code
5. Test Code
6. Repeat steps 1,3,4, and 5 until a working version is released.
7. Repeat steps 1,3,4,5, and 6 until satisfied.
Step 1a: Fleshing out the requirements
Pacific Alliance Arcadia - Working Title
Example run:
This example provides a descriptive snap shot of what using the program will actually be like. Given the fact that it's a rogue-like, the gameplay is, by its nature, random and can be hard to portray.
Initial Requirements
Note that no where in this list are there specifics about implementation. Those come in a later phase. This is just a very high level 'what do I want it to do' list. Each requirement can then be paired with one or more parts of the architecture to come and generate test cases.
A little background on me, I have just recently graduated with a bachelor's in Computer Science and have produced simple games before. What does this mean? I actually know how to program and have managed large, team based software projects. However, this will be a solo endeavor.
Although I always keep a few ideas bouncing around for day dreaming, I was recently struck with inspiration and I'd like to run with it while it's still searing hot. What I have in mind is a science fiction rogue-like taking place on the ruined remains of an abandoned hulk. This obviously requires minimal art and music assets which I find tedious to create. Admittedly, the idea borrows heavily on games like Space Station 13, numerous science fiction stores, and other rogue-likes. For the time being, the game will be written from scratch using Java.
The Plan:
1. Figure out the requirements
2. Create a Prototype
3. Create Design Documents detailing the underlying architecture
4. Write Code
5. Test Code
6. Repeat steps 1,3,4, and 5 until a working version is released.
7. Repeat steps 1,3,4,5, and 6 until satisfied.
Step 1a: Fleshing out the requirements
In software engineering, this is where all projects truly begin. You sit down and figure out what the program does. Not how it accomplishes these requirements but merely what it must do. As a programming veteran, I can tell you that having to rewrite your code because it doesn't fulfill some needed aspect of the project is the second most painful kind of programming. The most painful is having to go back and rewrite someone else's code. By taking time to figure this stuff out first, you can keep it in mind when designing the architecture of the software.
Of course, you're not going to think of everything, hence why you have to keep adjusting the requirements as you go along. In software engineering terms, this is referred to as an agile method of development because it keeps the design flexible while you work. In a serious development environment, this would take the form of a 'vision document' but I won't bore you with something that intense here.
For the beginner game maker, I'd recommend starting off with very simple projects like pong or tetris to get your feet wet. Without a good understanding of programming, you may have a hard time getting anything complicated off the ground. If you fall into this category and are interested in making games, I'd suggest making use of pre-built engines, game development kits like Game Maker, or Flash. Once your understanding of memory management, graphics, AI, data storage, various algorithms, etc become stronger, you can easily identify what is required for your more complicated game ideas.
Step 1b: Assessing RiskOf course, you're not going to think of everything, hence why you have to keep adjusting the requirements as you go along. In software engineering terms, this is referred to as an agile method of development because it keeps the design flexible while you work. In a serious development environment, this would take the form of a 'vision document' but I won't bore you with something that intense here.
For the beginner game maker, I'd recommend starting off with very simple projects like pong or tetris to get your feet wet. Without a good understanding of programming, you may have a hard time getting anything complicated off the ground. If you fall into this category and are interested in making games, I'd suggest making use of pre-built engines, game development kits like Game Maker, or Flash. Once your understanding of memory management, graphics, AI, data storage, various algorithms, etc become stronger, you can easily identify what is required for your more complicated game ideas.
Pacific Alliance Arcadia - Working Title
Example run:
The player begins the game with character generation by answering questions regarding the character's life. These questions determine the character's starting statistics.
After this, the player is presented with a short story on what happens prior to the start of the game, including any information on the Arcadia. As the starting ship approaches the Arcadia, something malfunctions and the ship collides into the side of the hull damaging the starting ship. Upon waking up, the player finds themself in the shattered remains of their ship with possibly an injured crewman and many corpses. Scrounging together some gear like a space suit and rations, the player leaves the starting ship to search the wreck for some way to get home.
After exiting, the player finds themself in the remains of the Arcadia's storage bay. The lights are off and boxes are scattered around the massive room. A check on the environmental conditions shows that there is sparse little atmosphere here. No surprise considering the gaping hole their ship just punched into the outer wall. A message displays informing the player that something nearby just made a scratching sound. Moving slowly with a flashlight in hand, the player responds to the sudden appearance of a monster with a thrown toolbox. Hurt by the makeshift weapon, the whatever it was runs away into the darkness. Shaken, the player equips a pistol and makes their way to rigging up a portable generator and getting the lights working again. Through some trial and error, they figure out how some of the equipment in the storage room works and grabs whatever looks useful for their journey deeper into the ship.
After this, the player is presented with a short story on what happens prior to the start of the game, including any information on the Arcadia. As the starting ship approaches the Arcadia, something malfunctions and the ship collides into the side of the hull damaging the starting ship. Upon waking up, the player finds themself in the shattered remains of their ship with possibly an injured crewman and many corpses. Scrounging together some gear like a space suit and rations, the player leaves the starting ship to search the wreck for some way to get home.
After exiting, the player finds themself in the remains of the Arcadia's storage bay. The lights are off and boxes are scattered around the massive room. A check on the environmental conditions shows that there is sparse little atmosphere here. No surprise considering the gaping hole their ship just punched into the outer wall. A message displays informing the player that something nearby just made a scratching sound. Moving slowly with a flashlight in hand, the player responds to the sudden appearance of a monster with a thrown toolbox. Hurt by the makeshift weapon, the whatever it was runs away into the darkness. Shaken, the player equips a pistol and makes their way to rigging up a portable generator and getting the lights working again. Through some trial and error, they figure out how some of the equipment in the storage room works and grabs whatever looks useful for their journey deeper into the ship.
This example provides a descriptive snap shot of what using the program will actually be like. Given the fact that it's a rogue-like, the gameplay is, by its nature, random and can be hard to portray.
Initial Requirements
I. Engine A. Graphics 1. Tiles generated from ascii characters 2. Seperate game window, status line, and character statistics B. File Storage C. Level Generation 1. Design ship layout 2. Place crew 3. Run and apply generation scenario 4. Continue to run until all crew are accounted for 5. Add random additional events (meteor strikes, looters, etc) 6. Insert starting ship somewhere in the main ship. D. User Interface 1. Point and click with context sensitive popup submenus 2. All Objects in Tile->Use Left Hand/Right Hand/Skills 3. Default double left click action (e.g. attack with weapon, open door, etc) E. Time System 1. Store energy for using actions 2. Both energy and time needed to perform actions 3. Hunger reduces energy generation and maximum energy storage 4. Run time in 1 second (in game) quantum II. Environment A. Air Composition 1. Need oxygen at all times to live. 2. High concentrations of certain gasses can have side effects. 3. Air can be stored in tanks or created by certain equipment. B. Heat 1. Cold from space/certain equipment causes damage 2. Fires, equipment, and certain entities can cause damage or set things on fire 3. Clothing and equipment can counteract heat variances C. Pressure 1. High or low pressure can cause damage 2. Counteracted by proper equipment 3. Can affect flamibility D. Light 1. Produced by fire, equipment, and certain entities 2. Lack of light reduces the sight range of the player and NPC's 3. Can be counteracted through the use of alternative sight equipment (e.g. infrared, light amplification, etc) E. Electricity 1. Causes damage if directly exposed 2. Can be insulated against with proper equipment 3. Needed to run ship systems 4. Transferred via power lines throughout the ship 5. Generated by internal engines, solar panels, or other sources F. Fire 1. All objects have a flamibility rating (temperature) 2. Must have oxygen to start 3. Consumes oxygen 4. Spreads to nearby objects 5. Causes damage when an object is on fire 6. Nullified by water and other substances G. Hazardous Substances 1. Acid 2. Air borne bacteria III. Character A. Generation 1. Life Path B. Statistics 1. Qualitative 2. Each limb individually tracked for health 3. Standard RPG statistics: strength, agility, etc 4. Hunger C. Inventory 1. Gear can be worn on both hands, torso, legs, feet, pockets, held in either hand, and slung on the back 2. All objects have a volume and weight characteristic that limits what they can fit inside D. Skills 1. E. Advancement 1. Use based advancement IV. Friendly NPC's A. Starting Ship Crew B. Computer AI C. Robots D. Cryo Stored Crew Members E. Visitors V. Hostile NPC's A. Randomly Generated Monsters 1. Created from random genes 2. Variances exist within the same monster class B. Pirates 1. Human 2. Do not necessarily speak same language 3. Can be friended given proper actions C. Cultists 1. Assigned to one or more alien species 2. Possible 'magical' abilities VI. Mechanical Systems A. Computers 1. Each subsystem will likely have one or more computer terminals to control them B. Life Support 1. Responsible for maintaining air pressure, composition, and temperature 2. Highest priority for electricity C. Power 1. Generates electricity for use by other systems D. Doors 1. Locked via key cards or pass codes 2. Can be opened using hacking, force, explosives, etc 3. Force Fields only appear when section is powered E. Equipment 1. Found throughout the ship 2. Functionality is randomized at the beginning of game 3. Equipment performs abilities appropriate to where it was originally stored 4. Can be moved about the ship during world generation 5. May require certain resources like batteries to operate F. Transportation 1. Moves objects from location to location 2. Time based, not instant G. Alien Systems 1. Randomized at beginning of game 2. Perform abilities not found on normal equipment VII. Levels A. Starting Ship 1. Damaged on entry, this is where the player will always start. 2. Basic essentials necessary for survival are found here 3. No enemies are found here unless they move in from elsewhere B. Docking Bay C. Storage D. Bridge E. Engine F. Power Generation G. Atmospherics H. Security I. Computer J. Hallways/Elevators K. Attached Ships L. Derelict Alien Ship M. Laboratory N. Navigation O. Fabrication P. Mess Hall Q. Quarters R. Hydroponics S. Generation Notes: 1. Due to various scenarios and during initial generation, rooms take damage to equipment and walls. 2. Rooms organized into logical subsections noted above 3. Hallways connect various rooms together 4. Life Support/Power lines are routed to connect all rooms VIII. Generation Scenarios A. Pirates 1. Major damage to ship starting from outside 2. Boarding party 3. Disabled pirate ship may be found attached or nearby B. Alien Relic Surprise 1. Aliens spawn from attached derelict ship or from science bay. C. Narrow Escape 1. Damage to ship from the outside. 2. Major damage to engines and life support D. Mutiny 1. Seperate ship crew into factions E. Meteor Storm 1. Major Damage to ship from outside F. Alien Attack 1. Same as Pirates G. Runaway Experiment 1. Dangerous toxins, bacteria, AI, or robots kill the crew H. Crew Logs 1. During ship generation, crew make log objects describing events transpiring 2. Can be used to identify certain equipment and pass codes IX. Winning A. Repair Starter Ship 1. Find components inside the ship to repair the ship the player came in on B. Repair Main Ship 2. Use components from the starter ship and those found inside the ship C. Find Teleport Technology 3. Possibly found deep inside the alien derelict D. Transcend Existance
Note that no where in this list are there specifics about implementation. Those come in a later phase. This is just a very high level 'what do I want it to do' list. Each requirement can then be paired with one or more parts of the architecture to come and generate test cases.
Valkun on
0
Posts
For now, though, sleep.
So, we have requirements, now what? I'm glad I asked. Using the list generated earlier, we organize them in a list of hardest to implement to easiest. This part takes some experience in programming. If you've never worked on similar algorithms before, it can be hard to gauge the intricacies involved in writing it.
For the purposes of this project, I'll divide the list into 3 levels of priority:
High These are items that are complicated to write or absolutely vital to completing the program.
Medium
Low These items are trivially easy to write.
Tomorrow: Step 1c - Use Cases, how to turn requirements into something a little more understandable.
Use cases and more importantly, the Use Case diagram, allows us to start creating a picture of the product we want to build.
First, let us define the 'actors' involved in the program.
Player. Also called a user in most software designs. This is our primary source of input and output. The player will also encompass the monitor which provides feedback to the user and the keyboard and other input devices which the player uses to communicate with the program.
NPC's. This might be a bit of a stretch, depending on our exact design and implementation of their AI.
Database. In most cases, it is too memory intensive to store everything about the game in RAM so the vast majority of it will be stored on the local disk.
Note the absence of the software, its function is encapsulated by the use cases.
A quick list of use cases:
Start Program
Generate Character
Save Game
Load Game
Quit Game
Move Character
Use Item
Pick up Item
Use Object in Tile
Pull/Push Object
Display Game Status
Generate World
Update NPC's
Process the current time cycle
Process Atmosphere
Process Ship Systems
Check for Victory
Check for Defeat
To be honest, it's taking a lot of willpower not to just jump in and start programming. Maybe I'll get started on something just for a prototype.
:^:
Resist temptation :P
We both know that once you start a prototype you'll get something working and then say, "Alright, I guess I can get to work on this from here since I've got a nice framework and that's almost as good as a design document!" and then shrug off the design document because writing in Word is boring.
How_to_Write_a_Roguelike_in_15_Steps
This guide right here made me cringe more than is imaginable. It's no wonder most of these projects turn into hacked together pieces of indecipherable spaghetti code.
It was horrible.
With games, you need to get the boring foundation down before you can even touch code. It may suck, but it helps throughout the entire project.
1. Death
2. Character Advancement
3. Level Design
4. Challenges
Death, my thoughts:
In true roguelike fashion, I was thinking of using simple permadeath requiring the player to evolve between play throughs. However, this style of gameplay is very unpopular with large segments of the population, especially when deaths can be out of their control. One of my design goals for this game is to make as much randomized as possible. This would reduce player learning between playthroughs compared to more static environments.
What alternatives exist to perma death that would still create a sense of tension in the game?
Character Advancement:
Ever since Ultima Online, I have always had a special place in my heart for use based character advancement. That is, the statistics and skills used are raise incrementally rather than having arbitrary levels and points to be allocated. This can lead to odd play habits concentrating on raising the values that the player wants to eventually develop rather than play naturally. If shared caps are placed on possible gains, this behavior is even more prevalent.
Level Design, How to create beauty out of chaos:
This is one area where I'll have to do quite a bit of research as I have never worked on such a system. Currently, I want to organize the map into randomly generated subsections using predefined rooms connected to hallways. To give it a more structured feel, the hallways would be generated first with rooms branching off of them. Sub rooms and equipment would then be placed afterwards. Each level can be sandwiched between crawlspace levels that can be entered through vents on the floors above and below it. It really can't be a sci-fi game without aliens bursting through random vents.
I was thinking of a more natural generation algorithm starting by creating the entire ship, functional and with NPC's placed in their corresponding sections. IE: The Captain on the bridge, engineers in the mechanical sections of the ship, etc. Then using some rudimentary AI, the ship can be naturally altered by 'attacks', 'meteors', or whatever destroys it. Say, engineers might respond to a hull breach by first looking for some tools and EVA suits and move towards the breach. These actions might generate logs that the player can find later to give them information about the ship and equipment.
Would that be way too complicated? Obviously, the world generation algorithm is one of the most indepth sections of a roguelike.
Challenges, Environments and Enemies:
Unlike most roguelikes, I want to foster a sense of isolation and tenseness during play. So instead of running into mindless monsters every few steps that rush at you with reckless abandon, the enemies would be fewer, better organized, and rather deadly individually. Individual intelligence algorithms would be selected via genetic creation.
Anyone who's played Space Station 13 knows how deadly space can be. Oxygen deprivation, fires, electrocution, plasma leaks, radiation, crushing doors, extreme cold, the player needs to be aware of hazards and how to circumvent them.
The question is: "Is this fun?". Tell me what you think.
I thought about going to DigiPen but decided to go for a full CS degree instead.
What alternatives exist to perma death that would still create a sense of tension in the game?
Another option, would be to have some mysterious entity "rescue" the player but the player might lose some (or all) equipment. If I understand your premise correctly, perhaps at some point losing too much equipment might make wining the game impossible and you'd have to start over. Ideally you'd be able to detect this and then bring up a tombstone type screen.
I guess you could make finding out who is rescuing you part of the plot of the game. I'm not a huge fan of these. Normally it seems hard to balance. In particular they seem to encourage really broken behavior to allow easier skill ups like you said. Roguelikes, at least those with permadeath, already push people to paranoid, perhaps unfun behavior to survive at all, I'd guess adding another such burden will push things too far.
Perhaps if you are careful to only give out skillups for unrepeatable actions it might work out.
Maybe someone has played a roguelike with such a system and can give a better opinion.
This seems like a cool idea, but not an easy one to work out. I doubt it's as impossibly complicated as whatever Dwarf Fortress is doing though.
In particular, I like the idea of the game somehow generating hints as to what might be upcoming problems. The smarter and especially the more unpredictable the enemy AI is, the harder it will be to sustain permadeath. For a classic roguelike, the reaction to dying must be "Wow, that was dumb of me" much more often than it is "Wow, that was fucking unfair. Or it least has to be like that once one has built up one's character over some time.
(Please do not gift. My game bank is already full.)
Randomly generated monsters might just be too unfair. Part of playing roguelikes is learning the behavior of the various enemies so you can properly gauge the challenge they represent. But if the monsters are randomized on every playthrough, then running into monster X with immunity to whatever you just threw at it would likely result in death that was out of the player's control. But without challenges like immunities, there wouldn't be enough variance to make things interesting.
Of course if there were weapons that could pretty much overpower anything but were limited in quality, the corpses (or what's left of them) could be studied to find more economic solutions.
What about a Bioshock style regeneration chamber? All equipment could be left wherever the player died with possibly some additional penalty. Different modes probably wouldn't be very hard to implement under that system.
Easy: Unlimited use of regeneration chambers. No Penalty.
Medium: Regeneration chambers need limited quantity resources to operate. Lose equipment, hunger, and character advancement.
Hard: Permadeath.
Another idea is to take a page from Valve and monitor how well the player is doing. You can adjust loot drops and enemy spawning accordingly.
I like how Dungeon Crawl Stone Soup handles use based advancement. In addition to traditional leveling up your stats, you gain skill points from defeating monsters. Actions automatically spend these on appropriate skills. Players can turn off spending skill points on skills they choose in a menu, but they never get the opportunity to actively grind up a specific skill by a significant amount, because the points will run out.
It isn't necessarily complicated, but it could be a lot of work. You probably don't want to implement all of those features right away, so you'll have to set up a nicely generalized system that allows for new types of data generation to be easily added in as you develop them.
You might have some experience with logic programming and how you can instantiate a tree from root goals into ever more specific literals using a tree traversal algorithm. World generation can work quite like that, having a general model of the world as a start as your root and adding subnodes onto it as you try to make the general properties more specific. Once everything is resolved and saved to disk, the structure can serve as a sort of scene graph for the game itself, allowing you to selectively load branches of it back into memory based on the player's position in the tree.
For example, you might start out with the general purpose of the vessel (research, military, transport), its size and crew number at the root node. From there it can instantiate deck types and dimensions. Then you can start filling the deck with rooms and hallways. Under the room level you start filling in the actual position and types of tile, objects and crew members that fit the type of room and its purpose.
Adding another type of deck, tile or vessel should ideally only involve code changes at the levels they are instantiated.
I think environmental and engineering challenges can make up for the 'lack' of enemies. In Spelunky, traps and falls can be much more dangerous than most enemies and are just as common. In essence they are simple static challenges with short, simple solutions that are still dangerous if you fuck up. Spills, gases, electricity, fire, radiation, people deal with these problems in a myriad of ways in real life that could translate well into a roguelike.
Randomization might throw a spanner into offering an obvious solution to the player, you might implement a metaphorical 'bomb' or 'hooked rope' that allows them to circumvent these situations. Like having those crawl spaces between decks might help players take a long way around any hazard.
Subtly announcing something is about to give a player a hard time (like the music in L4D or the situational quips on level entry in Spelunky) is a great way of building tension and expectation. It also helps prevent the 'came out of nowhere' feeling deaths can have in games.
The goal is simple: you are a samurai tasked with destroying a powerful demon lord. World travel takes place in an overhead view similar to Dragonquest, but dungeon crawling is done in first-person ala Might & Magic.
Nah, chances are there would be 4-6 zones, each one acting as a level. The question is: do I want it to be about 1 hour long without save points, or about 5 hours long with save points? The goal would be to have a replayable RPG.
I have zero programming skills or experience.
Godspeed, Ironsides.
Like the level generation in Etrian Odyssey? It might be interesting to combine a short story with lots of branches with randomized elements to make replays even more fresh. 5 hours is pretty long for a replayable game, in my opinion. Will it have permadeath?
The one list of "easy/medium/hard" seems strange to me, besides prior experience, ive found it rough making this kind of list because you dont know what your hitting until you really start getting into it. I can understand making a list by importance though, and thereby what you want to tackle for to make sure you can get it done and working properly.
Would most of this be considered part of the design document? if so how much of said document are you expecting to get out of this? Ive seen 1 page to 100 page docs on games, just curious whats going on so far
After nearly ten years of programming, I've kind of got a knack for figuring out just how involved something is going to be.
Can you send me that Game Design Document, Cymoro? Every one I find focuses more on marketing, trends, and cost analysis then fleshing out the concepts.
Right now, I think I just need to design each subsection enough that I can design interfaces for the architecture. Like the map generation system, it's not really important when it comes to the overall design. Any number of generation routines can be dropped into it using the exact same call.
I always seem to fall back on a Control style pattern but is there anything more efficient I should know about? Control patterns have all the various modules work through a central class instead of talking directly to each other to reduce the complexity of the program.
I wonder if I can design AI like so:
Encapsulate each AI idea inside a class derived from a AI decision class. Each subclass can analyze the current Mob's state including the surroundings that the mob is aware of and any memories implanted in it (IE: The player just rounded that corner but I can't see them anymore)
class testclass
{
double analyze(State x)
{
if (x.whatever)
return 1.0;
else if(x.something else)
return 1.7;
...
return 0.0;
}
AI_Action perform(State x) {...}
}
Then each AI can keep an array of weighted decision classes, run through them on their turn, and make a choice based on whichever decision has the highest value. This design would work pretty well using a genetic monster creation system I would think.
Starcraft 2: jawaka.947
Speaking of design documents, are they really the standard anymore? I obviously have no professional experience, but it seems like you can't go a week on gamasutra without another article about "scrum" or whatnot. Obviously I would like to see them remain, but I can't be certain they will.
You write...six hundred page design documents?
I'm going to be taking a break for a few days, I really need to figure out what I'm going to do with my life now and I'm kind of running around in circles. Seriously, I'm like that AI that got outwitted by Captain Kirk.
Well, not THAT long. I don't write 0 page documents, either. My longest one is currently at 518 pages and still needs more work, but it's one of those RPG epic types, so I have to make lists of enemies, bosses, spells, items, etc. And I tossed in a couple of pages of dialogue for every chapter of the plot to help me get the characters more. Most of my ideas are more reasonable. My favorite one is "only" 160 pages pre-index.
You seem to have a pretty good idea of what you want, so you should go for it.
Regarding your method (please take this as constructive criticism): Are you trying to figure out all of the requirements in detail before writing a single line of code? Because that's not agile, that's the good old waterfall. Agile would be to figure out the absolute minimum piece of functionality you need implement to call the thing usable and then do it as a first iteration. This first iteration is going to be pretty barebones but it's stable and it's usable.
After that you set a few new goals that you want to have in there, implement them and after a short time (two weeks max) you're going to have a little bigger game, which is again stable and usable. Rinse and repeat.
The point is basically that you admit to yourself that you simply can't design it all at once, so you just do very small steps. You will always have something stable and usable that you can base your work on. Since you don't want your code to be a horrible mess you constantly refactor it. Always just implement what needs to be done now and do that in a nice and clean manner so you can change your code according to new requirements easily. Don't overdesign by fooling yourself into thinking you can actually design for yet unknown requirements.
Of course, the more use cases you have from the very beginning the better but I would honestly try to pick the most basic ones from the ones you have, flesh them out and then start coding. In this example I would pick the following:
1. Tiles generated from ascii characters
2. Seperate game window, status line, and character statistics
This is going to be hard enough to do because you need to answer a lot of questions:
And there are a lot more. Once you have this done you have a way better idea of how to continue and if you find out you got something wrong, it's not that much of big deal because so far you haven't put too mich time in it.
Anyways, good look with your endeavour :^:
I'm not figuring out ALL the requirements.
As for your questions: Java, Java, Java, all of the above, that's in the list.
I just need to take a few hours and make a design I'm happy with. Been busy the last couple of days so I've been avoiding this a bit.
Yeah, I think I need to dive back into my Software Engineering books for a day. Everything seems so rusty for some reason and I'm fairly certain I'm doing it wrong. I really shouldn't embarrass myself in front of all the experienced programmers on the forums.
Edit: Stick figures are the Universal Modeling Language symbol for 'actors'. Kind of funny considering how abstract everything else seems to be.
A handy rule of thumb of what a good use case is, is whether an average user can use it as a step by step guide to test your program. Technical details that are specific to the implementation and not relevant to user interaction are thereby excluded.
There is a school of thought that likes to model program execution the same way as user interaction (as a step by step if-then-else guide). In my opinion, that method of description falls short of the level of abstraction that is possible in modern programming languages, especially considering concurrency and object orientation.
(although I completely support the idea of this thread since I'm currently writing my own XNA game)
He uses a very sophisticated method, comparing the success of a simulated player using random actions with one using a learning algorithm playing game more intelligently to gauge how fun (learnable) a design is. The 'fun' amount is then used as the fitness of a ruleset in the learning algorithm of the ruleset generation.
While designing a learning algorithm that will play a roguelike similarly to a human player is too tall an order, you might compare the statistics of how well players do facing a monster with a randomly playing simulated player, or a human player that has played the game less often.
Having a server that gathers the statistics of all players (without leaderboards to discourage spoofing results) would be neat regardless of whether you use them to tweak your gameplay. Recording how a roguelike plays out shouldn't take up much space, so if you do want to have leaderboards you could use game recordings as a way of checking whether a result was valid. If all the 'dice rolls' are deterministic (seeded by the turn counter for example), you could even automate checking the results.
o_O That seems like a lot of work. Feature bloat alert! I did work a bit on the architecture despite all the cries of more design time. At this point, I guess I'm just weak willed but I think I have enough of the design down that I can get to work. And it'd take me a while to remember how to do all the documentation properly.
I guess I can just point out design decisions as I go along.
Goal 1: Create enough code to complete a simple 10 x 10 room with floors and walls.
I started by laying out my architecture in Java packages, splitting the program into what I imagine would be logical units in the future.
Control (Experimental Design)
I want to try splitting the Control class into two seperate entities. One to hold all the objects and the other to provide a library of functions which classes can use to talk to other classes. I may end up merging them back together if this is too unwieldy, but control classes tend to get HUGE. And I may be able to write up more than one 'control' class to talk to.
Data Types:
This package does nothing but hold classes that are designed to encapsulate various data types that are not currently in use by Java. Simple things like a 3 point coordinate (may already exist), a space that holds objects (think tile), and a three dimensional collection of spaces, I called it an environment, that can be used to represent a subset of the ship (including its whole).
None of these classes are very involved so they're being stuck in a package and out of the way.
Engine:
Right now, my idea for the design of this is very simple. It will keep a <list> (undecided what actual implementation yet) of 'active' objects in the ship, then every tick it will generate a local environment (using another unspecified class) and pass it to that object to make changes. Each individual object will have the power to make changes to the area around it.
File I/O:
Reserved for the saving and loading routines. Considering that we can have nested inventories and such, saving may be a little more involved than first thought. 'Serialization' seems to be the easy answer to this problem, but I'll have to look into it. But this would necessitate that every object get its own unique ID because you can't serialize references I believe.
Generation:
Eventually, the complex ship building algorithms will fit in here. Right now, it just holds the test class for the goal specified above, a 10x10 room without air or any of the other fancy systems to come later.
Object Library:
This is probably the most complex package as the root package contains classes that are superclasses for its sub-packages. This root class, coincidentally named Object, holds all the members that are found in every npc, monster, item, and piece of the ship. Things like a name, how much it weighs, how much it can hold, whether it's passable or not, can you see through it, what temperature does it set on fire, etc. As well as functions that every object should have, like 'perform action' for the engine.
The reasoning for having this base class is for polymorphism. Instead of having to keep a seperate list of every monster, every wall, every syringe, we can keep everything uniform.
Current Subpackages:
Ship Parts
Holds entities like various walls, windows, panels, computers, etc. We'll need to define a wall and a floor space for our test run.
NPCs
Monsters, friendly people, etc need to go in here. Each category will likely get their own sub-sub-package
Skills
This seemed like a good a place as any. Skills represent the actions that objects use to manipulate their environment. Each skill will pass along a copy of the environment, a list of 'targets' to perform the skills on and it will make changes to the environment as necessary. I'll probably end up splitting this one up into various categories as well.
User Interface
This should be pretty standard stuff here. After Goal 1 is reached, this will likely be the next phase of development. Create a player character and move it around the room, making sure it is blocked by walls. I'll see if I can whip up a class diagram later, hopefully correctly.
Alright, so there's a room with floors and walls using what I hope are the final classes for these particular entities. This particular example was a bit more complicated then it had to be because it actually makes use of the environment->space->contents architecture. In the final test, I defined a 10x10x5 environment with different configurations of walls and floors and the output I generated from the space's contents proved correct.
The next goal is to create a functional prototype of the user interface, and basic movement for a character in the above environment. Would it be too crazy to include movement as a skill? This would certainly streamline everything into the same flow.
Example:
public move(data_types.Environment area, java.util.ArrayList<object_libary.Object> targets, data_types.Coordinate pos) { //Target 1 would be the object to move //pos would indicate where the target would be moved to, this should be exactly 1 tile east, west, south, north, up, or down movement. //Teleportation should also be possible using this system }