Flee! The barbarian hordes approach!
Still no band-selection yet, but otherwise the interface should feel quite familiar to anyone who has ever played a 3D RTS.
To be honest, I kind of psyched myself out with my last post about Planitia’s design, and I did it with two words: world simulation. Planitia will require at least a basic world simulation, but I’ll be darned if I know how to do one, and unfortunately my perusal of the Game Programming Gems books and AI Game Programming Wisdom books have been disappointing When all of these books discuss AI they discuss pathfinding, line-of-sight, group movement – unit-based AI. When they do talk about RTS AI, it’s about creating an AI opponent for the player to fight against (which, granted, may come in handy).
Of course, while I consider what I’m looking for to be “AI”, other game developers may not. What am I looking for?
A world simulation consists of a system composed of interacting subsystems with emergent properties. Oblivion’s world was made of a system like this. So was Ultima VII’s. So was Powermonger’s. Thus you can see that such a system doesn’t require heavy CPU horsepower. It does require one to know where to start coding such a system.
Once again, my friend Tom Mauer comes to my rescue. In college he heard about discrete event simulation, a form of computerized system simulation that is really big in manufacturing and scientific industries but hasn’t really been used for gaming. The basic concept seems simple enough; I’m going to try it out on Planitia. If I get it working I’ll probably write up an article on it.
He mentions me so I must go into my discrete event simulation rant.
There are two kinds of simulation, Process and Discrete. (there are a couple others too but I don’t care about them) Process simulation is what you are probably used to; update the timer by 1/30 of a seconds and update EVERYTHING. It is inacurate and cache unfriendly. It quickly limits how many objects you can simulate in Real Time because you must update everything every update. It is good for simulating things like physics where every object has an event every frame anyway, but bad for most everything else.
Discrete event works by using a time sorted heap (or list) of planed events that will take place in the future. When you update the system clock by 1/30th of a second you pop all the events scheduled to be handled in that time off the heap and handle them. This way you only needed to update the units that actualy changed. Much more cache friendly, much faster.
For some reason people think Discrete event does not work in real time. They are wrong. When we were working on Conquest 2 (an RTS) I switch most of the simulation to a discrete event simulation. Suddenly our unit cap did not matter, update droped off the profiler. (Of course networking 10000 units was still not going to work…)
Speaking of networking, discrete event also works better over a network because guess what! Network commands are Discrete Events.
I can go on further about it but … ahh well….
As a non-programmer, I’m going to relate this to things I studied in school. Ahem.
It sounds just like the “shot” system in the Feng Shui RPG. In that system, a round was divided into 20 shots, but even comparatively simple things like throwing a punch took 3 shots. I’ve always liked it for being how I think of Computer RPG combat because it slices time up into subactions.
I just completed a Webserver simulation a few months back in one of my Algorithms courses. It was interesting but I found it was hard to wrap my head around at first. The use in AI seems like a great idea. I can’t wait to see Planitia in action.
The article´s link seems to be broken, I was very interested in it.
Do you have a saved copy, or know somewhere I can read it?
Unfortunately it has fallen off the web, and frankly I can’t remember what the article said (it’s been a while). But there are actually more resources about using discrete event simulations in games now than there were then; some google-fu should produce something usable.