Praelium Game Design Document
From KruelWiki
cocachilare I stole/borrowed this layout from Chris Taylor (of dungeon keeper fame) for us to refine. see http://www.ihfsoft.com/files/docs/ctaylordesigntemplate.zip see that document for
Design History
The first recorded document I can find for Praelium was when we refering to it as 'Onus' back in mid 2001. Both names were taken from the latin, praelium was chosen because its not only did 'onus' constantly sound like 'anus' in discussions, but because having the meaning 'battle' was far more appropriate for the game.
We've started several incarnations of code thus far, with varying focuses and technologies, but until now we haven't worked towards a detailed design document.
Game Overview
Philosophy
Point #1 - Freedom in Gameplay
The player should decide how they wish to play the game. Most, if not all games focus on one key aspect be it rambo style heroics, insanely frustrating stealth missions, high DPS attacks etc. We need to carefully balance different styles, similar to classes in WoW/ D&D.
It should be left to the player to decide to play the game as it suits them. The choice to progress in the game, or to 'grind' just for fun should be available in single player games. For multiplayer games, if people want to play it as a hobby it should be just as enjoyable as for those that play it for an inhumane amount of hours a day.
Point #2 - World Interaction
Computer games are a detachment from reality, however, for a game to be sucessful it must be reasonably explained. We are not subscribing to the idea of "Magic" in praelium, so each interaction with the world and the players must adhere to a set of rules and guidelines. Physics is one such set of rules governing interaction. Other rules include behavioural modelling of the NPCs, and free-market modelling to avoid the fixed price trading that plauges so many games.
Cause and effect must be clearly evident in the game, and they must be in balance. A small causal factor should never create an excessively large effect.
An example of where the cause and effect model breaks down in some modern games is when a stray laser shot turns a previously friendly target into a foe, when the actual damage to the ship and the hostile intent was minimal as worst.
Point #3 - Community Involvement
The community of gamers that play this game should be free to suggest, create and assist in the implementation of new content. Most games have a close nature, partly for legal reasons, but the sheer volume of 3rd party add-ons for games show that people are more concerned with creating something for the game than getting paid for it.
Having groups develop mission packs would be good for the group, as they would be supported by kruel, as well as helping promote Praelium and Kruel. The community would also benifit by having additional mission packs available.
Point #4 - Rational Costing Model
The thought that people pay $100 a game for a game that will quite possibly go out of date in a few months is a large contributor to the problem of game piracy. In charging for the gaming, we must consider our target market and their spending constraints. Giving it away is also problematic in that it assigns a zero woth to the game in the minds of many people.
Charging a flat-rate per month to access a persistant world is also can be a large problem. Hourly rates act as a disincentive to play, so a compromise between these two models must be reached.
Point #5 - Maintained/ Open Code Base
If we don't release a non-trivial patch or update/upgrade in 12 months, the code should be released to the public under the GPL to allow the community to pick up where we left off.
The decision to open source has to be carefully considered, and is too big an issue to consider immediately. The current train of thought is to GPL the client and death match server, commercial licencing (be it zero cost or otherwise) for the content. The MMOG server would be either internal only, or under contract.
Common Questions
Feature Set
General Features
Multiplayer Features
Gameplay
Game World
Overview
(World Feature #1)
(World Feature #2)
(World Feature #3)
Physical World
Overview
The current plan is to find a public domain star database, and use that as a basis for us to build our own solar systems off.
Key Locations
The Sol system will remain the hub of the empire. Other key planets (and locations there on) will have to be created as we go.
Travel
The two main methods will be wormholes between systems, and FTL travel in-system, stopping for things like asteroid fields of course.
Scale
1:1, real world.
Objects
Astroid fields will be generated procedurally, similar to other non-planetoids in-system.
Time/Date
The world exists in real-time, at the current date. Technology is different but chronologically everything is the same.
Rendering System
Overview
3D Rendering
We will be using Ogre3D for managing 3d rendering.
This allows us to abstract ourselves away from Direct3D under windows and openGL on mac/lin.
GUI
Crazy Eddie's GUI (CEGUI) is what we'll be using for a gui.
It interoperates nicely with Ogre, and with our exisiting codebase has shown it's quite an appropriate tool.
Camera
Overview
(Camera Detail #1)
(Camera Detail #2)
(Camera Detail #3)
Game Engine
Overview
Collision Detection
Initially we will have collisions based on a sphere (perhaps squished) around the center of gravity.
Long term, we need to make collisions accurate, having the physics calculate things accurately to know if you really do touch someone, what equipment you might have damaged etc.
(Game Engine Detail #1)
(Game Engine Detail #2)
(Game Engine Detail #3)
Lighting Models
Overview
World Layout
Overview
See Also: Praelium Universe
Game Characters
Overview
Creating a Character
Appearance
In Praelium 1, appearance is kinda irrelevant, but having a 'face builder' will be important to build up a portrait when needed in game such as during trades and comms.
Names
Names should be limited from having prefixes such as "Sir" or "Mr" etc., and players should define their first, last names, and a handle. This means that when a player joins the military they can be addressed properly, Leiutenant LastName, or "Handle" when they're flying.
NPCs
Behaviour
Advanced behavioural modelling will be required for NPCs, so that we can balance their responses to player actions in the game
Naming
We're going to have to use some sort of algorithmic (magic number?) based way of naming NPCs.
User Interface
Overview
For our user interface, we're currently using Crazy Eddie's GUI. It works neatly with OGRE and saves us the time of making our own. We'll need to reskin it sometime before our release but thats life.
Look and Feel
The general look and feel of the GUI should be roman-esque by default.
As a player aligns themselves more strongy to different factions, the gui should change into something more appropriate. For example, if a player starts to become a real money bags, their GUI should look more efficient and "rich". If someone is a pirate, their gui should turn to a darker junk yard look. This will help us add to the immersion of someone into their chosen career, but is a low priority thing as it is merely polish and adds little to the game overall.
Crazy Eddie reports that dynamically loading a new GUI mid-game will be supported sometime in the future (est. end of 2005), but is not currently supported.
(UI Detail #2)
(UI Detail #3)
Weapons
Overview
Musical Score and SFX
Overview
Music and SFX should point towards where the player is in the game, but it should always carry an air of uncertainty about it. Space is a wonderful place to be but danger lurks at each turn. The further you travel away from the core worlds, the more dark and omnious the music should become.
Music
Multiplayer: Potential for server generated sound depending on time, mood and so on and so forth.
Single Player: More flexible. Parts have the potential to be randomly generated.
Positional Audio
Would be great to support more than stereo, but not a high priority.
Sound Design
Game Modes
Single Player
Single player mode will consist of some predefined missions intermixed with the whole random mission thing.
Storyline
The story of single player should introduce the player to the universe of praelium. Things such as hinting at the existance of the ancients should be done subtly through cinematics.
Add-ons
There could be money to be made in expanding the story line and giving people more of a reason to play solo some more. Perhaps charge something small like $10 ... or make it a freebie after $100 worth of recharging.
Timetable 1-2 per year?
Multiplayer Game
Battle Mode
Capture The Flag
Team Based Only
Fairly standard sort of game mode.
Flag placement can be fixed or semi-random. Random mode must keep a minimum spacing to ensure a fair game.
Deathmatch
Team or Solo
Fly around and shoot. To stop death by attrition, ships should be repaired by say 25% if they fly over the "vapours" of another ship that has died for single player mode. Team based modes should have a base that rapidly repairs and rearms them. This base should be available in both single and team modes. In Solo mode there needs to sufficent reward for the players to go through the landing/refuel/rearm cycle.
Needs a lot of thought, as we don't want to kill the whole premise of praelium being believable by an unbelievable game mode!
Carrier Battles
Team Only
Similar to deathmatch, but the goal is to destroy the other team's carrier however you can. Would enable a few additional classes of ship for laying mines, turrets etc.
Blockade Runner
Goal is to reach a target zone of space however you can!
Solo Mode
Need to get past a computer controlled blockade, first player to target wins.
Team mode
2 Teams, in either simultaneous mode or timed turns.
Persistant World
The biggest challenge! Creating a whole persistant world with a running economy etc.
