Game design process: Project OTD

[rogerborg]

OTD - OTD's Transparently Designed

I've decided to knuckle down and start on the design of a game. I'll be documenting the design process here, mostly as an exercise for anyone who hasn't seen it done before. Comments, suggestions and observations are very welcome at any time.

The first thing that I need to make absolutely clear is that this is not the announcement of a game project. It is a game design project. There will be a lot of words here, and no code. I will follow the design process until:

1) The time estimates look achievable within my lifetime, at which point I will start a game project.

2) The time estimates come in too high, at which point I will /dev/null the project.

3) I get bored or distracted by something shiny.


Second, I will not be dogmatically following any particular design methodology. Design methodologies ultimately boil down to organising blocks of content (text and mockups). What will be documented here is just the content, not the organisation.


Phase 1: Preliminary requirements

Before you can start to test, implement, design or analyse your project, you have to first decide what you're going to produce. Those are your requirements. If you don't have requirements, then you don't know what you're making, and so you won't know when you're done.

Requirements gathering is the most important part of the whole process. You should, by the end of it, have a list of everything that will be in your game, which just as importantly defines by omission what won't be in it. Everything that you implement should be trackable back to an original requirement.

It's important to distinguish between requirements and design. Requirements set out what you're going to do. Design deals more with how you're going to achieve it. So at this point, try to stay at a fairly high level of abstraction - although if your requirements will have significant consequences for implementation, it's fine to note that.

Don't skimp on or try to rush through this phase; correcting mistakes here is by far the cheapest place to do it.

What follows is a work-in-progress list of my actual and potential requirements, all of which are (at this stage) open to addition, removal or amendment. At some point soon, the list will be arranged into sub-sections.

Your comments and especially questions are most welcome.


Fundamental requirements:

• Multiplayer
• Realtime.
• Fleet based.
• Set in space.
• The primary game activity will be starship tactical combat.
• The game will be played in a winnable strategic environment.
• The game must not exactly duplicate or directly compete with any existing space themed game. It must offer a unique experience that offers a compelling reason to play it.

High level requirements:

• The game will have a client/server/metaserver architecture.
• The server must be able to service at least 16 clients via a home broadband connection with 128Kbs upstream capacity.
• The maximum number of players can be determined by the server admin. 32 concurrent players over 128Kbs will be a goal, 64 players a stretch goal, and 128 players a bluesky goal.
• Servers will register with the metaserver(s) and keep it/them appraised of their availability.
• A server with no human players will continue to advertise itself as active and available, although it may halt the game while there are no human players.
• Clients may connect directly to a known server (including a local server), or may obtain a list of available servers via the metaserver(s)
• The game will be played in fleets. Each player will join and remain a member of a fleet.
• The server will provide a configurable number of computer players to fill in for human players, potentially allowing single player play.
• Each player will control one starship.
• Players will be able to join or leave the server at any time.
• When a player leaves the server, his current starship will become computer controlled, and will attempt to disengage from combat, reach a safe area and eventually leave the game environment. If it is destroyed before leaving the game environment, the player is penalised as though he were still piloting it.
• Upon joining the server, if the player still has a starship in play (i.e. he has reconnected after a disconnect) then he will immediately be placed back in control of it. Otherwise he will have to select a starship, which will enter the game at a 'safe' area.
• The player will be represented by a crew that will gain in level, which will unlock more powerful starships.
• Each player will also have a record of combat achievements and losses.
• Each server will hold a persistent record of players, and will store their crew levels and combat record.
• The game will be played on a 2D plane, with false height for visual purposes only. Starships may yaw, but not pitch or roll (except for visual purposes).
• The viewpoint will be 3rd person.
• Tactical combat must rely on player skill and judgement rather than purely on statistics and random numbers.
• The size of the strategic environment can be set by the server admin.
• The game will be "winnable". Victory will be achieved by capturing all or most strategic points via tactical victories.
• After a strategic victory, the game universe will reset.
• There will be no overall time limit on strategic victory.
• There will be a resettable countdown to strategic victory once a fleet controls a large majority of strategic resources
• The state of the strategic environment will be serialisable.
• The game must offer incentives for both/all fleets to continue playing regardless of the strategic situation.
• The strategic environment will provide an area or areas in which only small starships can operate.
• The game will support team and global communication, with configurable message macros for standard message types (e.g. "Help me", "Moving to capture resource X")
• Computer players will send and respond to the standard message types in order to co-operate with each other and with human players.
• Combat performance will not award players with experience directly. Instead it will give them 'awardable merits'.
• Players may assign their awardable merits either as merits or demerits to any (other) friendly player. The awarding of these merits is what generates crew experience for the recipient.
• The game unit will be starships. Each player will control one starship, ranging in size from gun/torpedo boats to battleships and heavy carriers.
• Starships will always face in their direction of travel.
• The feel should be similar to WWI/WWII naval combat.
• Starships will be armed with guns and torpedoes grouped in batteries.
• Starship weapons must be aimed manually at a point in the game world, not by clicking on a target.
• Starship weapons will be externally mounted and rotate and reload fairly slowly.
• Gun 'shells' will not strike or damage targets until they explode at or near the point of aim.
• Torpedoes travel relatively slowly and can be dodged by nimble ships. They will not track or home on targets.
• There will be an enforced delay between successfully issuing repeated orders of the same type: turn, change speed, aim weapons.
• Some starships may carry and operate starfighters.
• Starfighters will be of 3 types: interceptors (anti fighter), bombers (anti ship) and scouts.
• All starcraft (starships and starfighters) will have sensors of limited range. Enemy starcraft that are outside of sensor range will not be fully visible.
• Starships will be equipped with tractor/pressor beams.
• Starships will not be able to operate all of their systems at full capacity indefinitely.

