4E4 Contest Entry - Unnamed RTS

[lief]

that is a good adage. here's another one - "10% of the work is coding the game, 90% is your wife letting you have enough time to even bloody well think about planning a game"

yes with the movement. a final positioning should be more important than how each soldier individually gets there, that sort of sums up what i was saying (or trying to say).

does your system allow for other formations? how does it actually get the soldiers into position, does it calculate the 4 corner soldiers from the middle soldier? a lot of systems seem to keep track of available positions in a formation block, when a soldier is sent to a position inside the formation block it requests an available position, if no position available then a new formation is built.

my system only works because it is not a rts, and I know the maximum amount of soldiers I have on each squad.

you have a waypoint system working yet?

[cairnswm]

Ok this might be embarassing but:

[pascal]Const
Formation : Array[0..8] of Record DX, DY : Integer End =
((DX:0Y:0),(DX: 30Y: 30),(DX:-30Y:-30),
(DX:-30Y: 30),(DX: 30Y:-30),(DX: 0Y:30),
(DX: 0Y:-30),(DX:30Y:0),(DX:-30Y:0));
procedure TRTSMap.MoveItems(X, Y: Integer);
Var
I : Integer;
Item : TRTSItem;
IC : Integer;
Begin
IC := 0;
For I := 0 to Items.Count-1 do
Begin
Item := TRTSItem(Items[I]);
If Item.Selected then
Begin
If IC < 9 then
Item.MoveTo(X+Formation[IC].DX,Y+Formation[IC].DY)
Else
Item.MoveTo(X+(Trunc(Random*120)-60),Y+(Trunc(Random*120)-60));
IC := IC + 1;
End;
End;
end;
[/pascal]

Thats the complete code for the formations and controlling the Movement of units ops:

So I have a fixed formation system. I might entend this later to manage formations of different number of units - for example four guys might stand around the move to point, two guys might stand left and right of the point

I dont think I'll use a way point system. My method of doing collision detection and path finding seems to be efficient enough not to require it. I have in the past worked out how to do a way point type system. For pathfinding and collision detection I create a collision array that overlays the map. Each item in the map registers their presence against one or more spaces in the collision array. When any object moves it does:
:arrow: Remove Self from Collision Array
:arrow: Calculate Destination Position
:arrow: Check Destination Position againsty Collision Array
:arrow: If Empty - Add self to Collision Array at new location
:arrow: Else Put self back at Old Position (Then decide about attacking etc)
:arrow: Remove from Draw Array
:arrow: Add to Draw array in new location (Only neccessary if Y changes)

For a way point system I'd implement a different system where the map is broken into sectors - each sector knows its neighbours and if a unit can move from one sector to another - pathfinding first finds the shortest sector route then does pathfinding through these sectors to the final destination - ignoring all area outside these sectors. (Not quite way points but then I'm using not quite A* pathfinding - (see very old post in tutorials forum))

[cairnswm]

"10% of the work is coding the game, 90% is your wife letting you have enough time to even bloody well think about planning a game"

I have been married for 12 years My wife and I did go through a period where this was a problem. We ended up sitting down and having a discussion about the problem. We resolved as follows -

:arrow: William is not allowed to sit at his computer until 8pm at night. This applies to every night except Sunday and Thursdays which are family (wife) nights.
:arrow: Saturdays and Sundays William is allowed to work on his PC unless Yolande wants him to do something else - then the something else always comes first UNLESS agreed up front that William wants time - ie Game Dev Contest - LD48 and GDC72 for example.

Now - William has as much time at the PC as he can do without sleep - But I find I have to be asleep by 11pm else I dont funtion right. Also PGD and other sites take up much too much time

[Sly]

Sounds familiar. I got married and suddenly had less time on the PC than before.

[Traveler]

LOL

There are times I enjoy being single

[lief]

We ended up sitting down and having a discussion about the problem. We resolved as follows

... We resolved as follows

...resolved...

i don't understand, I thought you said you were married...
that code should work find for formations, you could set it up as instead of points you use a grid, with flags on and off for each sector as available positions so:

x-x
-x-
x-x

would be a 5-dot formation like you have. this way you could resize the grid object and the formation would automatically spread.

[Crisp_N_Dry]

