Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
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. 
Posts: 166
Threads: 14
Joined: Feb 2011
Reputation:
3
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.
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
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.
Posts: 166
Threads: 14
Joined: Feb 2011
Reputation:
3
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.
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
(03-27-2011, 01:38 PM)Ramblurr Wrote: Indeed, good advice. I failed to mention the importance of modularization, because I assumed everyone coded that way.
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.
Posts: 1,475
Threads: 340
Joined: Jan 2011
Reputation:
9
I take it that you're not a fan of COBOL, Jon?
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
03-28-2011, 03:08 AM
(This post was last modified: 03-28-2011, 03:11 AM by JonO.)
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.
Posts: 408
Threads: 36
Joined: Jan 2011
Reputation:
4
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.
Posts: 408
Threads: 36
Joined: Jan 2011
Reputation:
4
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?
Posts: 169
Threads: 14
Joined: Mar 2011
Reputation:
0
Access sucks scissors sideways. Go with SQL Server Express or mySQL Free
|