* * * * * * * * * * * * * * * * * * * * * * * *

Option #1
(Already decided in favour of starships)

* * * * * * * * * * * * * * * * * * * * * * * *

Option #2
Three types of strategic environment are being considered:

1. Contiguous universe. There is no discrete boundary between points of strategic importance, and starships can travel without 'jumping'. Immediately upon entering the universe, players are effectively in the tactical combat environment.
2. Discrete strategic areas. The universe is split into 'starsystems', which contain strategic resources. Starships must 'jump' into a starsystem in order to take part in combat there, but may do so freely at any time.
3. (Option discarded)

* * * * * * * * * * * * * * * * * * * * * * * *

Option #3
Strategic resource interactivity.

1. Strategic resources are passive and do not fight back.
2. Strategic resources have fixed combat capability.
3. Strategic resources have combat capability that can be increased over time or by spending limited resources on them, adding a layer of strategic play.

* * * * * * * * * * * * * * * * * * * * * * * *

Option #4
Method of capturing strategic resources.

1. Capturing can be achieved simply by controlling the area of space around the resource for a certain amount of time, or clearing the entire 'starsystem' in a discrete area model.
2. Capturing a strategic resource requires assaulting it with starships, with some starships being more suited to assault than others.
3. Capturing a strategic resource required expending limited resources (e.g. the Netrek model of removing armies from a friendly planet and dropping them on an enemy planet to destroy enemy armies).

* * * * * * * * * * * * * * * * * * * * * * * *

Option #5
(Already decided in favour of awardable merits)

* * * * * * * * * * * * * * * * * * * * * * * *

Option #6
Availability of starships

1. Starships will be available 'free' based purely on crew experience.
2. Players will accumulate limited personal resources which must be used to purchase allowed starships.
3. Fleets will accumulate collective resources which can be used by individual players to purchase starships.

* * * * * * * * * * * * * * * * * * * * * * * *

Option #7
(Already decided in favour of tactical intelligence)

[MasterGod]

*Going to get some popcorn before reading that post*

[Dorth]

First I love it, second, here are my thoughts ^^ :

When I see "metaserver", I think warning: How long can you maintain it. How many of them? What fallback if it's down, temporarelly or permanently. Possible solutions include a way for the client/server to redirect to another metaserver and direct connections. -EDIT- Sorry, didn't see the direct connection bit -EDIT-

