Irrlicht Engine

I have been toying with the idea of creating a(full fledged) game for sometime now(i have made 2 small ones), i was thinking somewhere along the lines of an RTS (god game), but initially i would be happy if i could just implement only one user controlled city, with various kinds of buildings, units etc.i do have a few ideas about how to go about doing this but i am having some trouble in finding specific resources to help me.
I am not looking for a "make your own RTS in 24 hrs guide" but i would love to have some specific guidelines (pls don't tell me to google ... i have done enough of it , but google does not answer all my questions)
like
1. how to control Sooo many characters on screen at the same time?
2. how to implement a pseudo 3d or fully 3d map?(although i am not a very good modeler , but i can make do with dummy models for the time being)
3. how do implement microtasks.

and many more....
if you could point me in the right direction i would be very greatful
P.S. I am planning to use either C++ and irr OR C# and XNA , which do you think would work better for me in this kind of a scenario (i am equally proficient at both of these)

newbie8787 wrote: 1. how to control Sooo many characters on screen at the same time?

Control one character, and write a for loop.

Flippancy aside, the issues are the number of interactions. Try to avoid any O^2 interactions by (e.g.) tiling the world so that each actor only has to consider nearby actors in its interactions.

newbie8787 wrote:2. how to implement a pseudo 3d or fully 3d map?

Are you talking about your main screen, or a "minimap"?

newbie8787 wrote:3. how do implement microtasks.

What's a microtask?

I was talking about the main screen, actually i was thinking of making a 3D map on which i can place sprites which look like 3D images , but are actually just images drawn to give a 3 D effect , i realize that this would hamper my ability to rotate the map, but i think i can make that compromize.

by microtasks i was referring to not having to tell each and every unit what to do and when to do it, like there are always units waiting for jobs , as soon as jobs become available , the units automatically go and start working.

newbie8787 wrote:I was talking about the main screen, actually i was thinking of making a 3D map on which i can place sprites which look like 3D images , but are actually just images drawn to give a 3 D effect , i realize that this would hamper my ability to rotate the map, but i think i can make that compromize.

check out tutorial 6

newbie8787 wrote:by microtasks i was referring to not having to tell each and every unit what to do and when to do it, like there are always units waiting for jobs , as soon as jobs become available , the units automatically go and start working.

do you mean AI(artificial intelligence)

no ... i dont mean AI (which btw is such a general term) ...but it seems that i am not able to explain this particular requirement properly, are there no books or something on the subject which would gimme atleast an outline of what i need to know?

I suspect you may be inventing a lexicon unnecessarily. There doesn't seem to be anything complex about your requirements that would require making up a new term for them.

Let's work through an example.

Each unit (I'll call them actors from now on) will have a state that describes what it's currently doing, as well as some information describing what it's doing it to.

Let's say that you (God) places a new building, which has a completion counter (that initially starts at empty) and which knows how many actors are building it (initially 0).

Then each building will regularly[1] check its completion counter, and the number of actors working on it.

If it's not fully built, and there are fewer actors working on it then the maximum that could work on it, then it will find the closest actor[2] that is in an idle state[3]. It will tell that actor to come and build it The building increments its "builder count". The actor changes its state to "building" and its target to the appropriate building.

Each actor will regularly[1] check its state. If it's idle, it might wander randomly. If it's building[4], then it will move towards its target building. If it's at its target (a building that needs worked on), it will add to its completion counter at regular intervals. When its target building is complete, the actor becomes idle again.


This is just State Machine 101. I hope that seeing it worked through is some help, and demonstrates that (almost) all programming tasks are trivial if you can break them down into enough small, simple sub-tasks.

The specifics are up to you, since they will be decided by your requirements. In this example, I've considered your God influence to be passive. You could also be more active, i.e. pick up actors, then drop them directly onto a task to assign them to it, changing their state as appropriate.


[1] Regularly doesn't have to mean "every game tick". A time based check is better in many ways, e.g. buildings could attract a new actor every .25 or .5 seconds. On the other hand, actors should probably check their states and perform their actions during every game tick.

[2] It could do this repeatedly in a loop until it has enough actors working on it, but it may look better if it attracts them gradually, and that also removes the need to check that there are still candidate actors available within the loop.

[3] Actors could also be pulled out of states other than than idle, depending on how important their current task is compared to this new task. That's really down to your requirements.

[4] An actor that's "building" could also have sub tasks and sub targets, such as "fetching building materials" from the nearest stockpile, if you want more nuanced behaviour.