Hello! Just like, probably, a lot of Defold newbies, I’ve quickly found out that there are no standard functions to implement complex navigation between game screens in Defold. The provided examples only show the general idea of switching screens with collection proxies but games usually have more than just two screens. So I came up with an idea to develop a reusable navigation solution. I took the inspiration from UINavigationContoller in iOS and React/Redux.
This router gives you several navigation methods:
state machine approach to navigation (which, I believe, suits games perfectly);
navigation stack (with two variants of pushing the scene to the stack);
show popups.
You can use it as a library in your projects (all instructions are available at Github). I’ve also created a demo project to demonstrate all possible navigation methods.
I would love to get any feedback on this library. Do you like it? Will you use it in your projects? What functionality you’d like to have in it?
I’ve got the following ideas for the new features:
Support custom animated screen transitions (I will provide several examples and ability to write your own ones)
Optional saving of scene states to persistent storage so you can persist your scene state between app runs
Optional saving of the navigation stack to the file so when you run you game again, it returns back to the same scene where it was left (of course you will need to use states to restore your scenes).
Also I will add asserts for easier debugging.
What does community think of these ideas? Will they be helpful for you? Is there anything else you would like to see in the library? BTW, has anyone tried to use it in your projects?
Thank you very much for sharing this very nice piece of code.
I just tried it today and it looks very nice, simple and powerful.
Now that the rush for submitting your game to the GDC is over, I will spend some time implementing this library into my game and see if I could use it for any of my future Defold projects.
that’s a great addition to Defold’s core, very well written on top of that.
I’m currently testing your library in one of my pet project and really likes the design of it.
One thing that I’m a bit puzzled about is the impact it has on a splash screen/pre-load mechanism. At the moment, it seems the main bootstrap collection has to evaluate and load all asset (atlases and such) from all the collection proxies before showing anything when launched from an actual device.
I’m wondering if I should split the routing main scene from the splash-screen that is suppose to hide the initial loading of the game and must be presented to the user before anything else.
May I ask how are you handling this?
Thanks for all kind words, everyone. Yes, I plan to add new features to the library soon. The development was put on pause because I’m working on my game as well
@Nicolas_Darques as far as I know, collection proxies don’t preload any assets (that’s what factories do). I don’t know for sure so maybe anyone from the Defold development team can confirm that. But I’m almost sure that it’s true because, for example, when you instantiate an object/collection from factory, you get it immediately but when you load a collection with proxy, you have to wait for the message to use it. So, load time should not be affected.
That would make sense, indeed. I’m wondering if the 3-4 seconds freeze are not related to loading/initializing the engine then.
The question would be then, how one does achieve a nice splash/loading screen at launch on Android.
If the bootstrap collection in game.project is a very lightweight collection with the bare minimum in terms of graphics to show the splash and then you have a collection proxy that you load using async_load and not load then you shouldn’t get any significant hitches.
I will update the library with async_load today. Also, I’m not very familiar with Android (I’m another Apple user ), as I understand there’s no built in support for splash screens like on iOS. If so, I can definitely add a support for a special launch screen. I’ll think on it today.
I believe the router should give the possibility to use “async load” or “regular load” depending the use case.
Async_load is merely a non-blocking load spread over multiples frames if I understand correctly. That wouldn’t be always the best option.
From what I gathered it’s difficult to create a loading screen with a progress bar that does reflect actual metrics as Defold doesn’t expose anything that would allow you to compare what has been loaded to what’s need to be loaded.
Maybe if you break down your game in a set of collection proxy that you “async_load” one after another, as each proxy would send you a message once it’s done, but that seems contrived and hard to achieve for most cases.
Now, I believe a loading screen with an animation loop can be done using the same method as described before for creating a splash screen. Namely having your “loading screen” collection as bootstrap with in it :
the bare minimum to achieve the desired animation.
a collection proxy that points to your main collection.
a script of the following form:
function init(self)
msg.post("#main", "async_load")
end
function on_message(self, message_id, message, sender)
if message_id == hash("proxy_loaded") then
-- Splash screen must die!
msg.post(".", "disable")
msg.post(".", "final")
-- Show main collection
msg.post("#main", "init")
msg.post("#main", "enable")
end
end