-Players will be able to join or leave the server at any time.
What about penalties? Will a player stats be kept? Will his ressource keep on develloping while away? Is an empty server alive? Where should a returning player be inserted? (last position, safe spot, home spot, etc.)

-16 players will most likelly have problem with option #2 -3 (only 1 person signing on an event?) while 128 might have problems with #2-1 (everyone on top of one another, complete chaos, random playing a bigger role that strategy)

-How big is the winnable staus window? 10 minutes? 1 hour? 10 hours? 10 days? a month? more? What does it entail for the players? Awards, props, bonuses (if anything, in the next round), handicap?

-Might I suggest dynamic teams over welded ones? Multiple teams option? (free-for-all, 1v1, multi-teams, kingdoms like, etc.) On victory condition of a big team, if "destroy all ennemies" is a possibility, a chances for team member to go rogue and turn their back on ancient allies?

-Possibly multiple ressources type? Varying from one time scavenge to long run bases needing to put in ressources, even mining camp where you must pay per ressource? Neutral groups, hostiles, capturables, etc.

-If you want to augment strategy and disminish randomness, don't put xp in the hands of players, unless it's something like a rank that needs to be on one person at any time in a team, forcing it to vote it to someone and giving bonuses to that one. A well established rule system for awarding xp WILL play in that strategic side you want.

-Instead of set Starcraft, how about combining Ship hulls and mods? mods take all one spot or can have varying shapes, depending of your need. That way you could go with : Hulls are disponible based on rank, mods need ressources. Or something the like.

-I think for strategy, possibilities for obfuscation, hiding and such are a must. If nothing else, put a max range on those scanar, you'll have less info to send to each clients.

-Possibly a script engine built-in from the start? Adds extra time but simplify pretty much all the devlopment process and this way, you can have your cake and eat it too, by having various scripts that can be loaded for different gameplays, and opening the door to player modification. This combined with an in-game console can save a lot of time ^^ Of course, the benefices for a script engines are bigger the sooner you put it in



Well, that's my thoughts for now, I'll check by later if I got more ;P

[rogerborg]

First I love it, second, here are my thoughts ^^ :

When I see "metaserver", I think warning: How long can you maintain it. How many of them? What fallback if it's down, temporarelly or permanently. Possible solutions include a way for the client/server to redirect to another metaserver and direct connections. -EDIT- Sorry, didn't see the direct connection bit -EDIT-

That's an excellent point, and one which is bothering me. Even if there's network of multiple metaserver peers, they still requires a single authoritative list, so then we're into a meta-metaserver.

Of course, I could always punt the issue into the "It's only a problem if I actually complete the project and have players" bucket.

-Players will be able to join or leave the server at any time.
What about penalties? Will a player stats be kept? Will his ressource keep on develloping while away? Is an empty server alive? Where should a returning player be inserted? (last position, safe spot, home spot, etc.)

Great questions, I'll update the requirements.

-16 players will most likelly have problem with option #2 -3 (only 1 person signing on an event?) while 128 might have problems with #2-1 (everyone on top of one another, complete chaos, random playing a bigger role that strategy)

Indeed; the environment size needs to scale to the number of players.

-How big is the winnable staus window? 10 minutes? 1 hour? 10 hours? 10 days? a month? more? What does it entail for the players? Awards, props, bonuses (if anything, in the next round), handicap?

I'm thinking "Indefinite"; thus the requirement to serialise the strategic state.

Also, I'm inclined against any significant bonus for a strategic win, as I want the core reward to be the second-to-second playing of the tactical combat itself, rather than grinding crew or strategic wins, which would encourage... 'creative' play like blocking player slots on the other side, or tit-for-tat surrenders.

-Might I suggest dynamic teams over welded ones? Multiple teams option? (free-for-all, 1v1, multi-teams, kingdoms like, etc.) On victory condition of a big team, if "destroy all ennemies" is a possibility, a chances for team member to go rogue and turn their back on ancient allies?

