I'm starting off developing my first game. I've tweaked a few others, programmed useful applications extensively and even started in on a mod or two, but this is my first big project on my own.

I've got a ton of great ideas. I'm sure that's no big surprise to any of you out there. But I have the sneaking suspicion I'm letting things get too big.

Right now I'm working on a turn-based space strategy game. No big deal or anything. I'm having fun developing my own UI. (GUI layout will be defined in an XML document. Makes skinning that much easier, eh?) It's tedious teaching myself this stuff, but I think I'm on the right track.

Unfortunately, I don't know. So, I ask those of you out there who are much wiser than I . . . what advice do you have for me . . . the aspiring game programmer. The game development n00b. What are the pitfalls? What are the common mistakes? Are people on this forum really as dumb as they seem sometimes, or is it all really that hard?

And most of all . . . what do YOU want out of a turn-based space strategy game?

The most common mistake I see is people picking projects beyond their abilitys, or letting features creep into a simple design until it's not viable anymore, i.e. the hundred billion RPG's "in development" that you never see. Start small and work your way up.

I dunno, a turn based space game doesnt sound TOO ambitious, it's just when I hear "real-time strategy" or "multiplayer" and "RPG" when I want to stab myself in the face repeatedly.

It really depends on what areas you're going to be playing with - unfortunately just about everything Java-related has a gotcha or two somewhere, anything to do with games as well even more so.

Game programming really can be that hard. You might not run into any problems yourself, but on the other hand you might hit every performance killer, maintenance nightmare, non-portable feature and broken concept there is!

As for turn-based space strategy games, the two monsters in this field are Ascendancy and Master of Orion 2. Both of them get dug up and reinstalled for a few weeks every now and then on my computers - there's just nothing I've found out there recently to rival them. I'd recommend picking up those two and see how they work. Ascendancy is a particularly simple concept and has very basic graphics, but is executed beautifully. MOO2 is more complicated in many areas like ship to ship combat and race attributes and abilities.

Generally, as a minimum you need some concept of a planet which has population and buildings, and stars which planets orbit. You need spaceships that can travel between stars and shoot at one another. Lastly you need a research tree.

From there things depend on what you want to do. In Ascendancy the ships travel between planets, in MOO2 they just exist at a particular system. Ascendancy requires ships to travel through space lanes, MOO2 ships can go as far as they have "range". In MOO2 you generally only aquire one piece of technology per item researched. Ascendancy has a much larger focus on developing planets than MOO2. Etc etc.

You might not run into any problems yourself, but on the other hand you might hit every performance killer, maintenance nightmare, non-portable feature and broken concept there is!

Trust me, I know how that goes. It's not game development, but I write Java web-apps for a living. (everything from simple servlets to full-on EJBs) Java is an amazing, incredible, stupendous language that just makes you want to beat the living crap out of something sometimes. It's aggravating how much you have to "look up" to work in Java. In C++, you can't do something, you just brute force it. Start writing directly to memory and make it work the way you want. In Java, you have to find somebody's API and learn how to use it . . . ugh. Just figuring out AWT, BufferStrategies, MouseListeners, VolatileImages blah blah blah has been a pain. I think the worst of it is over for the moment though. Who knows . . . I may come to eat those words.

Quote

The most common mistake I see is people picking projects beyond their abilitys, or letting features creep into a simple design until it's not viable anymore.

Oh don't worry . . . I've already done that. For example. Everybody starts out with identical races which evolve based on their playing style at key points in the game. So far I've come up with 18 different races to "evolve" into and I have two more "evolution" points to design yet. *sigh* May have to pare that down a bit.

it's just when I hear "real-time strategy" or "multiplayer" and "RPG" when I want to stab myself in the face repeatedly.

Oh . . . so now's not the time to say that my game is just practice for developing my multiplayer real-time strategy/RPG game?

What? How hard could it be?

Quote

the two monsters in this field are Ascendancy and Master of Orion 2

Played MOO2 and wasn't terribly . . . wowed or anything . . though it was a good game. Never played Ascendancy. The one I played a LOT was Stars! A great little game when it was made, though definitely a bit old by now . . . and the micromanagement was just insane in big games. Mare Crisium is the company trying to develop the sequel. (company's founder wrote the original) It looks sharp (not in Java tho) and will be a great game . . . . if they can ever get out of "we have no money" hell and back into production. They got as far as beta testing and have been stuck there for 2 years now. Having a publisher helps. *sigh* ah well

Well, thanks for the reality check . . . time to get back to work, I guess.

Let's not forget Star Control 2 although one may argue that's not Strategy. Though the original Star Control was.

To make my post a little more substantial I'll add some comments on Java and Space Strategy game design.

My biggest problem with Space Strategies is that they're epic. Too epic. I find that most of them have a threshold after which the entire rest of the game becomes cleanup. And that's very, very dull. So if anything you should try to address the issue of end-game slowdown.

I myself am a professional Java developer (well, I get paid for it, I don't know how professional I am ) and started my own game, simply for the sake of learning and my love of games. From what I've learned, one very important thing is your API choice. It can make your life easy or miserable. Unless you're crazy to make your own, do your research carefully and make sure the API you choose suits your needs, be it graphics (LWGL, Java3D, etc.) or sound (JavaSound, Tritinous, OpenAL, etc.).

Well, I wouldn't say I'm exactly crazy about doing my own, but it looks like I am for now. I'm subclassing java.awt.Component for all my bits and pieces and setting it all up to use accellerated images . . . VolatileImage mostly. It's not terribly clean, and I've never been good at writing clean code, but it's kind of working. So far I can display a GUI layout and content windows, all based on a master Layout.xml document. Not terribly robust ATM, but we're working on that. Developing a thorough DTD will help a bit, as will cleaning up my API a bit more.

Running into framerate funkiness with mousemovements across my movement sensitive surfaces. Framerate limiter is there, but even as low as 30 it chunks. Not that it really matters in a turn-based game. For the most part, I've been trying to hold on to BufferedImages as long as possible before compositing them onto VolatileImages . . . mainly for the sake of preserving transparency on some things. I think they're slowing everything down tho. And honestly . . . transparency's not really at the top of my concerns ATM.

So I have the main display window, buttons, backgrounds . . . now all I need is to make some other happy display windows and a nice, happy way to display text interactively. Idea is you can issue orders . . . you'll see how long/how many resources it'll take to execute them. If you want it faster/cheaper the game will show you what orders you've issued already that will be affected. Then you can start prioritizing. That's a VERY highly interactive set of text windows though. Not sure how easy that's going to be to pull off. I guess we'll have to see.

If there's anybody with better ideas on how to do this, I'm all ears, but most of the APIs out there seem to be based on a render loop type of thing. This is a refresh only on demand type of setup . . . and only the components that need it.

Things are coming along right quick . . . especially considering my lack of time to spend on it.

And BTW . . . endgame boredom is precisely one of the issues I'm trying to address. That and micromanagement hell, which is equally obnoxious. As the game progresses, you should go from commanding single ships, to groups of 10 to 20, to groups of 1000, to massive fleets rather transparently. In theory, you should be able to tell a fleet "attack this system in this particular way" and the appropriate groups will break off and perform their respective tasks, all the while being easily commanded as you would one single ship.

We'll see if it works out that way. In theory, EVERY game is great. *sigh* If only.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org