Game design from the beginning

I have decided to put my money where my mouth is and create a new PBM game, along the lines of what I described in the opinion thread. This will actually be more of a Play By Web game, although I could provide a paper mail variant if there is demand, assuming the game actually works.

So I thought I would crowd-source the design and development process -- make it an open experience that others can witness and participate in if they wish.

Here are my high level specs for the development platform:

- web-based interface, with no client-side requirements
- open-source server and development tools
- unix or windows (depending on where I can get hosting)
- java / JSP for the application code, perhaps with Hibernate as the data access layer and Eclipse as the development tool
- MySQL for the database
- some design portability, such that it could be played by web, Facebook, smartphone, etc.

And here are my high level game design specs:
- close-ended
- computer moderated, though I could be persuaded to open it up to human-moderated with computer assistance
- space empire building genre
- heavy control over economic, military, and scientific development
- different races for each player, with different strengths and weaknesses
- some level of automated non-player activity (perhaps an ancient berserk computer player, fully automated, to give everyone an early opponent)

Finally, here is a possible approach to developing it:
- lay out a SIMPLE rule set to start with
- develop the page layouts to support this
- build the database
- build the game logic (again, for a SIMPLE preliminary version)
- ALPHA TEST #1
- incorporate early feedback
- lay out an expanded rule set
- redevelop
- ALPHA TEST #2
- incorporate feedback
- lay out final rule set
- redevelop
- BETA TEST

I invite any and all readers to give me feedback on this idea. Is my process going to work? What suggestions do you have for the initial rule set? What types of features would you want in the user interface? How important are graphics/images to your user experience?

And, of course, would anyone like to pitch in and help build it? I would do the database and coding, most likely, but could use help in setting up server and hosting, getting a URL, and lots and lots of testing.

I like the idea and wish you good luck! :)

I would like to stress the importance of doing a lot of playtesting. Looking at your development approach it seems you are aware of this. It's not only to test if the code works and finding bugs, but also to test what features are good and bad. What's fun, so to speak...

Well, to get the ball rolling, here is a draft of a very simple initial set of rules. Very preliminary and full of gaps, but maybe it will get a conversation started.

1. Play takes place in a 3D star cluster.
2. Each star will have 0 or more planets.
3. Each planet will have 0 or more moons (natural satellites).
4. Each planet can be terrestrial, gas giant, or asteroid field.
5. Each player is an independent race of intelligent beings within that cluster, with one home planet.
6. Players can place a single base on any terrestrial planet.
7. Players can place a single space station in any orbit of a planet (of any type).
8. Each player race will have a habitability number. Planets also have a habitability rating. Players whose rating matches a given planet will be able to build open terrestrial bases on those planets, and farm food.
9. Players will build ships of the following standard types: colonization, transport, space superiority, planetary assault, and surveillance.
10. Players will extract resources from planets using mines.
11. Players will use factories to construct production goods.
12. Players will use assembly yards to build finished goods.
13. Finished goods will include ships, mines, factories, and technological advances.
14. Players will be able to communicate with other players at all times, through the game or through email.
15. Technological advances will allow players to build more efficient mines/factories and larger/more deadly ships.
16. Combat will take place in space (space superiority combat), space-to-ground (planetary assault and bombardment), and ground-to-space (bombardment).
17. Player races will grow at standard rates per turn, up to a ceiling for a given planet, adjusted for habitability ratings and (possibly) terraforming.
18. Players will have awareness of all fleets and bases within any star system that they occupy, but no further.
19. Players may trade resources, production goods, and technology, but not population.
20. The game is won when one player or alliance controls half the potential habitability (for their races) of the star cluster.

This is a fairly simple rule set, with lots of room to grow. Yet it should be deep enough to let us build out a decent user interface and perhaps some 3D mapping tools.

Fire away!

What about characters? Will the game have a character system?

That's a good idea. As Margaret Mead once said (paraphrasing here) "Never underestimate the power of individuals to change the course of history -- indeed they're the only ones who ever have."

I'm inclined to say let's put it in the second round of development (intermediate rules set), unless there is popular demand to have characters play a role even at the simplest level.