That largely depends on whether all starcraft are available to all players. I was leaning more towards a fleet system, because I don't expect that any given server population will be big enough to really support "kingdoms" (or clans, or shifting alliances). With 16 players (plus computer opponent padding), you're really only looking at two sides if you want any decent sized engagements (although 3 fleets is appealling for rock-paper-scissors reasons).

-Possibly multiple ressources type? Varying from one time scavenge to long run bases needing to put in ressources, even mining camp where you must pay per ressource? Neutral groups, hostiles, capturables, etc.

Indeed, but I'll likely firm that up in the detailed requirements.

-If you want to augment strategy and disminish randomness, don't put xp in the hands of players, unless it's something like a rank that needs to be on one person at any time in a team, forcing it to vote it to someone and giving bonuses to that one. A well established rule system for awarding xp WILL play in that strategic side you want.

It might bear some explaining. What I'm thinking in option 5.2.2 is:

There will be a rule system for identifying 'good' conduct, i.e. damaging or destroying enemy ships, capturing resources. But instead of awarding XP to the player (as in option 5.1), it would instead give them 'awardable merits'. Players would then award those merits (or demerits) to each other, and it would be the awarding of these merits that would actually affect the recipient's XP.

I feel that might introduce some very interesting teamplay dynamics. I imagine that the most common scheme would be tit-for-tat, and friendly computer ships would likely tit-for-tat merits. Thus far, it's looking a bit pointless. But consider the case of a battleship being escorted by destroyers. The BB is doing most of the damage, while the DDs are there to deter enemy torpedo ships and fighters and might not actually get the chance to do much damage. If the game rewarded the BB directly, then the DDs have no incentive to hang around and keep it alive; they're better off just leaving it to get ganked by fighters while making suicide runs of their own. But if the BB can reward the DDs for playing smart, then it encourages teamplay.

There's another interesting effect in that it would tend to balance ranks among a fleet rather than high level players getting ever further ahead once they have a significantly better ship. The downside is that it may be frustrating for them to not be earning XP directly themselves, so the process of awarding merits would have to be viscerally appealing.

-Instead of set Starcraft, how about combining Ship hulls and mods?

1) It would add greatly to the implementation and testing time.

2) Regardless of the available combinations, there would only be a limited number of useful configurations. I'd rather make them available directly.

3) I like the idea of well defined ship classes, as it makes for more satisfying bragging rights when you win against the odds.

-I think for strategy, possibilities for obfuscation, hiding and such are a must. If nothing else, put a max range on those scanar, you'll have less info to send to each clients.

Yes, I agree.

-Possibly a script engine built-in from the start? Adds extra time but simplify pretty much all the devlopment process and this way, you can have your cake and eat it too, by having various scripts that can be loaded for different gameplays, and opening the door to player modification. This combined with an in-game console can save a lot of time ^^ Of course, the benefices for a script engines are bigger the sooner you put it in

If there's a requirement to have any part of the game easily configurable, then yes. The likely candidates are the computer controlled ships (I try to avoid saying "AI" ). However, I'm inclined to believe that it's quicker to code directly in C++ and to unit test the behaviour than to script it, if for no other reason than that scriptability encourages boundless tinkering instead of pushing towards code complete.

Well, that's my thoughts for now, I'll check by later if I got more ;P

Thanks, that's been really useful. I very much appreciate you taking the time to comment.

[Dorth]

It is much to my pleasure, after all, I am still indebted to you, and this is really nothing (nitpicking? cmon!)

Now another pass ^^

Well, for the metaserver, like I said, you could allow the app to redirect to a new metaserver, opening the door to the community to take care of it, after all, if your game is any kind of success, some people will do it by themselves and if it's not, it doesn't really matter anyway ;P

Indefinite time game don't sound winnable to me, or at least, not within a gameplay session, unless you oscillate between 15 mins and 5 hours. Also, the serialization aka, saving of the world and all would be nice, but by experience, being a big fan of tactic games and playing a good deal of those in multiplayer, I VERY rarely see the end of one, because for each additional player, it's that much harder to continue. Possible solution: Fleet are the real agents, aka, they possess territory, ressources, etc., not the player. That way, when continuing a game, a fleet can redivide all that amongst the present players. Taking over another's player game is pretty lame, but just continuing from a "ok, the team is in a 3 v 4 with 10% more ressources, let's get them" and then make a "new" start, now that's fun ^^

