RTS Game Engines...

[Ildûrest]

Well, it's something I've wanted to do for an age now.

Have you ever played Starcraft or Age of Empires? Both superb games.

I reckon I could make a game engine a bit like theirs.

I'd like to ramble a bit, perhaps get some of you interested in the idea.

All it really boils down to is a simple, but well-made, object engine, and a good display engine. You store the properties of each unit, including health and all such information, also keeping track of what they're doing. Then you can more or less draw what needs to be drawn on the screen.

You'd need a queue to store each units 'plan', and continue revising their actions based on their final target. This all needs to be connected to the user interface, and there are a few tricky areas (pathfinding in particular), but overall it would be relatively straightforward. "Computer players", i.e. AI, is where it starts getting really tough. Lots of fun, too, I'd think.

If I ever get around to this, I'd like to make this an open-source project; as the open-source community could do with a few good games.


Reply about anything - what you think of Starcraft, ask how game engines work, suggest something, muse about open-source games...

[earlofqb]

I know of several free game engines. First, however, I'll post the "game engines" link of the "Game Programming Wiki". It is really the first place you should go if you have serious plans about doing this.
gpwiki.org/index.php/Game_Engines

Second, the Irrlict engine is quite spiffy (although I haven't been able to do much in it as I'm not a C++ programmer). It's more of a graphics engine, however the author did make a game out of it's capabilities. irrlicht.sourceforge.net/

Third, virtually any game engine can be used to create a RTS game. In the real world, the engine has little to do with the game itself, and more to do with interacting between the game and the hardware. In other words, your basic game engine is a bit like a linker/compiler for your game.

Fourth, a look around TheFreeCountry.com gave me some intriguing stuff www.thefreecountry.com/sourcecode/games.shtml

Fifth, a simple list of stuff you'd like to look into (all freeware, some have source available somewhere):
Cube, Irrlict, Retribution, Boost, PPTactical (RTS-specific), GamesBasic (version of BASIC designed for producing games), Crystal Space, The Nebula Device, Qube, NEON, etc.

Sixth (why do I keep doing this?), I suppose I'll ask you "how game engines work", as I'm not entirely too sure myself.

Seventh, I'm making my own game (no game engine used, nothing much to it. Basically, a giant application that I'm calling a "game") in Visual Basic.NET (yes, I know how much you hate it, but it's still good for my purposes).

Normally I'd say more, but I've learned the hard way that when someone leaks information about what they're doing (game development-wise), people tend to copy it and (via the power of the so-called "rush job") get your idea out the door faster. Luckily for me, my idea wasn't fully disclosed, saving me the horror of my game being published by some n00b.

That's probably the only problem with open-source games, people tend to take your ideas and do stuff that you'd rather not be done with it. It might work fine for your purposes, but it didn't for mine (make a little bit of money and advance my "street cred" with some professionals I know (they keep telling me to make a closed-source game, because open-source doesn't get the same level of attraction that closed-source does whenever you're going for a job. Apparantly corporations see it as "inferior", despite the fact that open-source is (99% of the time) better than proprietary code (because others can review it and improve it, making the entire project better))). Just something to watch out for (not much worries for you. A lot of people have been trying to make the so-called "Freecraft" (open-source Starcraft-like game/engine). The only problem is that some have been sued by Blizzard for their efforts)...

[Ildûrest]

My vision for the game engine is one that is a lot more specific to the game. Well, perhaps my terminology is not accurate.

But by "game engine" I basically mean all the code for the "gameplay" part of the game. Everything from talking to hardware to path finding to what gets added to a unit's queue when you right-click somewhere.

The graphics rendering and talking to hardware business might be mostly taken care of by one or more libraries but that'd be it.

As to VB.net, I respect your choice (just hang on a tick while I go to the bathroom to vomit).

Open source, on the other hand... Don't even mention it. (To a prospective employer, that is.)

I'd love to write a wordy response but I've a lot of work and very little time as I've been wasting days trying to get this fast internet connection working. So I'll see you later.

[Mikrondel]

Well, I decided to see what I could whip up in a short period. Few hours of work brought this interesting little thing:
aleks.budzynowski.info/hold/RTS.BAS

You can click 'units' and right-click to make them move round.
It uses CALL INTERRUPT so you'll need to load QuickBASIC (Doesn't work with QBasic 1.0/1.1) with the /L switch, to load the default library, where the INTERRUPT routine is stored. This is easiest done by editing a shortcut to QB's properties and adding a space followed by /L to the shortcut's "cmd line" property (which should already contain QB.EXE or QBX.EXE).
You can also do this through a DOS prompt, by typing "QB /L" or "QBX /L". You DO require a space before the /L.