[quote='ixnay' pid='31' dateline='1294591586']
1. Play takes place in a 3D star cluster.
[/quote]

There is a game, Sword of the Stars, where each race has unique ways of moving between stars. Will movement between stars be free or will it follow wormholes/gates? Or will each player be able to chose his propulsion system (that would be cool but tough to balance)?

[quote='ixnay' pid='31' dateline='1294591586']
9. Players will build ships of the following standard types: colonization, transport, space superiority, planetary assault, and surveillance.
[/quote]

Following the same line of thought as above. Will there be standardized ships for all races/players or will they be able to create their own designs (like SN:ROTE)?

Cheers!

Start simple and expand is indeed a good way to approach this. More later when I have time to carefully read everything.

Let's broaden the discussion and focus on overall game design first, and drill down into specific rules later.

I had started out more or less wanting to make a simple version of a typical military/economic space empire game, along the lines of Empyrean Challenge, Master of Orion, etc. But the idea of having individuals (characters) play a role has me thinking of that old Avalon Hill/SPI game "Freedom in the Galaxy". This was a pretty naked adaptation of Star Wars to wargame format. The empire player controlled a few key characters, most of the key planets in the galaxy, and all the military forces. The rebel player had a secret rebel base and a strong cast of powerful individuals, who would roam around the galaxy, fomenting rebellion, sabotaging Imperial bases, and laying the groundwork for building a rebel force.

Our approach is to make a web-based game that can be played "casually" throughout the day, perhaps through facebook or a smartphone. Perhaps we could let players assume the role of these individual heroes (Luke Skywalker, Chewbacca, etc), OR take command of various military/economic formations.

I will add more later, real life is intruding at the moment...

the problem of using FB and smart phones is that the games becomes dumbed down with repetative actions, making real game play boring (my opinion only) You only have t look and camalot etctype games on FB to see they are not really games but based for FB simple games with click and select type menus. Fun for the first game say or run, but its hard to get players back for a second go once they know the route/clicks to acheive success.

The more I think about it, the more I realize I shouldn't think of the FB platforms so much as the mobile platform. Let people connect from their iPhone, ponder star system reports, draft build orders, etc.

Anyway, based on all the inspiration I've been given on this board, I am going to try to commit myself to working on this project at least a small amount every night. Tonight's mission is to investigate (free) development tools.

For what it's worth, I'll give you some advice I wish I had gotten before I started a long time ago: Design the game completely before you start programming. Have everything written down in as much detail as you can possibly imagine and every screen drawn up in a graphics program. There will be changes and inspirations along the way, but working like this allows you to catch your mistakes when they are easy to fix. IBM once did a study and discovered that the same mistake, when caught in the preliminary design phase could be fixed in one hour, but if caught in the testing phase would take 25 hours to correct. It is a truism of programming that only 33% of all projects see the light of day and of those that don't, 75% are abandoned because of a lack of design phase work.

You should, of course, value this post for exactly what you paid for it. ;)

This is good advice for all programmers in every field, not just the game industry. The problem many people face though is the sheer scale and size of the game/application/web app/service they have in mind is two large to put into words. OR, they become discouraged, after all programmers like to code, not design.

I think iterative development patterns really shine here. Fully design your core, fundamental components on paper. Produce a prototype, then evaluate the prototype. Maybe the interface needs to be re worked, or maybe that core game mechanic you thought would be really interesting ends up being a headache for the player. Re-design, add on to the prototype, and re-evaluate. Repeat until you have a fully functional product/game.

I would argue that if it is too large to put in words, it is far too ill-defined to put into code. The iterative pattern you describe works well, though I prefer to work as modularly as possible, too. Back in the good old days of the 640K barrier, we were forced to program in modules and therefore to think that way. One module for transfer, another one for buy, and a third for selling, etc. And thinking that way is a good method of breaking down your design into smaller, more easily defined concepts that will allow the designer to dig down until he got a real, robust, framework.

Indeed, good advice. I failed to mention the importance of modularization, because I assumed everyone coded that way. It is a generally sound design technique, for it brings with it a number of advantages: maintainability, easier to debug, etc.