For win bonus or anything the like, I'd suggest purely aesthetical bonuses with 0 influences in-game except for the taunting rights, or even just the customization of ship, etc. Don't underestimate that. Virtual Fighter and other games can easilly double their average player's playtime by offering those goodies as rewards, even though they alter nothing in the gameplay.

16 is not so little. Age of Empire 3 is a game with up to 8 players, yet changing alliances and such isn't so rare and can be part of the tactic. Also, if you reach any of your higher goals (32,64,128), the kingdoms-style teams would get more and more likeliness to be enjoyable ^^

While I do agree such an xp system is nice, it's quite volatile and can be used to bully players. I'd think that before thinking this part, a lot more of the game should be solved. If 95% of the game is capturing ressources and fighting, the 5% tactical left with scare tactic and all is not worth taking into consideration, but if it ends up 50/50, then of course it is. Also, there are ways to award points for making ennemies retreat (they turn around after having come "this close" from you), offering cover fire to a fighting ally, or, for that matter, just group xp. I haven't had good experience with any kind of human intervention in xp system before, unless it was an entire human-based game (Dnd )

Yeah, I'd though mods could be a bit much, though the way some game like Escape Velocity handles it are just masterpieces. Anyway, I'd like you to look at Escape Velocity's choice of ships if you don't offer mod. What they offer is often 4-5 versions of a same hull, with slightly varying stats, and while a certain class of ship will be more X than Y, one of it's mod can still have more Y than all other in it's class and less X. You get the idea

One of my favorite game of all time, still to this day, is Starbound II. One of the main reason is that the AI system is a beautiful coding language and even as a kid, I was finding myself breathless touching it and playing it and those of others. Of course, I'm not suggesting anything that complex. Also, with scripting languages nowadays, it's pointless recreating your own from scratch. But, it did increase the game's worth in my eye by manyfolds and allow to this day new ennemies with incredible tactics to suprise me. Hardcoding can't compete with a community based modding (Civ 4 ) Of course, nothing says you even PLAN to have AIs in the first place, in which case, this whole point is pretty much moot

Anyhow, I like this exercise and will follow it attentively Once more, you offer much, sir Rogerborg ;P

[rogerborg]

Well, for the metaserver, like I said, you could allow the app to redirect to a new metaserver, opening the door to the community to take care of it, after all, if your game is any kind of success, some people will do it by themselves and if it's not, it doesn't really matter anyway ;P

The problem of mutable metaservers is: how does a brand new player find them? If there are multiple metaservers then there's effectively fragmented island communities.

I really need to give this some more thought. Thought... make for... brain hurts...

Indefinite time game don't sound winnable to me, or at least, not within a gameplay session

That largely depends on whether the perception amongst both server admins and players is that the game is more of persistent mini-MOG in which total conquests and resets are rare, or a pickup deathmatch with fairly frequent conquests. I was leaning towards the former, but I'm going to keep an open mind on it and play through the latter in my fevered imagination a few times.

For win bonus or anything the like, I'd suggest purely aesthetical bonuses with 0 influences in-game except for the taunting rights

Agreed.

or even just the customization of ship, etc. Don't underestimate that. Virtual Fighter and other games can easilly double their average player's playtime by offering those goodies as rewards, even though they alter nothing in the gameplay.

I had considered using it to cap crew level, i.e. each rank requires being involved in a game win. I'll need to crunch through some more imagination exercises on that one though.

16 is not so little.

Depends on if it's a mini-MOG or a pickup deathmatch.

While I do agree such an xp system is nice, it's quite volatile and can be used to bully players. I'd think that before thinking this part, a lot more of the game should be solved.

It actually forms a fairly key part of my thinking. The problem with having the game award XP directly is that gameplay for many players then becomes more about selfishly exploiting the mechanics than on being team players. It certainly could devolve into silly tit-for-tat demeriting, but I wouldn't be interested in supporting that sort of a playerbase anyway, so that would be a self-solving problem.

