As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options

[Make On] The Journey to Write a Game.

ValkunValkun Registered User regular
edited January 2009 in Games and Technology
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
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 Risk

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.

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

Posts

  • Options
    ZombiemamboZombiemambo Registered User regular
    edited January 2009
    GameMaker is decidedly limited but I've seen a number of quality games come from it and its peers (Multimedia Fusion, for example). I have some sprites I've been messing around with, trying to come up with an idea. If anything comes from it I might participate in this thread.

    For now, though, sleep.

    Zombiemambo on
    JKKaAGp.png
  • Options
    ObsObs __BANNED USERS regular
    edited January 2009
    We could make a BYOND game really easily. I propose a time limit of 7 days to make a game from start to finish.

    Obs on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Step 1b - Identifying High Risk Requirements

    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.
    I.  Engine
    	A.  Graphics
    		[COLOR="Lime"]1.  Tiles generated from ascii characters[/color]
    		[COLOR="Lime"]2.  Seperate game window, status line, and character statistics[/color]
    	B.  File Storage
    	C.  Level Generation
    		[COLOR="red"]1.  Design ship layout[/COLOR]
    		[COLOR="Lime"]2.  Place crew[/color]
    		[COLOR="red"]3.  Run and apply generation scenario[/COLOR]
    		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
    		[COLOR="red"]1.  Store energy for using actions
    		2.  Both energy and time needed to perform actions[/COLOR]		
    		[COLOR="Lime"]3.  Hunger reduces energy generation and maximum energy storage[/color]
    		[COLOR="red"]4.  Run time in 1 second (in game) quantum[/COLOR]
    II. Environment
    	A.  Air Composition
    		[COLOR="Lime"]1.  Need oxygen at all times to live.[/color]
    		2.  High concentrations of certain gasses can have side effects.
    		[COLOR="Lime"]3.  Air can be stored in tanks or created by certain equipment.[/color]
    		[COLOR="red"]4.  Gasses must be able to flow and equalize in the map[/color]
    	B.  Heat
    		[COLOR="Lime"]1.  Cold from space/certain equipment causes damage[/color]
    		2.  Fires, equipment, and certain entities can cause damage or set things on fire
    		[COLOR="Lime"]3.  Clothing and equipment can counteract heat variances[/color]
    		[COLOR="red"]4.  Heat must be able to transfer to its surroundings[/color]
    	C.  Pressure
    		[COLOR="Lime"]1.  High or low pressure can cause damage[/color]
    		[COLOR="Lime"]2.  Counteracted by proper equipment[/color]
    		3.  Can affect flamibility
    		[COLOR="red"]4.  Pressure must flow naturally to equalize in the map[/color]
    	D.  Light
    		[COLOR="red"]1.  Produced by fire, equipment, and certain entities[/color]
    		2.  Lack of light reduces the sight range of the player and NPC's
    		[COLOR="Lime"]3.  Can be counteracted through the use of alternative sight equipment (e.g. infrared, light amplification, etc)[/color]
    	E.  Electricity
    		[COLOR="Lime"]1.  Causes damage if directly exposed[/color]
    		[COLOR="Lime"]2.  Can be insulated against with proper equipment[/color]
    		[COLOR="red"]3.  Needed to run ship systems
    		4.  Transferred via power lines throughout the ship[/color]
    		[COLOR="Lime"]5.  Generated by internal engines, solar panels, or other sources[/color]
    	F.  Fire
    		[COLOR="Lime"]1.  All objects have a flamibility rating (temperature)[/color]
    		[COLOR="Lime"]2.  Must have oxygen to start[/color]
    		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
    		[COLOR="Lime"]1.  Acid[/color]
    		2.  Air borne bacteria
    		[COLOR="Lime"]3.  Radiation[/color]
    III.  Character
    	A.  Generation
    		1.  Life Path
    	B.  Statistics
    		[COLOR="Lime"]1.  Qualitative[/color]
    		[COLOR="Lime"]2.  Each limb individually tracked for health[/color]
    		[COLOR="Lime"]3.  Standard RPG statistics: strength, agility, etc[/color]
    		[COLOR="Lime"]4.  Hunger[/color]
    	C.  Inventory
    		1.  Gear can be worn on both hands, torso, legs, feet, pockets, held in either hand, and slung on the back
    		[COLOR="Lime"]2.  All objects have a volume and weight characteristic that limits what they can fit inside[/color]
    	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
    		[COLOR="red"]1.  Created from random genes[/color]
    		[COLOR="Lime"]2.  Variances exist within the same monster class[/color]
    		3.  Each class of monster will have a randomly generated name and icon associated with it
    	B.  Pirates
    		[COLOR="Lime"]1.  Human[/color]
    		2.  Do not necessarily speak same language
    		3.  Can be friended given proper actions
    	C.  Cultists
    		[COLOR="Lime"]1.  Assigned to one or more alien species[/color]
    		[COLOR="red"]2.  Possible 'magical' abilities[/color]
    VI.  Mechanical Systems
    	A.  Computers
    		[COLOR="Lime"]1.  Each subsystem will likely have one or more computer terminals to control them[/color]
    	B.  Life Support
    		[COLOR="red"]1.  Responsible for maintaining air pressure, composition, and temperature[/color]
    		2.  Highest priority for electricity
    	C.  Power
    		[COLOR="Lime"]1.  Generates electricity for use by other systems[/color]
    	D.  Doors
    		[COLOR="Lime"]1.  Locked via key cards or pass codes[/color]
    		2.  Can be opened using hacking, force, explosives, etc
    		[COLOR="Lime"]3.  Force Fields only appear when section is powered[/color]
    	E.  Equipment
    		1.  Found throughout the ship
    		[COLOR="red"]2.  Functionality is randomized at the beginning of game[/color]
    		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
    		[COLOR="Lime"]3.  No enemies are found here unless they move in from elsewhere[/color]
    	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.  Nuclear Arsenal
    	T.  Generation Notes:
    		[COLOR="red"]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[/color]
    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
    

    Tomorrow: Step 1c - Use Cases, how to turn requirements into something a little more understandable.

    Valkun on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Step 1c - Use Cases

    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. D:

    Valkun on
  • Options
    freakish lightfreakish light butterdick jones and his heavenly asshole machineRegistered User regular
    edited January 2009
    This is relevant to my interests. I hope to do something like this sometime when my coding skills are a little stronger.

    :^:

    freakish light on
  • Options
    DavionDavion Registered User regular
    edited January 2009
    Valkun wrote: »
    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. D:


    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.

    Davion on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    The last large project we did, we spent half the time just doing design work. We didn't write a single line of code for almost two months.

    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.

    Valkun on
  • Options
    DavionDavion Registered User regular
    edited January 2009
    Last major project I worked on we didn't start working on the design document until we were about 60% done with the game. Then we spent about two months staring at a private Wiki typing up crap we should have typed up a year prior.

    It was horrible.

    Davion on
  • Options
    CymoroCymoro Registered User regular
    edited January 2009
    Step one is Make A Game Design Document. It's what every company does, and it's where you should start. I believe you can find some example ones on Gamasutra, I'm not sure. If not, I'll upload mine from my freshman game at DigiPen.

    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.

    Cymoro on
    i am perpetual, i make the country clean
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Now that I think about it, I'm not omniscient. It'd probably be a good idea to refine the idea first before throwing out a bunch of requirements. D: So I'll throw out some topics and you, my peers, can help me further develop them. Otherwise, I know I'm going to forget things and be frustrated by them later.

    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.

    Valkun on
  • Options
    lowlylowlycooklowlylowlycook Registered User regular
    edited January 2009
    Valkun wrote: »
    Now that I think about it, I'm not omniscient. It'd probably be a good idea to refine the idea first before throwing out a bunch of requirements. D: So I'll throw out some topics and you, my peers, can help me further develop them. Otherwise, I know I'm going to forget things and be frustrated by them later.

    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.
    The easiest thing is to have permadeath but have an option to allow saves if someone just wants to play around. Might also be possible to change this after you find how your game plays or is balanced.
    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.
    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.
    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.
    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.
    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. :lol:

    In particular, I like the idea of the game somehow generating hints as to what might be upcoming problems.
    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.
    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.

    lowlylowlycook on
    steam_sig.png
    (Please do not gift. My game bank is already full.)
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    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.

    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.
    The easiest thing is to have permadeath but have an option to allow saves if someone just wants to play around. Might also be possible to change this after you find how your game plays or is balanced.
    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.

    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.

    Valkun on
  • Options
    peterdevorepeterdevore Registered User regular
    edited January 2009
    Valkun wrote: »
    Death, my thoughts:
    What alternatives exist to perma death that would still create a sense of tension in the game?
    I think time(turn) limits can be intense if you do them right. It would be hard to do them right though, because of all the variables of how long something could take in a roguelike. A scifi setting gives plenty of scenarios for them to pop up: radiation, limited air or self destruct sequences for on the short term, and maybe diseases or mutations from human made or alien virii, nanobots (like corruption points in ADOM?) for on the long term. Personally I don't like long term time limits though. I did love the Pit in Fallout 1
    A nuked military base. Highly irradiating, but also chock full of goodies. You wouldn't die straight away if you spent too much time in it, but a short walk out of the gate. A sort of modern version of the curse of King Tut.

    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.
    Valkun wrote: »
    Character Advancement:
    use based character advancement
    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.
    Valkun wrote: »
    Level Design, How to create beauty out of chaos:
    Would that be way too complicated? Obviously, the world generation algorithm is one of the most indepth sections of a roguelike.

    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.
    Valkun wrote: »
    Challenges, Environments and Enemies:
    Unlike most roguelikes, I want to foster a sense of isolation and tenseness during play.
    The question is: "Is this fun?". Tell me what you think.
    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.

    peterdevore on
  • Options
    ZombiemamboZombiemambo Registered User regular
    edited January 2009
    Alright so I have a basic idea. No idea if I'm going to actually do it, but if I made a game this would probably be a candidate.

    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.

    Zombiemambo on
    JKKaAGp.png
  • Options
    peterdevorepeterdevore Registered User regular
    edited January 2009
    As long as you don't make it as hideously long as Anvil of Dawn and lots of those first person crawlers were, I'll certainly play it. Lands of Lore is one of my favorite games, although that might be more due to the graphics, story and nice voice acting (Patrick Stewart!). That game was terrible at telling you what items did. And it had the first person crawler classic 'level that doesn't automap'. If you value my sanity, please don't do those things :)

    peterdevore on
  • Options
    ZombiemamboZombiemambo Registered User regular
    edited January 2009
    As long as you don't make it as hideously long as Anvil of Dawn and lots of those first person crawlers were, I'll certainly play it. Lands of Lore is one of my favorite games, although that might be more due to the graphics, story and nice voice acting (Patrick Stewart!). That game was terrible at telling you what items did. And it had the first person crawler classic 'level that doesn't automap'. If you value my sanity, please don't do those things :)

    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.

    Zombiemambo on
    JKKaAGp.png
  • Options
    Jedi_BoiJedi_Boi Registered User regular
    edited January 2009
    I thought you meant write a game...with words...Because I would love to do that.

    I have zero programming skills or experience.

    Jedi_Boi on
    i.imgur.com/DG7Jj7H.jpg
    Godspeed, Ironsides.
  • Options
    DarmakDarmak RAGE vympyvvhyc vyctyvyRegistered User regular
    edited January 2009
    You can always check out this thread to learn how it's done.
    I'm so sorry.

    Darmak on
    JtgVX0H.png
  • Options
    peterdevorepeterdevore Registered User regular
    edited January 2009
    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.

    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?

    peterdevore on
  • Options
    DiannaoChongDiannaoChong Registered User regular
    edited January 2009
    I am enjoying reading this process so far, I dont want to see it dipping to page three.

    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 :)

    DiannaoChong on
    steam_sig.png
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    I am enjoying reading this process so far, I dont want to see it dipping to page three.

    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. :lol: Unless I find a really nice Game Design Document template, I'll probably write a Vision Document, a Software Requirement Specification, and a Software Design Document. How robust I make them still needs to be seen.

    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.

    Valkun on
  • Options
    Sir CarcassSir Carcass I have been shown the end of my world Round Rock, TXRegistered User regular
    edited January 2009
    I keep reading that as "class testicles"

    Sir Carcass on
  • Options
    CapuanoCapuano Registered User regular
    edited January 2009
    Hey, this is really cool and helpful, too. Good luck getting it done. Even if you do crash and burn, it's still a learning experience, right?

    Capuano on
    1372374-1.png
    Starcraft 2: jawaka.947
  • Options
    ObsObs __BANNED USERS regular
    edited January 2009
    Look guys, you should spend about 60% of your time on Design, 15% on graphics, 5% on testing, 20% on coding.

    Obs on
  • Options
    EmperorSethEmperorSeth Registered User regular
    edited January 2009
    As a dreamer looking to make a game of my own, I would like to help. I'm a bit different, though, in that I'm 29, and thus much more cynical and bitter. I'm increasingly considering going back to school around August of this year; I graduated with a computer science major in 2001, but honestly I don't like programming that much. My favorite game creation aspect is the writing, and I'm less experienced as a level designer, but I enjoyed it when I tried; I just haven't found as much motivation to do that instead of, say, continue writing my 300+ page design documents (okay, they tend to vary from that number by several hundred pages, but still,) or personal issues like trying to get a love life.

    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.

    EmperorSeth on
    You know what? Nanowrimo's cancelled on account of the world is stupid.
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    As a dreamer looking to make a game of my own, I would like to help. I'm a bit different, though, in that I'm 29, and thus much more cynical and bitter. I'm increasingly considering going back to school around August of this year; I graduated with a computer science major in 2001, but honestly I don't like programming that much. My favorite game creation aspect is the writing, and I'm less experienced as a level designer, but I enjoyed it when I tried; I just haven't found as much motivation to do that instead of, say, continue writing my 300+ page design documents (okay, they tend to vary from that number by several hundred pages, but still,) or personal issues like trying to get a love life.

    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? D:

    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.

    Valkun on
  • Options
    EmperorSethEmperorSeth Registered User regular
    edited January 2009
    Valkun wrote: »
    You write...six hundred page design documents? D:

    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.

    EmperorSeth on
    You know what? Nanowrimo's cancelled on account of the world is stupid.
  • Options
    ShaquarShaquar Registered User regular
    edited January 2009
    I've been toying with the idea to write roguelike for a few months. It's the only kind of game I could possibly do all by myself since I'm a coder and absolutely no artist.

    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:
    • Which platforms should it run on?
    • Which language are you going to use?
    • Which technology are you going to use (SDL, DirectX, WPF, blablabla)?
    • Fullscreen? Fixed size window? Reconfigurable window?
    • What goes into the characters statistics? Level (do we even have levels)? Which attributes does he have?

    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 :^:

    Shaquar on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Shaquar wrote: »
    I've been toying with the idea to write roguelike for a few months. It's the only kind of game I could possibly do all by myself since I'm a coder and absolutely no artist.

    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:
    • Which platforms should it run on?
    • Which language are you going to use?
    • Which technology are you going to use (SDL, DirectX, WPF, blablabla)?
    • Fullscreen? Fixed size window? Reconfigurable window?
    • What goes into the characters statistics? Level (do we even have levels)? Which attributes does he have?

    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. :lol: I'm identifying the hardest (in terms of complexity) requirements so that the architecture I design doesn't need to be rewritten over and over again.

    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.

    Valkun on
  • Options
    ZombiemamboZombiemambo Registered User regular
    edited January 2009
    I don't actually want to program a game but at the same time I want to make some sort of abstract game, kind of like Space Giraffe (but not at all like Space Giraffe). As of late I've been more interested in games that aren't about fun, but might be visually/audibly pleasing.

    Zombiemambo on
    JKKaAGp.png
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Edit: Removed because it is flawed!

    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.

    Valkun on
  • Options
    peterdevorepeterdevore Registered User regular
    edited January 2009
    Use cases and diagrams are good for designing GUIs but they should never touch any part of the system that isn't directly visible to the user. They should describe the flow of control between menus and possible actions, not the actual flow of control your program is taking. It's tempting to put in actors and steps in use cases that describe how you see the system working behind the scenes in reaction to the actions (like 'permanent memory' and the step 'perform time cycle'), but that's not the goal of making use cases.

    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.

    peterdevore on
  • Options
    ChewyWafflesChewyWaffles Registered User regular
    edited January 2009
    That's not even remotely a use-case diagram :)

    (although I completely support the idea of this thread since I'm currently writing my own XNA game)

    ChewyWaffles on
    mwf2sig.jpg
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    That's not even remotely a use-case diagram :)

    (although I completely support the idea of this thread since I'm currently writing my own XNA game)

    :lol: Guess I better go hit those books.

    Valkun on
  • Options
    peterdevorepeterdevore Registered User regular
    edited January 2009
    The genetic evolution idea you have for monster behavior is really neat. This guy uses a similar system to evolve the rules of a complete game, which might give you some ideas on implementation and testing the fitness of new generations.
    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.

    peterdevore on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    The genetic evolution idea you have for monster behavior is really neat. This guy uses a similar system to evolve the rules of a complete game, which might give you some ideas on implementation and testing the fitness of new generations.
    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.

    Valkun on
  • Options
    ValkunValkun Registered User regular
    edited January 2009
    Goal 1 Successfully Completed.

    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
    }
    

    Valkun on
Sign In or Register to comment.