I'm aware that it's full of holes, (mainly: units can erase each other and overlap, there is no boundary to movement, and, of course, you can't attack. Yet.) but I think it's pretty good for having done it all in much less than one day.

I'm releasing it under the "Use for educational and Mikrondel-praising purposes only" license.

I'm happy to discuss its inner workings if you're having trouble understanding it yourself (as you probably would be with my awful commenting)

[earlofqb]

So, basically you plan to make a game, where the graphics and sounds are generated by outside processes? Thus, there's no actual "game engine" as the entire game logic will be processed from within the main class?

The only way your game would fit under the "game engine" terminology would be if it were to simply process the AI and battle logic from within the engine. The rest would be processed by I/O engine, graphics engine, sound engine, and terrain engine (although that could be integrated into the game engine). I don't meant to sound condescending, but that's (at least my understanding) of what at game engine is (just the logic and primary features of the game).

Your test thing was pretty spiffy. What's the red dot for? Some simple collision detection could be used so the dots couldn't overlap, and to attack you'd have to use some more Call Interrupts to get the position of the cursor whenever you fired. Then you'd have some pretty complex (for amateurs) stuff where you'd design a path for the weapon's fire and some continuous collision detection for if it encounters a wall (or lastly, the object you shot at).

From what you wrote, it looks like a pretty good thing you could use to set up something like a Dark Chambers (an old Atari 2600 game I once played. In it, you moved sprites around, killing monsters and progressing through a maze (never did finish it, it simply looped around to the first level when you finished the game), only yours would be a top-down version (as currently written)) -like game. Spiffy stuff.

I didn't look at the source code (lately I've been in a sort of funk where I can't really read source code, only write it (making debugging "fun"). Hopefully it'll pass soon (I used to be able to look at source code for a few seconds and tell you exactly what the game would do)), but I should get around to it sometime (because game programming is some stuff I'm starting to get into to "hone my skills").

[Mikrondel]

"So, basically you plan to make a game, where the graphics and sounds are generated by outside processes?"
Not exactly. It would definitely be RTS-specific, but beyond that AI and unit definitions might not be part of the main code.

"the entire game logic will be processed from within the main class"
Gwah. What the heck is a class? [Not that I don't know, I just think OO is a lot of hot air in most cases.] And the answer is no, anyway.


<<The only way your game would fit under the "game engine" terminology would be if it were to simply process the AI and battle logic from within the engine. The rest would be processed by I/O engine, graphics engine, sound engine, and terrain engine (although that could be integrated into the game engine). I don't meant to sound condescending, but that's (at least my understanding) of what at game engine is (just the logic and primary features of the game).>>
I don't care whether it falls under the widely accepted definition of 'game engine' or not. I'm making what I want to make. And I have a feeling Starcraft was coded in a very similar way to the example I just gave (except using Win-32 equivalents, more modularity (my example is far from complete, after all; if it grows I will move some of its main code into subprocedures) and letting DirectX do a bit more thinking).

"Your test thing was pretty spiffy."
I'll keep working on it.

"What's the red dot for?"
Which red dot? It's a unit that's supposed to look like an X (when not side-on).

"Some simple collision detection could be used so the dots couldn't overlap"
DUH.

"and to attack you'd have to use some more Call Interrupts to get the position of the cursor whenever you fired"
Why? I already know the position of the cursor. It's the other bits of the logic that'd be important.

Gotta go!