Printable View
Ive been working on a few games with Multimedia fusion 2 and Games Factory 2, and it fells that the more conditions I add the more glitchy game becomes, things that worked perfectly fine when level only had less than 100 conditions, work 75%, or even 50% of the time when that number gets larger and larger.
Is this a normal issue? Is there a way around this problem?
I don't think so. It's probably either a bug in your code, a corrupted MFA, or an obscure bug in MMF2. Hard to tell which one. I have games with more events than that, and they work fine...
I believe you, I wonder why Ive battled have this problem with every single game I've made ever since I worked with the Trial version of Games factory 1, on different computers with different OS.
It feels as though the game skips some conditions (not always) when there are too many at once. It does improve sometimes when I "Limit Conditions" but not always.
How would a MFA get corrupted?
Here is a question, Is it better to try to use one object for multiple uses with tons of conditions (ex: one bullet for every variety of gun upgrade, and every type of enemy bullet. with extra code that determines bullets animation, disable/enables certain collisions,and damage ) or have separate objects with not that many conditions (ex: one separate object for every bullet, and enemy bullets with a simple collision check)?
DelphaDesign
In my experience this is normal
For instacne im having an app with 1k Events and alot of complicated stuff.
Because there are "wires" and stuff all over the place, basic things which is expected to work within secounds from a blank App turn into long mystery chases.
However i allways find the problem, which range from simple faults to delicate hidden details, with enough time and determenation.
But usually the first thing i think about durring such encoiunters is "BUG!"
Really what this boils down to is your code.
How clean and organized is it? You say this only happens with large projects. My guess is that your large projects get messy and you have events that interfere with other events in ways that you aren't seeing because things are jumbled.
Do you organize with groups? Do you comment code? It could very well be an object selection issue where you haven't set up events in a way to properly select objects and instead MMF is just guessing which object you're referring to.
Also I'm going to state the obvious and ask if you are maxing out the object limit for the frame.
Thanks everyone, Honestly I don't use comments and While I do use groups they are generalized so not very organized. So it is very possible that i'm not not doing things correct and cannot see my mistake.
What do you mean by this?Quote:
Originally Posted by Konidias
I don't believe i maxing out object limit, but wouldn't this just slow down the frame rate?
No. Object selection is MMF2 determining which instance of the object is the one you are talking about. It is very awful at doing so. However, if you use the ForEach object, you can easily fix such issues.
Well a frame has a limit to how many objects it deals with... default is 500... so if you don't increase this and you go over that limit, you get really odd things happening with objects.
I wish MMF had a way of alerting the user through debug or something that the frame has reached the object limit.
As for the object selection thing... basically what happygreenfrog said. If you have a lot of conditions/events dealing with a particular object or qualifier group, you could potentially run into issues with contradicting events or something... or if you are not properly setting up the condition, it is checking an object instance at random and not precisely the one you were wanting to select. Stuff like that can break things when projects get big.
As previously mentioned it all boils down to the efficiency of your code and technical skill. For the lengthier projects, it helps to at the very least think about the full project or big section of the project before implementing code. I'd go as far as saying mapping out the code via drawing would reduce bug/errors.
No, it isn't. Behaviors are so that you can have objects behave the same way in multiple frames by simply dragging them into a new frame (try a widget to see what I mean). Also, as we have told you many times, you probably shouldn't use behaviors, since they are buggy and were kind of "hacked in", so to speak. And by "hacked in", I mean that it involved working around the old code (some of which dates back to Klik 'n' Play, from the sounds of things) to make it work. Also, you can avoid (but not completely stop) code from contradicting itself by using ForEach loops.Quote:
Originally Posted by OldLongDragon
Object behaviors have issues and become a huge hassle to work with... continue using them if you want, but if I were you, I would be taking the advice from people who have been using these products for years (some of us over 10 years)
Why are behaviours bad?
'Frame Events', 'Global Events' and 'Behaviour Events' are all part of a MMF2 Applications code.
Although they reside in different locations/ windows, they are all interconnected.
Meanining they are not confined to, and do not work exclusively within, their Event List.
To clarefy further, all three Event Lists are part of a unified "Master Event List":
- 'Frame Events' go first
- then 'Global Events'
- 'Behaviour Events' come last
So for example, since ALL Events are connected , 'Behaviour Events' can very well affect 'Frame Events' or 'Global Events' or the other way around.
But ( ant this is whats realy bad ) the 3 different Event Lists reside in different windows, meaning if you are looking at the 'Global Events' and want to view Goblins 'Bahaviour Events', youl have to:
- Close 'Global Events' window
- Find and Click the Goblin
- Change Properties Tab
- Click on the Behaviour to view the 'Behaviour Events' for Goblin
Think about it, if all of your different Game Objects have seperate Behaviours, and you want to view the code to see how they all affect eachother, or your going bug hunting, or its not your application but your just trying to help...
Youl have to do alot of closing and openig of windows to be able to cross check Events which reside in different portions in the Application.
For medium to large projects, this is doom.
It all becomes very unorganozed to the eys and mind, time consuming, dissorienting, unclear and blurry.
...
Why are Behaviours there at all?
The sole purpose of Behaviours is to make duplicating Events easier for you, well and maybe to reduce the total Event count, and thats it ( correct me if im wrong ).
Having too many Events is almost never the problem with MMF2 creations.
I dont think it even makes the top 10 list of MMF2 roadblocks.
If you organize your Events properly within one of the Event Lists, say the 'Frame Events', duplicating your Events is easily done by marking and copy-pasting.
...
Bottom line, if you ( or you want others to ) want to have a good understanding and totall overview over whats going on in your application, then confine all your code to 1 or as few Event Lists as you can.
Qualifiers ( Qualifiers gives you the power to have multiple different Objects have a single and same referance, for easier coding and saving time ) apparemntly dont work inside 'Behaviour Events' as well.
On the other hand, as i recall, Objects can have differents 'sets' of Behaviours which can be swiched out durring runtime, but for me the downsides of Behaviours heavily outweigh this little feature.
http://i.imgur.com/qzhzc5I.png
Runs slick and quick, 120 FPS when uncapped and thats mostly graphical.
What game is that Pixelthief? :)
Asunder, project I've been working on as a full time job for a couple years nowQuote:
Originally Posted by Outcast
Woah! A couple of years? That must be a big game...Quote:
Originally Posted by Pixelthief
Dev log?Quote:
Originally Posted by Pixelthief
Excuse me Konidias, can you explain more about the issues with behaviors in MMF2? I'm just curious, not taking any side here.
Yeah I've been meaning to restart thatQuote:
Originally Posted by Konidias
Suffice to say Asunder's enginework is basically 99.9% finished, and all the enemies are fully drawn/implemented, and about half the minor 'objects' for the game (doodads, physics, ambient creatures, etc), right now I'm starting tilesets (1 finished, ~17 to go), and applying a layer of polish to enemy sprites.
Anyway I don't want to sidetrack the thread. But I want to assure you its not an abandonware or project spinning out of control, I've got a project plan and work method all figured out for it, its still at least a year off however. The majority of the content is finished and all the real programming is done, its just a matter of filling in the rest of the content and then piecing it all together and building the levels / game itself. Left myself a lot of room to iterate, and I have 6 bosses planned that are undrawn/implemented that will probably be a significant amount of the time
but erm yeah, offtopic
I'd put it like this: objects and events won't stop functioning just because you add more content and features to your game. If things stop to work, it's almost always a result of your events being wrong.
However, when it comes to performance, it's a whole different thing. MMF2 is very weak with iterating through objects. Even with the ForEach object and the most optimized events imaginable, there are operations that you can get away with applying to a hundred objects that you could in other game dev platform apply to to tens of thousands of objects. With sub-events (to get rid of redundant duplicate conditions), a built in ForEach that iterates more efficiently, and other optimizations (for example not evaluating every "on loop" and "on foreach loop" condition every iteration of every loop), MMF3 could become waaaaaay more efficient for power users. Like, fifty times more efficient without exaggerating a bit.
MMF2 is very capable in many ways, but there are boundaries, so yes, a game can be too complex for MMF2. I have some new projects I want to dig into, but they're just too heavy for MMF2 (plus I need sample accurate music layer synchronization), which is why I'm so eager for MMF3.
What about number of frames? Example: Hasslevania 2 has almost 200 frames total and most of them have a **** ton of events + groups within as well as a lot of actives. The project's .mfa is over 200MB and doesn't include most of the voiceovers. It takes nearly 5 minutes to save or load the thing on my computer, and I'm always a little scared that it's going to be too big for its own good and never be finished.
What's the most number of frames you guys have had for your games and have you ever noticed that they don't work properly when you reach a certain point?
By frames you mean levels right? Then I would imagine frames have nothing to do with it. Perhaps its the graphics, are you using global objects how many unique objects are in your game?
For some reason copy/paste code between frames seem to cause issues for me, although the objects are all the same.
Afaik, MMF2 (while uncompressed) stores the graphics for each object per frame, so long as they aren't global. So if you have a ton of character and effect sprites, that are copy/pasted in each level, the filesize will get huge. But I think compression should take care of that on release. I think. Sounds do not behave like this, and code doesn't take up any real space at all (Asunder weighs in at 37.9 mb edittime, 34.0 if I delete all 10000 lines of code). Object properties are class specific too so its doubtful you use up anything there, but fonts can be an issue