[quote='Ramblurr' pid='507' dateline='1301233099']
Indeed, good advice. I failed to mention the importance of modularization, because I assumed everyone coded that way.
[/quote]

I am remembering being called in to work on code written by a COBOL programmer who had been forced to switch to ASP.NET 1.1. ;)

I take it that you're not a fan of COBOL, Jon?

Some of my best friends are converted COBOL programmers. (said the Quaker Minister.) I am pretty sure that this person had not followed COBOL best practices either, especially when it came to documenting her code, but according to her, COBOL allowed her to get away with a top down approach that was fine, I guess, but .NET, like most modern languages is object-oriented and requires a bottom-up approach.

Need to get this project moving forward. I am thinking that I will build the core game functionality as a database app and work out the game mechanics first. I will hook up a web front-end later. For the moment, I want to get the feel of running a game and watch the data going in and out "manually".

I think my game design will be fairly typical and standard, so this won't be a leap beyond, say, Far Horizons. Actually, it is partly inspired by FH, and also Empyrean Challenge. Basic game mechanics that handle the tried and true space empire genre. I will likely throw in some support for characters.

I am tabling my idea of a Flash interface until I get more experience with that platform. My son wants me to program some of his "game designs" using Flash, so I will be learning at least the basics of that soon.

But this PBM game will start out as a database (probably Access) with an ordered process to handle each turn's output. It will then produce turn results as "reports" in PDF format. All pretty much out-of-the-box stuff.

Update: I have a new laptop arriving tomorrow, which will be my development platform for this little project. (My other machine is many many years old and only good for surfing, and I can't use my company machine.)

Initially I had thought to build out a database in MS Access (which I am pretty familiar with.) But Access has a LOT of quirks. I know the Empyrean Challenge boys are building their new version on it, but I decided to go with something else. (I also would have had to pay $200+ extra for MS Office "professional"!)

Someone here mentioned you can get temporary use of .NET tools for 3 years -- enough time to determine if this would actually be a viable game platform. So I might look into that. Otherwise, are there any suggestions? I have done JSPs before, and I could probably get up to speed on MySQL pretty fast. But is there an open source equivalent to Access? Sort of a rapid-prototyping database development environment?

Access sucks scissors sideways. Go with SQL Server Express or mySQL Free

[quote='JonO' pid='1176' dateline='1308073834']
Access sucks scissors sideways. Go with SQL Server Express or mySQL Free
[/quote]

I agree with Jon. MS SQL is my preferred relational DB. But it does depend on what you plan to implement. For Ilkor: Dark Rising we've gone for both SQL and MongoDb. Mongo for our game map and SQL for the typical relational data entities.

Mongo is free and MS SQL isn't nearly as expensive as at first it might appear.

[quote='Gads' pid='1177' dateline='1308074508']
[quote='JonO' pid='1176' dateline='1308073834']
Access sucks scissors sideways. Go with SQL Server Express or mySQL Free
[/quote]

I agree with Jon. MS SQL is my preferred relational DB. But it does depend on what you plan to implement. For Ilkor: Dark Rising we've gone for both SQL and MongoDb. Mongo for our game map and SQL for the typical relational data entities.

Mongo is free and MS SQL isn't nearly as expensive as at first it might appear.

[/quote]

Sql Server Express is free. Later can be ported up to the paid version if needed

http://www.microsoft.com/express/Database/

[quote='JonO' pid='1178' dateline='1308151745']
[quote='Gads' pid='1177' dateline='1308074508']
[quote='JonO' pid='1176' dateline='1308073834']
Access sucks scissors sideways. Go with SQL Server Express or mySQL Free
[/quote]

I agree with Jon. MS SQL is my preferred relational DB. But it does depend on what you plan to implement. For Ilkor: Dark Rising we've gone for both SQL and MongoDb. Mongo for our game map and SQL for the typical relational data entities.

Mongo is free and MS SQL isn't nearly as expensive as at first it might appear.

[/quote]

Sql Server Express is free. Later can be ported up to the paid version if needed

http://www.microsoft.com/express/Database/

[/quote]

True, however I don't think in the real world (hosting) it is that easy (seamless) to scale up. You actually have to 'script' your entities and data across.