This is based on experience of similarly themed games; Netrek and Navy Field. In both games, certain vital but low intensity roles (e.g. scout, deterrent escort) are penalised simply because there's no practical way for the game to distinguish between players who are actively neutralising each other through bluff and manoeuvre and players who have just gone AFK.

I'd like to think that humans are much better at deciding whether a teammate is helping them out than any algorithm, although I'm prepared to be surprised on that.

So I think I'll go ahead with this requirement for now. Bear in mind that I will be designing in performance metrics, it's just that they won't award XP directly. However, once that mechanism is in place, it would be near-trivial to make the XP awards directly.

Yeah, I'd though mods could be a bit much, though the way some game like Escape Velocity handles it are just masterpieces. Anyway, I'd like you to look at Escape Velocity's choice of ships if you don't offer mod. What they offer is often 4-5 versions of a same hull, with slightly varying stats, and while a certain class of ship will be more X than Y, one of it's mod can still have more Y than all other in it's class and less X. You get the idea

That sounds much like what I'm planning. I'm a wet navy / Star Fleet Battles nerd, so I get very hot pondering all the possible variants on a base type, e.g. a destroyer hull could have DD (standard), DDL (leader), DDG (torpedo), DDA (assault), DDE (escort), DDS (scout) and DDV (carrier) variants. By basing all of these on the same hull (i.e. model) and using a descriptor system that's inheritance based (i.e. this starship is the same as that one, but with these few absolute or relative differences...) that would wring the maximum gameplay bang out of each content creation buck.

About the scripting, one thing that I'd like to achieve is a network and gameplay design that's robust enough so that it doesn't matter if a remote client is a human or a (player written) bot; both should have the same limited state information available, and the same opportunity to influence their environment. So while I may not actually use it on the server, I might see if I can trot out a client with a plugin that makes it easy to automate it for budding 1337 h4xx0rz.

Thanks again for your great input, I'll certainly ponder on it tonight over a beer and a blowj-... I mean, a curry.

[killthesand]

Hello. First I will clarify that by no means am I an experienced programmer or game designer, but I'll offer up what my brain was thinking about after reading this post.

Since you're not sure if you have a persistent MOG type or quick deathmatch type game, I'm not really sure what it would mean to connect to and play on a server. It sounds like you want to avoid 'fragmented island communities'. If you have a long term mmo style game, this seems unavoidable. When you start a character with one server, you have to stay on that server. If characters can level up, obtains tons of cool abilities, and switch from server to server, it seems like it would screw up the dynamics of battle. The military power of each faction would constantly fluctuate. This would limit the demand on the metaserver to new players.

In the other case, if the games are short and the servers keep resetting people to an equal starting point, here's how I would deal with servers/metaservers: Give the client a flat text file (or easily human editable file) that has the address of every metaserver. The client would try them in order, use a simple ping/timeout function, if the metaserver is down or busy, move on to the next one. It is unlikely that all your metaservers will be down. Each metaserver will keep a list of the other metaservers. If there is any change to the list, it will update the client. If the client can't connect anywhere, you should have an updated list of metaservers available for download from your website. (or a huge apology for the servers being down)

If you use only your own dedicated servers, you might be able to get away without a metaserver at all. Employ the same text file list of servers. Maybe the client would pick one at random. Store a list of servers on each server. If there are changes, the client is updated. If your users are allowed to host their own servers, this isn't going to work as the list would be updated frequently. If your users are allowed to host their own servers, I wouldn't try to make a long term mmo style game.

Another thing to think about: If you do have a more mmo style persistent world, what do you do when one side finally wins? If players have been spending months working hard gathering resources, building bases, defending, attacking, etc. then they aren't going to be too happy when it all resets to zero. I haven't ever seen a team vs team game that lasts more than a couple hours. Short term games at least give you the thrill of tallying win-lose-tie. If putting a check in the win column requires weeks, months, or years of effort, it seems like the cost is greater than the reward.

