The basis is: lots of objects (entities) and a terrain (heightfield). The objects are rendered as sprites, each of them can have arbitrary size, picture and color. You may add and remove entities at your will. The terrain can provide you with altitude information, also you may dynamically modify it (rise or lower).
There are additional not-so-essential things: you can draw text on the screen, draw some sprites on the screen or on the world, and draw some rigid (non deformable) 3D meshes.
Of course, the engine provides you with keyboard, mouse and timing information; also there are many helpers for common tasks.
The system of entities and/or user interaction deserves special attention, more on that later (after you're familiar with the difficulties) - see The Grid.
At, first, it seemed like an easy thing. 100 thousand sprites - that's not so much...
But then: 100 k sprites - that's 400 k vertices. Dynamic ones, so they're going to be fed through the AGP bus. If we wanted 50 FPS - that's already 20 million vertices per second! It's already near the GeForce2 vertex limit... As our vertices are 24 bytes in size, that's roughly 480 MB/s AGP traffic - that's already AGP 2x limit! And then, we must first write these vertices to the AGP memory, and then the video card reads them - we quite quickly understood that we'll be at least RAM bandwidth limited.
The rendering itself should not bother you, fellow game developers, but you'd better know that there's not much RAM bandwidth you have for your game logic (and, by the way, not very much CPU cycles also :)).
So while the engine opens great opportunities for you by giving you the ability to deal with lots of entities; it also restricts you with some design decisions and processing scenarios we had to make:
As a game programmer, you should deal with game logic and user input mainly. That means: you don't draw the entities, you don't draw the terrain, you don't load textures and so on. You do almost no graphics stuff (except for some indicators or text on the screen).
What do you do: add/remove entities, move them around, change their colors/sizes/pictures. Respond to user input. Draw some indicators. Optionally notify the player when he wins or loses.
Imagine an invisible grid that is laid down on the ground (like a chess board, for example). Each grid cell will be called a "sector". Or in tech terms: we have a 2D space partition with fixed size rectangular sectors.
So, we have those grids lying on the terrain, and lots of entities running around. At any time, we can find a sector any entity is in. Once we know the sector, we can do anything we want with it - like increase some sector's counter or test the entity agains some magic stuff that is recorded into the sector.
You're not restricted to using one grid; also, sector data type can be just about anything.
We think that this "grid system" is fairly good for approximating collisions, doing entity-entity and user-entity interactions. It's somewhat similar to the usual space partition schemes, but here we have one difference: grid sectors don't track the entities they contain, and the entities don't track the sectors they are in. This saves us quite large amount of time, but also imposes some difficulties.
More on the grid is in Details: Using the Grid.
1.2.17