Advertisement

another design doc for the forums

Started by May 09, 2002 04:28 AM
5 comments, last by Overload 22 years, 7 months ago
Yes its another design document, so why not read it, give me some tips on how to improve it or criticize it for all its worth. Its not finished yet, I just wanted someones opion on it. TITLE: _______________ (if you can think of one let me know) GENRE: Mixed (which do you think?) Setting: Middle ages 1 Backstory 2 Overview 2.1 THE POINT 2.2 THE GAME IN SHORT 2.3 UNITS 2.4 BUILDINGS 2.5 PLAY OPTIONS 2.6 RULES OF PLAY 1 BACKSTORY: Once a giant kingdom ruled over all of the lands we call home. This kingdom was very powerful, and rich it established trade routes through-out the land. But one year a plague swept through, killing everything except the plants. With no people to take care of the buildings they soon were turned into rubble. For five years no creature passed through the land, and in that time the land regenerated. Then humans and animals started to filter back into the land. After a while, tribal groups started to form over the land. One of those groups became our, victorious clan. (well, its better than nothing) 2 OVERVIEW: 2.1 THE POINT The point of this game is to give the player a feeling that he/she is actually in the game. 2.2 THE GAME IN SHORT You take the role of a clan leader. You can establish a city or try to convert NPC's to join your side, and you are able to give anybody on your side a range of orders to do your bidding (menu driven) . From millitary to peasantry tasks. Also the ablity to play from a first person view will help you co-ordinate attacks against your enemy, or see how your citizens are going, close up. 2.3 Units Peasant Peasant-milita Peasant-mounted Foremen Noble Tax collector Tax collector-armed Trader Trader-mounted Armed escorts Swords men Swords men-mounted Thief Thief-mounted Thief-armed Hostage taker Hostage taker-mounted Slave driver Archer Archer-mounted Town crier Entertainer Ram Catapult (if you can think of any more that would be a help) 2.4 BUILDINGS Fire Tent Large tent Village centre peasants" (the < representing a button used for decreasing the number, the 00 meaning the number (left as 0 for this example) and > representing a button used for increasing the number.) the player clicks the > button four times and clicks OK. Then the peasant, two idle peasants and the two closest non-idle peasants (because of the fact that there are no other idle ones) goes off to a near-by forest, builds a lumber camp (if there is not one within 8cm of the forest). The player waits until he has 50 wood and then the player right clicks on other of his teams units and the words again come up "gather wood", "build something" ect. The player selects "build somthing. A new box comes up "Peasant: what would you like me to build?" and under it a box with about 20 buildings in it, 15 are "grayed out" (not available) the player selects one of the five buildings (the house) and selects OK, once again another box appears with the words "build a house with <00> peasants" the player leaves the counter at 00 and selects where the building will be built, the one peasant goes and builds the building and everybody is happy. (note: It will not take as long as it did reading this to do the tasks mentioned here in the game). (I think this should be in an interface section, but I wanted to explain some gameplay) [edited by - overload on May 10, 2002 7:27:44 AM]
You''ve said nothing about actual gameplay,
it is hard to imagine what your game will be like.
Please post more info.
Sounds interesting so far...
Advertisement
Remember that the point of a design document is to provide a reference that a development team can look at, and from that build a complete game from the information in the document. You need to put a little more meat on them bones. =)
Design document can never be truely complete. You have to start with a game summary, then you break it down into several parts and describe them in more details. Repeat the process recursively until you get actual code that compiles and runs correctly.

Here's what I had to do in order to define such a thing as "power generator". If you read everything below you should get a pretty good idea of what I mean by that term.

1. Space Simulation



1.1 Space Ships
1.2 Space Stations
1.3 Space Environment
1.4 Asteroid Mining

The space simulation aspect of this game was inspired by other games of this genre, such as Elite, Privateer, and EVE. The scope of the game is a galaxy of about a 100 stars, a lot of big nebulas and asteroid fields, plus a few black holes. This game will use all the space phenomena as space terrain, which will make space terrain for space ships almost as important as planet terrain for land units.
Players and NPCs will have a wide variety of customizable ships to play with. Ships will often organize in various fleets. The biggest fleets will be the empire military fleet, smaller fleets will belong to individual rulers of kingdoms and various commercial organizations. And some fleets can be formed temporary by people with a common goal. In general, there will be plenty of room for strategy and tactics involving groups of ships, rather than having “every man for himself.”
There will be space stations that act as supply outposts for space ships, they also can serve as military fortresses. Space ships will be of many different sizes, from small fighter-like ships to those that are no less than mobile space stations (which are gonna be huge). Besides fighting, space pilots may engage in asteroid mining, military scouting, and treasure hunting (for rare asteroids full of precious elements)

-----------

1.1 Space Ships