There's many permutations of game style to choose from that will drastically change the gameplay. Maybe you can create multiple game modes. One mode will force quick deathmatch/ctf/objective style play, while another mode is full blown epic scale resource management, strategy, and battle that lasts forever style.

Also please redefine 'a 2D plane, with false height'. I guess I'm imagining that means a top down camera. The universe is an infinite plane on which everything rests, and that plane has some hills and valleys in it. That seems kind of weird for space battles. It's more likely that instead of a 'plane with false height' you mean that you will have full 3d models for all of the ships, planets, etc., but every object will have a Z position of zero.

For the most part, it looks like you have a solid foundation. Thank you for sharing this stage of game development. I hope that you do eventually make this a successful game and continue to document the process along the way.

[rogerborg]

Thanks for the great comments, I really appreciate them.

Since you're not sure if you have a persistent MOG type or quick deathmatch type game, I'm not really sure what it would mean to connect to and play on a server.

It is an interesting pickle. I'd like to think there's a solution that makes the 'grind' secondary to the minute-to-minute play, but I agree that it will inevitably engender investment in a single server.

In the other case, if the games are short and the servers keep resetting people to an equal starting point,

To clarify, it's just the universe that would reset, not the player ranks.

here's how I would deal with servers/metaservers:

LA LA LA THAT'S A DESIGN ISSUE, NOT A REQUIREMENT, SO I CAN'T HEAR YOU YET LA LA LA.

>>> <<<

(Only joking, thanks for the suggestion).

If you use only your own dedicated servers, you might be able to get away without a metaserver at all.

The 'server' is likely to be given away with the client, and servers would be hosted by users (thus the requirement to support at least 16 human players over 128Kb).

One thing I'm swithering on it whether to open source the server. The problem with doing that is that it then becomes a race to create the most Monty Hall server to attract players. I'd rather that server configurability be kept to a minimum, with competition being over bandwidth, latency and uptime.

If your users are allowed to host their own servers, I wouldn't try to make a long term mmo style game.

Careful now: not "MM", just "M".

Yes, I tend to agree. I'd like to scale it so that a game could theoretically be winnable within tens of minutes, given a series of overwhelming victories. The feel should be a fragile and dynamic environment, not a static one with irregular changes.

The long term investment would be in a crew, not in the strategic environment. I'll /dev/null the idea to invest in defences; that's a distraction from the core gameplay. Thanks for helping with that decision.

There's many permutations of game style to choose from that will drastically change the gameplay. Maybe you can create multiple game modes. One mode will force quick deathmatch/ctf/objective style play, while another mode is full blown epic scale resource management, strategy, and battle that lasts forever style.

Not in this lifetime. I'm going to pare the requirements to the minimum, which means I need to pick one direction to go in. I'm leaning strongly towards shorter sharper gameplay now.

Also please redefine 'a 2D plane, with false height'.

Quite right, it's clear in my head but jive when written down. It'll be effectively a 2D game with 3D models, and any rising above or below the 2D plane will be purely for visual purposes clientside, to avoid the appearance of collisions.

Thank you for your comments, they've been very helpful. I'm currently expanding and categorising my requirements, and adding all the bits that I haven't included yet, like account maintenance and ship selection.

[ebo]

Sounds like Darkspace...

[Dorth]

I do not agree with the "If your users are allowed to host their own servers, I wouldn't try to make a long term mmo style game." May it be one m or 2. I have played on offi and private servers many mmo, and I usually stick with the private because of the selected population, customization, etc. It's easier to find a private server that tailor your taste than one big mmo (or mo). I would think allowing privately own server if it was long gameplay would be exactly what it would need to be a hit vs a loss. UO private servers are kicking the rump of offi. WoW are doing pretty amazingly well too. And all strategic, shooter, tactic, etc. game comes with the possibility of private server, no matter how long the gameplay is, because they know people can create all kinds of customization to make it enjoyable at different configurations. Starcraft is an amazing example. With seemingly little customization that can be brought on, an incredible wealth of different gameplay emerged in the custom maps world.

I am still and will always be a huge partisan of "if it doesn't cost much to allow this to be customizable, let it be so and put a default value to it."

