Hello to everyone! I'm using C++, DirectX9, OpenAL, WindowsXP, Adobe Photoshop, GraphicsGALE. I have made games like tetris3d,orbfactor(like Dropout). I would like to make an RTS!! Im dying to make a game like RED ALERT!!!! What shall I do? any Tips? any suggestions about problems that I will encounter in the progress of the game? please help me. especially those that have already made a game similar to this one. one thing i think that i will be having problems is about when clicking the floor/enemy, your units will come close and attack. another thing is the AI. because I will be making this game for a single player only. Thanks for any help out there.

Making a RTS is harder than it looks. One of the critical components of an RTS, the part which solves the problem you mentioned of getting units to move into position is called pathfinding. The basic algorithm which people like to use for this is called A-star but that will only get you started as it is not suitable for dynamic environments (in which other units can get in the way for example) and it us usually too expensive to do fully for all your units all the time.
As for AI, well that is even more challenging. You have to take into account resource management, build order and building placement, scouting, unit production, unit maneuvering and potentially even more. It can get very elaborate, although I suspect most RTS games out there "cheat" in many ways just to make the problem manageable. I can't really describe in detail each of these aspects but it involves planning, learning, lots of heuristics and statistical metrics, and often people will employ things like decision trees to arrive a high-level strategy based on limited information from scouting.
Good luck!

I agree, it will take a lot of planning. Look for the book Core Techniques and Algorithms in Game Programming. I believe it is available for free on the internet now without too much looking, although I could be mistaken. You're going to need to do some AI research before you get started and will definitely need at least a set of heuristics for higher-order thinking.

It is also _very_ important that if you want multi-player you start designing that in from the very beginning. The paradigm of lock-step simulation that RTS games use requires some very specific coding patterns: everything must be deterministic, if you use random numbers you must have a mechanism to ensure that the same number is rolled on all clients, etc. Basically seed at the beginning on the server, share seed to clients all start at the same time. You'll also need deep de-sync checkin logic built at low level. This stuff isn't that easy, but certainly achievable; just make sure you plan it all out from the beginning. Tacking multi-player on after you have single-player up and running will be an impossible task.

-me

Hi!

I have recently started trying to make an RTS game using SDL/Opengl.

The problems I had were:

1. Unit selection. Solved.
2. Memory management of entities. Mostly solved. ;)
3. Path finding. Solved.
4. Dynamic collision avoidance. Partly solved.

1 was easy. 2 is an ongoing process... but the boost library is helping greatly with this.

3+4 are interesting, and where I am right now in my project.

I have large maps (grid can be 1024*1024 or more), and so A* pathfinding is slow, and the resulting paths can be both large AND crap when high amounts of open space are involved. I have attacked this in two stages:

a) To have a queue of a* path requests, of which only a few are processed every frame. If an entity has requested a path, but does not yet have it, it just heads in the direction of the goal destination until the path is available a few frames later. The stupidity is not really noticed by the player.

b) For each a* path generated, I create waypoints between unblocked/line of sight path locations and remove the path locations in between - which means that if nothing blocks the route between the entity and the goal location, the a* path is simply 2 steps. (Instead of potentially tens of thousands of individual path steps given a large map size)

If there is a block in the path, a waypoint is created. Not every path location is checked, I check every 8 or so steps to save time. This may result in a waypoint which doesnt have quite perfect line of sight to the previous step, but this is where my collision avoidance routine kicks in. I also use a PVS (potentially visible set) - a *big* data structure that I can query for line of sight information between one cell and another - this is calculated offline during the map creation phase. Bresenham style line of sight ray casting algorithms are quick, but not for large maps, hence the need for the lookup.

My collision avoidance doesn`t use anything clever at all - it simply runs an early-exit a* path finder using a euclidian heuristic, and gets the best path it can find in 10 steps or fewer. Costing of cells can be dynamic according to speed/number of entities contained within - so the early exit path will cost those higher and avoid them, all the while trying to find a path to the next waypoint in the main path's list. This allows the lazy evaluation of waypoints, as explained earlier, as even if they are not perfectly visible, the real-time crap a* routine should be good enough to 'find' it, all while avoiding slow/static entities.

That is the story so far.

As is pretty common, I`m thinking most of this is not the best way forward and am currently reading up on flocking and other more generic grouping / avoidance behaviours.

.mitch

Hi! Thanks for your response.

That would be a BIG help before I start.

I haven't mentioned. I already know the A* algorithm. I have done it.

what about selecting the unit/s?

I really want to make even a simple strategy game like DOTA and RED alert.

for example. A red alert style but has only 1 unit like in DOta. My main purpose for making this game is to practice myself on making a game that uses mouse. you know what i mean. similar to Battle Realms,DotA,RedAlert,BattleCry,Diablo(the click stuff),etc.

Please explain it deeper on this specific task.

Thanks.

Quote:Original post by macmoy
Hi! Thanks for your response.

That would be a BIG help before I start.

I haven't mentioned. I already know the A* algorithm. I have done it.

what about selecting the unit/s?

I really want to make even a simple strategy game like DOTA and RED alert.

for example. A red alert style but has only 1 unit like in DOta. My main purpose for making this game is to practice myself on making a game that uses mouse. you know what i mean. similar to Battle Realms,DotA,RedAlert,BattleCry,Diablo(the click stuff),etc.

Please explain it deeper on this specific task.

Thanks.

Unit selection is straightforward, but I am an opengl man, so don`t know how to do it in directx, though I suspect it's similar.
Basically, for every selectable object, you have a separate rendering pass into a selection buffer (for a complex object, you can just render a quad in this pass). You give each object or group of objects an id number, and then all the id numbers which are visible in the selection buffer are kept in an array which you can then query to see what was selected.
It is common for the projection matrix for the selection buffer to represent a single pixel on the screen, but also possible to have it dynamic according to a range dragged by the mouse as well for selecting multiple units.
This is just one way to do it, but it was easy to implement.
Somebody else will have to advise on the directx way of doing it.

.mitch