1.1.1 Movement of ships.
1.1.2 Standard ship guns.
1.1.3 Detailed equipment description.
1.1.4 Damaged Equipment.
1.1.5 Ship concepts.
1.1.6 Ship interfaces.
1.1.7 Drones.
1.1.8 Special guns.
1.1.9 Special ships.
1.1.10 Retrofitting and Upgrading.

Space ships play a very important role in this game, most of it focuses on fighting, but there’s also exploration, trading, scouting, and transportation. Space combat in this game is a mixture of FPS and RTS. I can split the nature of space simulation into several elements:
Physics: Physics of the game will be partly Newtonian, so there will be such things as acceleration, inertia, and friction. Ships will be able to achieve very high speeds by accelerating in one direction for a long time. However, unlike in Newtonian physics, acceleration in our game will decrease in direct proportion to current speed in the same direction. What does this imply? It just implies that flying will be a little trickier, more realistic, than in some other space games. In my opinion, such a physics model allows for higher variety in tactical combat maneuvering.
Customization: The ships in game are highly customizable. There is a wide variety of equipment to choose from, such as guns, scanners, armor, and other devices. Each equipment type also has a “tech level” that determines how good the device is. The general rule is that as quality of a device increases, the cost of this device increases exponentially. What does this imply? First of all, it’s always fun to customize stuff, people who are really into space combat will advance thru the game by upgrading their ships. A wide variety of equipment will make combat more interesting, people will be specialize in particular areas, such as stealth, maneuverability, firepower, and weapon choice. Also, the fact that cost of better equipment will be increasing exponentially means that not every rich guy will buy the best possible equipment, people would often choose to buy less expensive items.
Small Ships: The majority of ships in the game are going to be small, relatively speaking. These ships are easy to fly, controls will be similar to all the classic space sim games. The smaller the ship, the faster it can accelerate, which means that small ships will tend to be the fastest and most maneuverable ships. What does this imply? New players will get the smallest ships, while they won’t have much fire power, their ships will be among the fastest and most maneuverable ones. Life of newbies will be a little easier and more interesting due to this. Also, the fact that small ships have a considerable maneuverability advantage over bigger ships, players will not always want to buy a bigger and more powerful ship. This balance of power is good for variety.
Big Ships: The game will have a wide variety of ship sizes. The biggest ship will be about 250 times bigger than the smallest ship, which makes quite a difference. Big ships are very slow and can’t be flown as fighters. So all the bigger ships have different control system than the small ships. Big ships can store a lot of supplies which could be needed by small ships, small ships may dock on large ships. What does this imply? Large ships present mostly strategic value rather than tactical, since there are slow but very powerful. It’s likely that large ships will belong to groups or organizations of people, rather than individuals.
Combat: this game will try to add as much tactical and strategic value to space combat as possible. There are 3 important elements of combat:
1. Damage: there will be 3 separate damage forces, all players will have to choose how much focus they want to give to each force. They will also be very interested in knowing how much focus to each force their enemies are choosing This aspect of the game makes intelligence gathering very important, it insures the strategic value of combat before it even begins.
2. Weak spots: each ships will have tens or even hundreds of separate hit areas on the hull. So hitting a ship in the right place will be important. Each ship will have its weak spots. The most basic of them all is in the rear – the engines. So, for all ships, the weakest part is always behind. This means that the players will always try to fire at the rear of the ship. While this is nothing special for small fighter-like ships, this particular game element will be very important for all the large slow ships. Commanders of large ships will have to make important tactical decisions that can result in victory or defeat. Commanders of squadrons of small fighter-like ships will also get to play with important tactical decisions. As for ship size in general, here is a picture that shows the ship’s power balance:
Here the arrows show which ship types tend to work well against which other ships.
3. Weapons: This table shows which weapons tend to work best against which ship types:
Weapons Ships
Guns, Artillery Shuttles + Destroyers
Missiles Frigates + Cruisers
Torpedoes Heavy Cruisers + Battleships
Artillery weapons are very big, so they can be carried only by large ships. Also,
there are three types of guns and each of them has special characteristics:
Gun Type Range Impact Radius Fire Rate
Shell gun short medium-large fast
Phaser medium medium continuous
Laser long small slow
Cargo: Almost all ships will have cargo bays. Trade is a big part of this game, so many ships will be transporting stuff from one place to another. When a ship is destroyed, or has damaged cargo bay, it releases some of its cargo into space, which can be picked up by other space ships. Many space ships will tow cargo containers, as an external module, so once a ship with container is destroyed, the container itself may not get destroyed. So even fighter pilots with no cargo bays could get some reward, by towing the cargo container with their ship.
Inside Ships: Since the player plays a 3D character that can walk around on space stations and planets, the player can also walk around in his space ships. Each space ships will have a number of rooms and corridors. It will be possible for 2 ships to link together, in which case one of the ships may invade the other, people could move between the ships and fight inside the ships. If the invaders are successful, they could destroy the conquered ship or even take it over.
Other: Space ships will also have a few special guns, a few special purpose ships. Space ships can carry “drone” ships. Large ships can usually hold small ships. There will be special interfaces for people who command a group of ships, that would help them to control a group of ships better. Space ships would often use “jumpgates” and wormholes to travel, however, it will be possible to go anywhere without using those. Space ships will require fuel for energy, which will be limited.