[rogerborg]

Sounds like Darkspace...

I hope not; I'm veering away from anything akin to "Massive", or commercial. Player hosted servers, short victories, a resetting universe, a minimal layer of strategy over the tactical combat.

I do not agree with the "If your users are allowed to host their own servers, I wouldn't try to make a long term mmo style game." May it be one m or 2. I have played on offi and private servers many mmo, and I usually stick with the private because of the selected population, customization, etc.

True, but those are commercial MMOs who do a good job of marketing and distributing their clients to a large potential playerbase. I'm in a very different situation.

I am still and will always be a huge partisan of "if it doesn't cost much to allow this to be customizable, let it be so and put a default value to it."

How do you deal with the Monty Hall problem? i.e. every server admin cranks up the rewards to the maximum to attract players?

On the other hand, if you can't personalise a server, what's the incentive to run one?

It's a pickle, and no mistake.

[Dorth]

"Fun servers" (Man do I hate tha name) will always exist in any popular game, wheiter you meant your server to be customizable or not anyway. It's a good sign in a way. But that doesn't mean it'll steal the majority of your players. Only those who are naturally bound to like more those kinds of things. And why not? If they somehow enjoy it, let them have fun! After all, it's for them you're making the game, not for you. If you make a cut decision in anything that would have been easily modifiable, you force your view of the game on the player. It can be good, if you're extremelly talented game designer with a good information gathering team. But most chances are you're not or don't have that. Even if you did, you do not automatically ruin a good game by making it extensible. Especially if you have defaults value well calibrated AND for bonus points, if your whole system is made to balance itself out anyway (bigger ship == slower or those sort of things, keeping the gameplay balanced no matter what the players prefer ^^ )

[ebo]

I hope not; I'm veering away from anything akin to "Massive", or commercial. Player hosted servers, short victories, a resetting universe, a minimal layer of strategy over the tactical combat.

Scrap commercial (which in fact seems to be no longer true, you had to pay for darkspace once, but it seems they dropped that) and that pretty much describes Darkspace.

You could host your own server (but they didnt have any influence on your 'official' rank). The DS-Metaverse is a connection of several missions in different solar systems. One of them took like 2 hrs and was for about 32-64 players (cant remember). As soon as one side wins, the metaverse rests, leaving the ranks ppl acquired intact.

I played the beta and loved it. Unfortunately i couldnt pay for it at that time. I _really_ dont want to discourage you (I played with the thought of starting something like that, too, but you know ... i'm not a professional game development team), I'm just noticing that this sounds kind of familiar

[rogerborg]

DarkSpace is a Massively Multiplayer Online Game that combines tactical ship to ship combat with strategy in a team orientated game. Players gain rank and prestige, which expands the ships they can command and the strategic decisions they make. More...

SUBSCRIBE NOW to DarkSpace for only $9.99 a month...

Ah, they seem to be bullshitting about the "massive". Their 4 online servers have player caps of 100, 100, 500 and 100... and only 12 people playing out of that 800 capacity. Based on the few unique posters on their forums, it seems to be on life support.

Verdict: $9.99 is too much to ask these days. To attract and retain players, a game needs to be free to pick-up-and-play, or of the scope of Eve or WOW. This will be a labour of love.

Thanks for the heads up. As I dig deeper into the manual, it does look quite similar, but on a much grander scale. I wonder how much they spent developing it, and whether they made their money back? I seriously doubt it.

My budget is $0, and my requirements and design tailored to that budget. It'll have to be 'sold' on core gameplay, not extras, visuals and sweeping scope. If I need a manual, I have failed it. Hmm, I should add that to the requirements.

[ebo]

SUBSCRIBE NOW to DarkSpace for only $9.99 a month...

Ok .. somehow i missed that line ...

Dont forget that this game was released in 2001. They had more players at that time

My budget is $0, and my requirements and design tailored to that budget. It'll have to be 'sold' on core gameplay, not extras, visuals and sweeping scope. If I need a manual, I have failed it. Hmm, I should add that to the requirements.

Get someone to make you some models and sounds .. thats more important than any amount of code.