Should I split my game world into several different frames, or put everything on one single gigantic frame?
I'd have to copy a huge portion of the code into every different frame, but the frames would be significantly smaller. I'm just not sure which is more important for keeping the game running as smoothly as possible. Fewer events, or smaller play areas? (Or maybe it doesn't really matter either way?)
Well's there's 3 options you have.
1) If you don't know lua/python and you can make a level editor, then keep everything in one frame. Much easier to manage than +40 frames , especially if when you'll need to go back and make small edits. The better the level editor you have, the easier it'll be to have one frame. It does take getting used to migrating from using MMF2's frame editor to your own personal. I use this method myself, and I don't think I can ever imagine going back. As for handling levels, I segment the level into multiple parts. This way loading is faster and editing is much easier. It also allows me to make levels as big as I want them to be without worrying about consuming too much memory. Typically something like:
[Level 1 - Cave]
Level 1, Part 1 = 20KB.
Level 1, Part 2 = 20KB.
Level 1, Part 3 = 20KB.
Then after completing a level part, the player progresses into the next part. Loading is nearly instant and much better verses loading one giant clunk of a level.
2) If you know lua/python then you can have several frames since majority of the code would be in the scripts. You get more power and flexibility from using such functions as coroutines and being able to have a textural representation of your code. I still would not suggest having multiple frames, since more than likely half the objects/events you're using will be shared between all of them anyway. Adding more frames also creates a bigger executable. Without a doubt scripts are more easy to organize than events/groups.
3) If you don't know lua/python, nor how to build a level editor, then several frames are the only option. Someone may have a good workaround to dealing with it though. I haven't used multi-frames for my main engine in quite some time.
How smooth the game runs largely depends on your events. The amount of events you have does not make a difference if you know how to manage it. You can have 1 condition that is x10 more resource tasking than 1000 events, but lesser events are easier to manage. As I've said before I have 7.6k events yet even on old machines the FPS never drops below 59. The virtual width/height don't have an impact, but the physical application size will. A game being ran in a 1600 x 1900 window will most certainly be more tasking than one ran at 256 x 223. Instead of making huge graphics, make things on the small scale then let the user amp the resolution up x2,x3 and so on.
I've actually already made my own world editor with MMF2, since the game is made up of 16x16 tiles, and placing them in MMF2 would be a nightmare. I've set up the editor to create the world map in several 720x480 "regions", which are then simply saved as a PNG image. I was originally planning to have one region per frame, but considering the way I've set this up, it would probably only take a few minutes to place all of the regions into one frame.
i don't know python/lua but i have made this work before.
how i did it was to create a group for each level, which is disabled and all movements stopped that are used in level1 and all elements are turned invisible.
disable and enable each level (group) as necessary, being sure turn stuff invis, etc when you disable a level/group
when the player completes the level, you disable group1 and enable group2.
within group 2, you turn all the stuff you need from invisible to visible, start movements, etc
a huge frame with lots of active objects will create slowdown in Flash applications (no so much in the PC version, but still at some point it might).
Don't waste your time making level editors and stuff like that, I've gone that route before, but like I read it somewhere "MMF is already the level editor". Just have all your main game code in the global events, work with global objects only and life will be much easier. You can't use qualifiers that way but it's still worth it since it saves you from a lot of trouble. You can use each frame's events for scripting stuff related only to that frame and local frame variables.
If Load on Call is checked for all objects, then only the objects you need loaded should be used. (Ie, the objects used for that specific stage) I'd hope if they were using the one frame method they wouldn't have every single object loaded initially. That'd defeat the purpose of using a level editor. You shouldn't need the entire game's resources utilized every level. Also since most of the content is done externally with level editors, there shouldn't be much of anything in the frame.Originally Posted by oruga
Global events are far too limited for main events. The fact every object needs to be imported + lack of alterable value names would make things disorganized and messy quickly. (Unless you plan on using global values/strings for them all, which without a doubt would get messy quick) Qualifiers are essential for large groups of events that behave similarly, and it would be a pain to re-paste it in every frame if changes are needed.
For small iphone app games or flash games it's not a problem to have maybe +10 frames. Anymore and it'll be a nightmare of redundancy.
"For small iphone app games or flash games it's not a problem to have maybe +10 frames. Anymore and it'll be a nightmare of redundancy."
Yeah I tend to agree with that. You have to weigh the payoff for using a level editor. If your game isn't going to be huge, there really isn't much of a reason to use a level editor quite honestly, unless you want users to be able to create their own. I don't care what people say, making a level editor takes a lot of time and is a lot of work, especially if you are not an advanced user. It could be hair-pulling frustration that probably wouldn't even be necessary depending on the game. And if your levels are pretty complex creating a level editor could be even more of a nightmare.
That said, a level editor can be pretty helpful and does have its uses. If you decide to create a level editor, I strongly suggest you design it in a manner that it could be fairly easily adapted to any project. That way, you make it once and you pretty much don't have to do a whole lot ever again.
In the case of my game, since it's an RPG, the only active that will ever be actually moving is the character's overworld sprite, and then I have 4 actives per region (56 regions in total, separated in that manner to make it so different regions are rich in different crafting materials, as well as to have different monster libraries for each region) for collisions/water/etc., and then 1 for each dungeon entrance, which is on average going to only be 1 per region... so that's around 280 actives being used at any given time. Even though the frame is 5760x3840, there's so little that actually happens in it, that it seems like it would be a waste to separate it to different frames, and have to worry about smooth transitions between them.
(And the actual world is just a backdrop btw, as there's no direct interaction with it. Which is why I made the level editor. I think it'd be a lot more of a pain to position a million actives in the mmf2 editor, and then take a screenshot and make it a backdrop.)
Edit: And now that I think about it, I can actually use just 1 single active for all of the dungeon entrances on the map, and then choose which dungeon to send you to based on the player's position... so subtract another 55 from that active count.
Posting Permissions
Reply With Quote