-------------

1.1.3 Equipment description.



1.1.3.1 Thrusters
1.1.3.2 Gyro-Drive
1.1.3.3 Armor
1.1.3.4 Shield Generators
1.1.3.5 Shield Regenerators
1.1.3.6 General Scanner
1.1.3.7 Tractor Beam
1.1.3.8 Tractor Beam Reverser
1.1.3.9 Cloak
1.1.3.10 Stealth Armor
1.1.3.11 Power Generator
1.1.3.12 Unit Scanners
1.1.3.13 Anti-Unit Scanner ECMs
1.1.3.14 Hardpoint Modifier
1.1.3.15 Repair Droids
1.1.3.16 Inertial Dampner
1.1.3.17 Radar Jammer

Each equipment type will have a dedicated ship space. The size, location, and numbers of each dedicated equipment space will depend on the ship design. Equipment space is to be visualized as a 2D blue print of a ship, inside the ship’s outlines would be boxes (or compartments) that represent the rough sizes and locations of different ship equipment. Relative equipment size will be crucial to game balance, since the user will be able to create his own ship design, with only the total ship space as the limit. Some equipment will have to share the same compartment. All equipment will have size represented by width and length (measures in meters) and thickness (measured in number of “decks”). All equipment has a variable for mass. All equipment has 3 variables for maximum damage absorption, one for explosive damage, one for phaser damage, and one for laser damage. And all equipment will have three variables for current damage status. All equipment can be stored in a cargo bay if space is sufficient. All equipment must have 3D and 2D visual representation. There will be a lot of variety in equipment models, so there should be only 1 or 2 3D representations of the equipment type, not the different models of the same type. All the separate models will have 2D pictures. Note: I consider it important to have 3D model for each equipment category. Such models will be used to represent equipment floating in space, whether it was ejected cargo or leftovers of destroyed ship.


----------------

1.1.2.11 Power Generator



The most important part of the ship, it shares the same properties as power generators for planet vehicles (see 1.3 of Planet Mod). All the equipment requires power to function. For this reason, power plant will be the limiting factor that will help balance ship strength. Power pant is capable of producing internal explosion when damaged (see 5.3). Only one power plant per designated compartment space is allowed. However, some ships may have more than one power plant. The power plant has a maximum power output variable and current power output variable. I suggest that power management is done not by the power plant but by the ship itself. Since power is the main limiting factor and since player can manipulate power inputs on some devices, it is possible to run out of power, reach the maximum limit. For this reason, a list of power supply priority has to be made. The equipment at the top of my list will lose power first:
01. Cloak – if ship’s runs out of power, this would be the first device that gets turned off, if it is possible
02. Tractor beam - its next, if active of course
03. Shield Regenerators (boosters)
04. Shields Generators.
05. Rear Engines, they consume a large portion of power
06. Weapons
07. User specified power changes.
Use this as a default setup, but let the player choose the order. You have cloak on top. Maybe I am pretty bruised and want to get away. I do not need tractor beam, weapons, shields, since I will use the cloak to stay hidden.

Everything else should be somewhere at the bottom of the list. Notice that user power changes have higher priority than some of the equipment. This means that if the player allocates more power to shields when there is not enough power, that extra power will come from the engines. The player should be allowed to fixate his specified power input, so the computer will not reduce power to this equipment when there is power shortage. In other words, this particular equipment goes to the bottom of my priority list. Also note that if the player tries to allocate more power to shields while the only available power is given to something like scanners, he/she will not be able to do so. Important fact: destruction of all power plants on the ship will trigger a 1 minute count down. The player will be warned to eject from the ship. If the player doesn’t eject, his character will die. Note that is possible to have a “dead ship”, floating junk.


------- end concept design

------- start technical design

"Power Generator" will be produced by class "Generator", here's a trace of it thru the class hierarchy:


