Levels using Diddy.
Monkey Forums/Monkey Programming/Levels using Diddy.
| ||
| I just wanted to say that Monkey is looking great, as is Diddy. People have obviously put a lot of work into this, and it shows. I have a feeling that the tile system, the screen system, and Monkey itself are going to save me a lot of time on the platformer I'm working on. That said, I have one thing I'd like some input on, that wasn't obvious to me from the example files. Ideally I will have multiple levels in my platformer, and it seems as though making diddy screens would be the best way to accomplish that. However, given that I have many levels, should I create some sort of game manager that checks the current state of say a level_loaded variable with select/case and then null out the previously loaded level/screen object? In the example files it loads all the screens at once, and they seem to persist until the game is closed. For a title screen and one level, this is no problem, but generally I would say that is a bad approach if I'm loading multilayer tiled levels in quantities of 5 or more at application startup. The second question I have is, is there a way to make sure the GC runs between levels, rather than during playtime in another level, to free up memory from the previous level? Any input on a system that might be appropriate to accomplish this and minimize problems with program performance and memory use, would be appreciated. :D |
| ||
| The screen system is designed to be used for different portions of your game. So you would have a screen for main menu, options, your game and an end of game for example. You wouldn't use a different screen for each level. You would load the level in the game screen and clear it out and load the next level in the same game screen. |
| ||
| Yes, +1 for not using screens (or layers) to hold different levels. Layers or screens (depending upon the framework) are designed to contain different elements that you would show at different times back and forth. This makes it easy to move around your state engine (menu mode, play mode, game over mode, enter high score mode, etc.). This lets you ignore objects and things that are not in the layer/screen you're currently interested in without having to think about them at the time you need them-- just design your individual layers and show/hide them as you need them. This is totally distinct from what you're doing. To do what you're doing, you would have just one gameplay layer (or screen) in which all your action happens and takes place. When your level ends, you would show your interstitial or load screen (if you like), zero out the gameplay layer, and then reinitialize it with the next level (whether that's from data in the program or read in from a file). I do not know enough about GC to know when or how it runs, but I do believe it's slightly platform dependent. Personally, I'm not thinking about this until I start to see problems. :) |
| ||
| Why0Why is correct, you wouldnt have a screen per level. Check out the platformer example: http://code.google.com/p/diddy/source/browse/trunk/examples/Platformer/screens.monkey Within the GameScreen class we have this line: Local tm:TileMap = reader.LoadMap("levels/level1.tmx")This could easily be changed to: Local tm:TileMap = reader.LoadMap("levels/level"+player.level+".tmx")So every time a player gets to the next level (player.level+=1) and the GameScreen is displayed the level would change. |
| ||
| I used one screen for all my levels, but I used a separate screen for the inbetween areas and fading. it seemed to work out well and was easy to move between screens. I don't know if it is the best use of these things but you can check out the source here. |
| ||
| Ok, thanks for the advice. I can certainly setup a "level screen" and load/unload that way, then just use the screen system to handle the menu or options windows and such. Makes sense, and now I'm glad I asked. :D However, the main concern I have here is avoiding a GC during the process of gameplay. Is there any way to trigger the garbage collector (on any system), after the destruction of the previous level, and before the creation of the next level? My thinking here is that I can make a very memory static level to level game, by loading at level start, creating object pools for everything that spawns and despawns, then just dump all of that at the end of the level, which seems the ideal time to GC the memory. I guess another question would be, what are the best ways to store information that minimize the amount of GC that needs to run (on any system), given that not a lot of data will be persistent from level to level, and I don't want to be freeing memory from the previous level, or many previous levels, while playing another? |
| ||
| Based on therevills post...and some more thought, essentially you're saying to instantiate the game screen, but then call the Gamescreen Start method with a different value for a level variable. This will load new data into the existing Gamescreen object, which should write over top of the current tile/level data... Is that correct? If that's true, I think I see the light, as all I need to do is manage one state variable to control what level the player should currently be in, and memory is only a function of how big I make each level because the object is being overwritten with new information... |
| ||
| his will load new data into the existing Gamescreen object, which should write over top of the current tile/level data... Is that correct? Bingo :D |
| ||
| Thanks for the help. :D |
| ||
| tiresius, No source code is available for download on the Google Code Project site. "This project currently has no downloads." |
| ||
| No source code is available for download on the Google Code Project site. Check the source code: https://code.google.com/p/the-lost-wand/source/browse/#svn%2Ftrunk |
| ||
| Thank you therevills, I forgot to click on "Browse" in the Source Tab. |
| ||
| I use a global to track current level but I like the idea of sending it as an argument to Start() method, I'll have to try that out sometime. This will load new data into the existing Gamescreen object, which should write over top of the current tile/level data... Also having a level as its own object might be easier as you just instantiate a New level object and the old one will be GC'd away on its own. At least that worked for me where levels were not cached. |
| ||
| I usually use an Init() function which regenerates the level in place. Making an entirely new one is fine too, but you need to remember to tell anything that holds a pointer to the level object. If you just make a single level object at the start, you don't have to worry about it moving. |
   |