Vertigo (Beta)

[kalle2990]

Vertigo is a clone of the game "Vertigo", the goal of the game is to navigate through the rooms in a map to a goal (which doesn't exist in this Beta). You simply use the arrow keys (left/right), or A and D to move and W, S, Up, Down or Space to switch gravity. There is no jump in this game which means you have to figure out how to get from point A to B. The game includes a level editor to create your own maps and an example map with 3 rooms to play. Creating a whole map can take a while since they consist of 64 rooms with 50x33 tiles in each room (1650 tiles) making the number of possibles maps very big. The maps are saved in the AppData directory and can easily be shared with others, please upload your own maps to this post. All rooms links together, so when falling or running out of a room you moves to the next one.

Vertigo.png (8.04 KiB) Viewed 2492 times

Vertigo2.png (11.15 KiB) Viewed 2492 times

Map editor controls

• Q = Change tile type
• E = Change wall color
• Arrow keys = Change room
• F2 = Back to game
• Y = Load
• P = Save
• Click = Place piece
• Shift+Drag = Create selection
• Enter (when selection) = Fill with tile
• Delete (when selection) = Delete all tiles in selection

All ideas are welcome

EDIT: Uploaded version with collision check only for the 20 tiles nearest player instead of the 1650 ones, it should be 8250% faster.

[bartbes]

I only recently played the original (did you link it on IRC?), and I must say this is pretty good, even the graphics, did you rip them? One problem was that I had terrible performance.. and sometimes it seemed like you floated a while before you landed on the floor (/ceiling), which was pretty annoying.

[kalle2990]

Yes, I took the graphics from there.. (Not the stars in the back though) And the terrible performance you are talking about might just be because it doesn't lag on my computer, but on everyone else's. The floating is known, it shouldn't really matter with a high FPS, but with a low one it does. To save performance, it only checks a jump of the pixels moved and not every pixel. When it makes a collision there it checks for the 'floating' one, checking only 1 pixel. If the FPS isn't 60 (as it if on my computer) it could effect both of them since you have to use the pixel one earlier and slower...

This is most probably because it needs to check collisions of 1650 tiles with the character around 2-4 times a frame, which is lagging alot on slow computers

[bartbes]

on slow computers

I never considered my computer to be slow!

[kalle2990]

slower than my computer*
No, you're right, your computer is great, I shall fix my game!

[leiradel]

This is most probably because it needs to check collisions of 1650 tiles with the character around 2-4 times a frame, which is lagging alot on slow computers

You could reduce the number of tests by testing only the tiles on the player's neighborhood.

[Jasoco]

You should put all the tiles in a grid. Not load all of them at once then check collisions against every one. Put them in a grid then check the player overlapping the surrounding tiles. Instead of checking against every tile every frame.

[kalle2990]

Thanks for the tips, I will add that

[schme16]

You should put all the tiles in a grid. Not load all of them at once then check collisions against every one. Put them in a grid then check the player overlapping the surrounding tiles. Instead of checking against every tile every frame.

Thanks for the tips, I will add that

Good to see your taking that on board, although performance wasn't an issue on my PC, I could immediately see the problem with running a collision model that way.

Apart from that the game is excellent! Great time waster my suggestion would be to add a way to upload custom maps to a server and have a map browser built into the game

[willurd]

This is most probably because it needs to check collisions of 1650 tiles with the character around 2-4 times a frame, which is lagging alot on slow computers

You could reduce the number of tests by testing only the tiles on the player's neighborhood.

You can also drastically reduce that count by "attaching" the player to a tile when you find that they collide with it, and then maintaining a reference to that tile somehow (like by keeping the index of that tile in your tile array). Then when the player moves, you can check that tile first to see if they are still touching it. If they are then you only had to perform one check. If they aren't (or in the case of when the player changes orientation, which will always mean they'll be colliding with a new tile), then you can just perform collision detection on the tiles that are displayed in the window (that's supposing of course that your collision detection operation is more expensive than the operation of figuring out if a tile is viewable). You can do other tricks like maintaining the collection of viewable tiles until the map moves. That being said, the worst case you'll ever come across doing it this way is having to check the position of 1650 tiles and then do collision detection on the viewable ones once for each time the player moves off of the attached tile or changes orientation, which can happen like, what, once or twice a second, rather than 120-240 times a second (2-4 times each frame, 60 frames a second) like it's doing now. Or, to put it in perspective, that's at worst around 4,000 operations a second doing it this way, as apposed to at best around 200,000 operations a second the way it's currently being done. A 5,000% increase in performance