Lessons learned in isometric style gaming

Games
#1

Lesson 1: If you are thinking about making an isometric game, DONT (there are so many little nuisances that you never realize until you are trying to fix them)

Lesson 2: As objects change order in the display group (to come in front or go behind other objects) as they move around the map, then you can’t iterate through the display group when animating your objects, D’oh! In other words, don’t iterate through a list that changes as you are itermarating it.

Lesson 3: Making art for ground tiles is way harder, in fact, I’m still trying to figure out how not to get a weird repeating pattern… I think I’ve got a solution, but I haven’t implemented it yet.

Anyway, here is a preview of my game. It’s very rough right now, but at least I’ve got the animation and z-order stuff worked out (as well as A* algoritm, bezier curves, etc. etc.)

gorillas [import]uid: 62193 topic_id: 20022 reply_id: 320022[/import]

#2

How does your sorting algorithm work? Can you gather all your display objects, sort them, then insert into the parent based on their index like so?

[code]
local sortedObjs – your sorted objects

for i=1, #sortedObjs do
container:insert(i, sortedObjs[i])
end

You need to add more noise to your tiles. Or go with solid colors to prevent the appearance of tiling.

[import]uid: 27183 topic_id: 20022 reply_id: 78104[/import]

#3

Well, until I had the characters making smooth transitions, sorting was not an issue. In other words, if the object was moving up on the screen, it would re-insert itself into the display group at a lower index value.

Once the characters were making smooth transitions however, the problem of when and how do you decide that a character is behind another character. You cannot possibly resort all the display objects every single enterframe (although maybe you can? it would solve the issue) Here is the issue. Imagine this is your set of tiles:

0 0 0 0 0 0 0 0  
 0 0 0 0 0 0 0  
0 0 0 0 0 0 0 0  
 0 0 0 0 0 0 0

Clearly, each “row” will have a different z-index. However, objects along that row may be in the display group somewhat randomly, but all grouped together. So if you wait until after the character has walked “up” on the screen before changing the z-index, there may be a weird effect that he is walking on top of something he should be behind, and then suddenly snaps behind it once he has reached the new position. So the best thing to do is actually, as soon as you know the direction he is moving (in this case, let’s say “up”), you need to shift the object behind all the other objects in the “row” that he is starting from. That works, and keeps you from having to resort everything all the time. [import]uid: 62193 topic_id: 20022 reply_id: 78112[/import]

#4

Actually, don, your comment has prompted some questions I’ve been having… What is the cost of inserting into a display group I wonder…? Clearly all the objects higher in the group need to be re-indexed, but is that a costly process?

Also, thanks for the suggestion on the tiles. I think I am going to go with solid(ish) colors, with leaves/rocks/etc. scattered on top as separate objects. [import]uid: 62193 topic_id: 20022 reply_id: 78113[/import]

#5

we are also doing an iso game, 99% done. for sure, missing z property sucks a bit. we also did the trick with sorting and reinserting into the group and it seems to work just fine. for sure it depends on the objects, we only have like 20 that need to be sorted. beside that, all is the same as with non iso view. so we can’t really share your opinion (yet).

good luck with your game! [import]uid: 90610 topic_id: 20022 reply_id: 78128[/import]

#6

@dmoore764 In my tests sorting the display objects has a fixed cost (well not really, but…) Basically if you’re trying to get 60fps while sorting, forget about it. But 30fps you can sort hundreds of objects.

In iso engines I’ve built in the past (using flash) I would sort the scene every frame because I had hundreds of moving entities.
[import]uid: 27183 topic_id: 20022 reply_id: 78136[/import]

#7

Congratulations on (almost) finishing your game! Considering this is my first venture into game programming, maybe there are hidding nuisances for all game types, and I just don’t know about them (yet!)

For my game, I want there to be a crazy amount of action going on (like several hundred characters walking around), so, even though I didn’t think about just re-sorting every frame, I still think my solution will work better in my case, because I’m only iterating through the list of objects once per move, and a move only happens every 20 frames or so, depending on how fast the character is moving (and not everything is moving, like buildings and stuff, which saves some time as well).

Edit: I also started programming about 15 years ago when processor cycles were more precious, and brute-forcing something would always end up chugging along. These days, maybe I should just spend more time adding features and worrying about speed when it becomes a problem… [import]uid: 62193 topic_id: 20022 reply_id: 78137[/import]

#8

I agree with you, in our game performance is not that crucial and we only have the main char moving. its good to see others facing some similar challenges!

fps: we run with 60fps, no probs, but as already mentioned, this depends on the number of objects.

I hope to submit the game next week, the artwork is great in my opinion.

[import]uid: 90610 topic_id: 20022 reply_id: 78146[/import]

#9

More issues to think about: what is the z-value of something that takes up more than one position on the map? Going back to our example map, here is something that is larger that is placed on the map:

0 0 0 0 0 0 0 0  
 0 0 1 0 0 0 0  
0 0 1 1 0 0 0 0  
 0 0 1 0 0 0 0  
0 0 0 0 0 0 0

For this object, it is actually easy to figure out, the z-value is the same as anything else on row “3”. But what if the object is not square? A person walking around the map is represented by an “x” E.g.

0 0 0 0 0 0 0 0  
 0 0 1 0 0 0 0  
0 0 1 1 0 0 0 0  
 0 x 1 1 x 0 0  
0 0 0 1 1 0 0  
 0 0 0 1 0 0

In this case, the “x” on the left should be in front of the building, but the “x” on the right should be behind it. Yet they have the same z-value… So far my only solution is to imagine this rectangular object as two separate square objects with two separate z-values (and two separate display objects), i.e.:

0 0 0 0 0 0 0 0  
 0 0 1 0 0 0 0  
0 0 1 1 0 0 0 0  
 0 x 1 2 x 0 0  
0 0 0 2 2 0 0  
 0 0 0 2 0 0

Now the z-value for the top portion is “3” and the bottom portion is “5” [import]uid: 62193 topic_id: 20022 reply_id: 78149[/import]

#10

what about considering also the x position? so the row, ypos, is in this example 4 for both x and the building.

and now, add the x pos like: 0.01 * xpos, makes a value between eg 4 and 5. now use this value for sorting.

i might be wrong, watching tv and writing on ipad, but it might work?
[import]uid: 90610 topic_id: 20022 reply_id: 78153[/import]

#11

Yes, clearly the x position plays a role… Thank you for your comment. So far all the objects I have been working with are square, so I haven’t implemented a solution yet, but I’m liking what you speak. Sometimes the biggest step to solving a problem is articulating it in the first place. Articumalation is often my biggest hurdle… [import]uid: 62193 topic_id: 20022 reply_id: 78155[/import]

#12

I think you’ll be fine. and yes, being able to describe a problem is not always that easy :slight_smile:
i am glad i could give you an input, happy coding! [import]uid: 90610 topic_id: 20022 reply_id: 78156[/import]

#13

Sorting square objects is much easier. Calculate z-order by calculating the y position on screen of the mid point of the iso object. Then sort those values to determine the display order.

Rectangular objects are harder but more accurate. The best algorithm I know is O(n^2), but you can spatially partition the scene to get linear sorting behavior if the world is sparsely populated.

But the best thing to do is to split your objects into squares.

[import]uid: 27183 topic_id: 20022 reply_id: 78160[/import]

#14

@don: indeed… for my game it is not mission critical to have oddly shaped objects that are more than just a combination of squares… so I think I will stick with the simple solution [import]uid: 62193 topic_id: 20022 reply_id: 78162[/import]