Should I use this engine if


#1

Should I use this engine if my scope are Android and iOS user ?
I would like to build Terraria type of games.
Pretty big and open world but just pixel art to reduce lagg.
Do you think this engine can handle it?
How about finish game performance on the devices?


#2

The engine can certainly support a Terraria type of game though you need to use some optimization if you want to be able to delete all tiles like in Terraria but doable I would think.

However, there is no lights in GDevelop, so you won’t be able to create dark corners below ground and torches.

As for Android, personally I am not a big fan of HTML5 when it comes to mobile. I can’t recommend HTML5 for a mobile first game. I just don’t like it personally. But technically it can work, you can make Android games with GDevelop.


#3

I guarantee you that it’s possible. But for the performance you will need to do a lot of optimizations, as this engine is more made for productivity and ease to use than high performance.


#4

Yeah. Performance is a big key to. Mind sharing how to optimize game here ?
Other than delete something out of camera view


#5

Don’t display too much tiles at once. Don’t use physics if not absolutely nessecary. That’s the most important ones. It shouldn’t lag if you respect that.


#6

The biggest problem is collision checking. In a Terraria type of game you may end up checking collision with hundreds if not thousands of tiles at once and this is what you need to avoid.
The best way to do it in my opinion is to divide your game world in to zones and use different tiles for each zone and check which zone the player is inside.

If player is in zone1, check collision with zone1 tiles
If player is in zone2, check collision with zone2 tiles.

Depends on how big the game world is going to be you may going to need a lot of zones and tiles for each zone.

You can define a zone by either using an invisible object as the zone marker.
If player is in collision with Zone1 then it means player is in zone1. But if you have lot of zones, it could be a problem.

The other solution could be is to check the player X and Y pozition. It is a better solution but you need to keep in mind exactly where each zone begin and where each zone end at which X and Y coordinates.
You can store the coordinates for each zone in a structure maybe.


#7

He already said he would delete all objects that are not visible


#8

It may require more resources imo to constantly delete and create objects if you have hundreds of them, you also need to constantly write and read in to storage the location of each tile if you can delete and move them around like in Terraria but could work, worth a try.


#9

The most effective solution could be if we could simply put objects in to “sleep” which means we take it out of rendering and collision checking, all behaviours would be disabled as well and the objects would be totally ignored and when you need them you can just “wake” the objects so you don’t need to go through all the initialization process when you create a new object from scratch. But GD doesn’t support anything like this. You either have an object in the scene or don’t. Not all engines support staff like this actually but I think it is very useful especially for open world games with physics.


#10

Thanks for the reply


#11

Ok. Thanks…


#12

Collision checking is indeed going to be a headache to get good performance - and in general making sure you reduce the work for the game to only the necessary (what is displayed on screen and what is around characters essentially).

If you use the physics engine, bodies (i.e: objects) that are not moving are put to sleep by Box2D, so you should be able to handle a fairly large number of objects, but I’ve never tried a huge open world with it.

If you use the built in collision engine, a very large number of objects will be hard to filter quickly. I’ve actually being working on an optimization that will greatly reduce the number of checks when you’re checking collision, but also distance and raycast between a lot of objects (in a nutshell, storing object positions in an optimized data structure allow to quickly discard objects that are too far).

In benchmarks I’ve done, this allows to keep 60fps in extreme cases, like for example testing the collision between thousands of objects against another set of thousands of objects (well if they actually collide, collision checks have to be done so FPS are decreasing dramatically - but if you keep the objects far from each other, they don’t impact performance!).

This will also help the “distance” condition. Currently, even if it’s a good idea to use it to filter out objects that are too far, it’s iterating on all objects living in the scene. With the new optimization, GDevelop will internally find much more quickly only the objects that are in the area where the distance check is made - discarding all other objects. Benchmarks also show a very nice improvement when testing distances between hundreds of objects.

This will probably land in the next 2 or 3 version (I have to extensively check that this is not making any regression or bug).


#13

Umm how about something like stove in Minecraft. Will it not cooking when player is not in home area. You know you put meat in there, let’s say you have to wait 5 minutes and It cook itself.


#14

You can use object timers but obviously if you delete the object it won’t work.So if you decide to delete/create objects as you move around the world, do not delete the stoves bot only other tiles and let’s hope the player is not going to put hundreds of them in to the level.
Or if you choose the way I was suggesting using zones, then it should be not a problem as it would be to reduce the number of collision checks only but the stove should keep cooking regardless if you have enough fuel in it and something to cook.