Im starting to build a 2D adventure (as for example the classic “Monkey Island” or the more modern “Machinarium”)
It would be a series of single screens where the action happens. - like for example “Machinarium”.
I’m wondering what’s the best approach to this.
Make different scenes and make the GUI a prefab so it’s shown on every scene.
Make the different screens in different positions in the scene and move the 2D camera to each scene when needed.
I have to say that every scene has a 800K -minimum background image and I intend to realease the game for ipad and android tablets.
As far as I see it option 1 seems more logical to me, but maybe option 2 is more efficient.
Any advices? Am I wrong? Can anybody with previous experience enlight me?
Option 1 is really the only option, because having all the “scenes” loaded at once will be too taxing, especially when going mobile/tablets. You could possibly have “sub-areas” of a main-area (main area being for example a city-view and a sub-area being inside a house from that city-view), but that means you’ll use two loading-systems for your scenes, which can get confusing. I’d say just stick to option 1, loading the scene you’re at and load a new scene when you’re entering a door or whatever. That way, you won’t have stuff you’re not showing taking up your precious memory to run everything smoothly.
What about option 3: Have each scene consist of several screens that exist in the same in-game area and simply change the camera background when changing between screens?
Prefabs can be dynamically moved into/out of place for each screen, or can exist in the correct positions relative to one another and have the camera move to where the center of each screen takes place, using the camera transform as a user coordinate system. This may make it easier to divide your game into chapters, between which NPC states and interactions won’t need to be saved (e.g. Mêlée IslandTM vs. Monkey IslandTM). If each screen is its own scene, you’ll have a logistical headache in trying to keep persistent the numerous game progression flags.
That’s basically what my “Sub-area”-idea involved. But as I said, you’ll still use up memory for lots of stuff that you don’t see which you don’t want. Since you need to load scenes anyway I don’t see why you should have sub-areas, that just means you have to figure out if you should reposition the camera or load a new scene. Not hard, but it adds extra complexity. Or wait, maybe you mean that each scene is a prefab that’ll be loaded/unloaded into the same scene when needed? I think that would basically be the same as loading an entirely new scene.
Well, game progression will always be messy in some way. You need to keep everything persistent between game-sessions too, so you’ll always have to keep some kind of persistent boolean if you have the “X” item in the inventory, or if you talked about “Y” with person “Z”.
In point-and-click adventure games, you will need to track a ton of flags for character and environmental interaction, including whether certain dialog options are available, whether you’ve been to certain areas yet, and whether you’ve given then items, etc. There are going to be a ton of these, but quite often once you progress past a certain area and start in a fresh one, there is never an opportunity to return to earlier areas, which means their flags can be dumped. This was the case for Monkey Island and games like Indiana Jones and the Fate of Atlantis, and not really applicable to games like Maniac Mansion and DOTT. It depends on the structure of the game progression, but if it applies, then you can also save on keeping flags persistent between plays for areas that are no longer accessible, and it fits the by-scene model that I described.
I still argue that tracking flags is going to be the biggest headache in this type of game, and so you would likely want to compartmentalize them if possible (I suppose it depends on whether OP’s game fits the description above). To this end, using less scenes is preferable, while, depending on the size of the game, using only one scene probably isn’t ideal either. Probably the biggest consideration would be the large backgrounds, and they can be unloaded when not in use if necessary.
Using one scene for each screen would work, obviously, but this method makes more sense to me.
About the game progression state - having in mind that im just at the inception of the game - I was thnking of using an xml file. Actually 4 xml files as “save slots”. Every xml file with all the flags needed for the game. Everytime an event is done the flag gets saved in the correspondig xml-slot. The xml can be structured having a parent node for each screen so its all in order and easy to mantain.