Cairnswm -
I was using version 0.5 previously before, in fact I tested all of them. 0.3 crashed everytime but that's not an issue now. However, 0.6 which I just downloaded is missing all but one of the image files and so halts on startup. I ransacked the 0.5 zip file and cppied the images over. Just a heads up, not really a big deal unless somebody doesn't have the previous versions in which case you might miss out on some valuable feedback. Anyways, 0.6 ran at the same speed as 0.5. I dare say the refresh on your laptop is 80hz hence the 80fps framerate, whereas my monitor is running at a 60mhz refresh (2 year old TFT). I would check out your code but time constraints don't allow for it, not tonight anyway. The earlier versions (pure SDL) ran at 30 frames at best which seemed very slow considering what it was doing but since you are now using OpenGL this shouldn't be a concern.

There are times I enjoy being single

My wallet loves me for it

[cairnswm]

However, 0.6 which I just downloaded is missing all but one of the image files and so halts on startup.

I was aware of this - therefore my note in the previous message of:

(PREVIOUS IMAGE FILES REQUIRED - see RTS0-05.zip)

I am just trying to save a bit of space RTS0-06.zip has only been downloaded a total of 8 times and I dont think I should waste the web space for that few interested people


Anyway - onto the next post

I've been doing some thinking about optimisation of drawing for a while now. Basically while sitting on holiday for the weekend I gave some thought to the following:

[pascal]
For I := 0 to DrawItems.Count -1 do
Begin
Item := TRTSItem(DrawItems[I]);
If (Item.X > MapLeftInt-12 and (Item.X < MapLeftInt + 92 and
(Item.Y > MapTopInt-12 and (Item.Y < MapTopInt + 72 then
Item.Draw;
End;
[/pascal]

Obviously the first optimisation is to stop checking once Item.Y is no longer in the area. Also some changes to the 128 number can improve it a bit as well. And of course pre calculating the (MapLeftInt-12 calculations.

HOWEVER

(I think this solution is sort of a quadterion (sp?) solution).

What if I have an array covering my map in 16x16 pixel areas (similar to my collision array I use for collision checking - defined elsewhere). Each time an item moves it updates its feet position into this array. When drawing the screen I just go through all the drawing array squares, if an item is positioned in the array at that square then I draw the item.

This means I would have 3000
[pascal]
If DrawArray[I,J] <> nil then
[/pascal]

as opposed to the big If statement above. As the statement above is already doing an assignement, and a number of checks I think this may be faster. (I suppose I need to check it )

Also

What about splitting the DrawingItems List into multiple lists - each covering a half of the screen, when an Item is registered into the draw list it gets put into the draw list relevant for its locations. This way I need to cycle a max of 9 lists to get the objects instead of having to check every object in every location.

Any ideas?

[lief]

Keep a track if objects were drawn last frame... if not, only do checking if they haven't moved (or camera position moved). would need to add an extra flag to track this.

i presume the first thing you posted was just a screen area check?

i call this fantasy pascal

on Event MoveObject
Object.draw_flag := Object is inside ScreenRectangle
Object.might_need_to_draw_soon_flag := Object is inside SlightlyBiggerThanScreenRectangle

on Event MoveCamera
check all objects with might_need_to_draw_soon_flag to see if they need their draw_flag set or unset

or instead of the draw_flag, which would cause you to need to still check every object, if the object needs to be drawn, just keep one list. why do the array squares if they all need to be drawn anyway? aha... you might need the z order kept correct yes? no.. that wouldnt work for multiple objects in grid square... hmmm

anyway...

keep three lists and housekeep them every so often.... (you might be able to figure a way so you don't have to do a full sort every processing cycle)

the lists

1. Will not need to draw now, next frame, or the next 10 frames...
2. Not drawing now, but hey, you never know what will happen... sprites move, cameras pan...
3. Lights, camera, action!

this probably doesn't help you at all.
hehe

[Paulius]

Partitioning space for movable units is very likely to be slower than simple culling using bounding rectangles, you could make a container object with a pretty large bounding box and put all unmovable objects in its area in it, so if it?¢_Ts culled you don?¢_Tt draw objects which it owns. You could also optimize for OpenGL, but since it?¢_Ts not likely to become you?¢_Tre bottleneck you may not want to bother and it will break you?¢_Tre current structure. You?¢_Tre objects shouldn?¢_Tt know how to draw themselves, but better just contain material and coordinate data. You should do some kind of material management to minimize state changes, you could sort objects by material or at the very least check if it?¢_Ts the same as the current one and doesn?¢_Tt need to be passed to OpenGL again. glbegin/glend are also a bit expensive, sorting by material will help you to minimize them.