And here are 3 header prototypes for actual code:



  // serves as superclass for all equipment modules#ifndef EQUIPMENT_H#define EQUIPMENT_Hclass Physical;enum modes{	OFF = 0,	ON = 1};class Equipment : public Physical{	float efficiency;		// efficiency is associated with the process of making output from the input. 							// Some of the input energy is "lost" and never contributes to making output.							// So the percentage of energy that actually contributes to output is specified							// in this variable. Possible values range: 0.0 - 1.0	float conversionRate;	// conversion rate is associated with the rate at which input is converted into 							// output. This variable also serves as the magic number for converting input into							// output. So the whole process formula looks like this: 							// input * efficiency * conversionRate = output/unit of time	double currentPower;	// represents equipment's current energy input. It is positive if equipment requires							// energy and negative if equipment produces energy.	double maxPower;		// maximum power input	int mode;		// default modes are 0 - OFF and 1 - ON, some equipment may have additional modesprotected:	Equipment();	virtual ~Equipment();public:// ACCESSORS	inline float getEfficiency() const		// note how efficiency is effected by damage status	{		float temp = Physical::status.getHealth();		if(temp>0.2f)		{			if(temp<0.85f)				return efficiency*temp;			return efficiency;		}		return 0.0f;	}	inline const float& getRate()		const { return conversionRate;}	inline const double& getCurPower()	const { return currentPower;}	inline const double& getMaxPower()	const { return maxPower;}	inline int getMode()				const { return mode;}// MUTATORS	inline void setMode(int new_mode) { mode = new_mode;}	inline void setEfficiency(const float& ef) // invalid input will be ignored	{		if(ef>=0.0f && ef<=1.0f)			efficiency = ef;	}	inline void setConversionRate(const float& cr) // must be greater than 0	{		if(cr>0.0f)			conversionRate = cr;	}	inline void setMaxPower(const double& mp) { maxPower = mp;}	inline void setCurPower(const double& cp) { currentPower = cp;}// SPECIAL functions:	void turnOff(double& power_grid);	// "mode" set to 0, current power set to 0, power_grid updated	void changeCurrentPower(double& power_grid, const double& power);	// "power" is the increment to			// "currentPower". So if it's positive, we increase energy, if negative, we decrease it			// "power_grid" is updated accordingly												};#endif  


the Power Source class now is pretty empty, I'll probably remove it from the class diagram. So here's Generator:



  // Programmer: Fig//   This class is responcible for generating all the possible Power Generators.#ifndef _GENERATOR_H_#define _GENERATOR_H_class Equipment;class FuelPile;class Generator : public Equipment{	FuelPile* fuel_ptr;		// shortcut pointer to fuel which this generator is using	unsigned long fuelUniqueID;	// used for validation		/* conversionRate */	// this is inherited from Equipment. In case of Generator, it represents							// the speed at which energy is extracted from a block of fuel							// This will be measured in "energy units per milli-second"							int consumedFuel;		// counts the number of consumed fuel blocks. It's useful in updating							// the fuel pile that provides generator with fuel //	int currentFuel;		// stores the number of available fuel blocks, useful for making							// sure that generator stops when it runs out of fuel	double energyPerBlock;	// stores total energy in 1 fuel block	double currentBlockEnergy;	// stores current energy in fuel blocks, it always decreases as 							// power generator burns fuel	double timeToRun;		// stores the time in milliseconds for which the generator can still run							// at current fuel supplypublic:	Generator();	~Generator();// ACCESSORS	inline FuelPile* getFuelPtr() const { return fuel_ptr;}// MUTATORS	inline void setFuelPtr(FuelPile* ptr) 	{ 		fuel_ptr = ptr;		fuelUniqueID = ptr->getUniqueID();	}// SPECIAL functions:	void setGeneratorMode(int& desiredMode, double& power_grid); // switches generator in specified mode, if possible,				// and updates the power grid. Default "modes" are 0 - OFF, 1 - ON, some generators may have additional modes	const double& getTimeToRun();}; #endif  


Of course this ain't perfect either and isn't very up to date, but I think it's a good start..


[edited by - berserk on May 9, 2002 9:26:35 PM]

[edited by - berserk on May 9, 2002 9:28:52 PM]
wow, I wasn't going to put any code in to explain everything.
Anyway as I metioned before I haven't finished yet so I'll go into more detail (I'm writing up the gameplay overview now) but I just wanted to see if people liked the idea or what could be changed. Also do you think it would be wise to put references in a brief description of the game? because people would just get annoyed at going back and forth to different parts of the doc, just when they were starting to like the idea. Can anybody think of any other units of buildings I can add?. So, I'll post more of the doc later, so if you can answer any of the questions I have inserted in the document please tell me. But for the meantime thanks for your help.

EDIT: could somebody estimate how many people it would take to make a game like this.

[edited by - overload on May 10, 2002 2:57:37 AM]
Shouldn''t code/implementation details go into the Technical Design Doc?

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Advertisement
yes, I thought I made that clear, but if not it''s pretty much common sense

important thing to realize is that "concept" design doc should always come before technical design doc

This topic is closed to new replies.

Advertisement