Clickteam please improve PERFORMANCE of MMF2 games ASAP

[DistantJ]

Yeah man, MMF is a software development tool, not LittleBigPlanet. There are plenty of 'make your own platform game/racing game/whatever game' programs out there, MMF is a bit more for people with a little more skill who want more control but without having to laboriously code the whole thing. Besides, if you use built in movements etc., it's very close to that anyway. If you really do want to do things that way and remain in MMF, lots of people upload pre-made engines to be used however the user wishes.

But Blue66, what people are trying to say is that MMF2 is a tool, not a miracle. It's designed to be a good all-rounder for development and that will never be possible without some shortcomings. Yes, DOOM can display thousands of enemies on screen at once but that's because DOOM has those enemies precisely programmed to properly allocate and release specific bytes of memory. When you create an 'Active Object' it could be something as big or small, complex or simple and basic or detailed as you want, and MMF2 has to allocate memory, create collision masks etc. for non-specific objects as best as it can, often during runtime instead of upfront. Coders can say 'use this free bit of memory here for this and then free it up once we don't need it anymore', and be truly precise with it; MMF2 can only guess what you are going to do with it. There are ways of helping it to understand how you want to use the memory (learn about MMF2's memory management, collision detection etc. and how to work best with it) but if you want full freedom of control and the ability to do thousands of on-screen objects etc. you need to build an engine capable of it, which will probably require for you to take the plunge into proper coding.

[Eliyahu]

If you give beginners frameworks, they're hardly examples. They don't read comments. They don't care how it was put together. I remember doing the MMF2 tutorials for MOO Chat and such, and I ended up blindly copying the code from the tutorial, but at least I was doing work in MMF2.
There's a fine line between examples and this framework idea for games, and the lack of such templates is better, in my opinion.
By trial and error I don't mean throwing a new user into MMF2 so they can get eaten alive. They should be trying new things and when they don't know how to do something, they should do a search through the forums or ask. When you ask how to do something, you never ask again, because you learned. When you supply a user with a template for a game, they don't know why it works, and they don't need to care, because it does work, and that way of thinking doesn't help users improve.

There are enough game creation tools that let users make drab games quickly from premade engines.

Also, because analogies are fun, I think a framework/template would be like giving a person a cake with some icing and stuff to decorate, and the recipe for the cake. The cake is already baked, so hell, I don't care how it was made. I just spread icing over it. If everyone does this, you end up having the same crap with different variations of icing.

Let's make our own cakes.

EDIT: Sorry if my posts seem accusational. Must be the negative vibe of this thread. I see what you mean, I just think making examples is a better way to go. A lot of it is in how you display it, anyway. If you tell people "Make a game from this template!" they will. If you upload an example, people may "steal" events from it, but overall I don't think that would be the reaction.

[Outcast]

I think any example, frameworks or tutorials is a good thing. I don't think it will ever be a bad thing to have a big library to learn from. I really want to see an optimizing guide. Maybe it could even be for different game types. Overall it would be really nice with a more structured place for all these examples, frameworks, tutorials and optimizing guides.

[Nifflas]

It's a given that examples, frameworks and tutorials are always, always a great thing. They makes the learning curve better and lets people learn advanced things when they are ready for it. They are also crucial for a lot of people who are just getting started to feel that they can actually make games, which means they're much less likely to give up early. I can definitely see why it's ideal for a kid who only wants to create a simple 2D game to use a template, even though it'll result in a game with similar mechanics to all the others that uses the same template. Come on, it's not like a beginner is going to create a masterpiece just because you force the person to overcome the threshold of figuring out events right from the start. Sooner or later every person is going to want to learn more, so value the learning curve and and let each person take the time they need to get into programming. Using a template is going to do as little damage as using a level editor for any existing game. Plenty of game developers started out with creating levels for other games, then went to modding, then proper programming. With good templates, MMF can contain all these steps. I've held three courses where I teach MMF2, I know how people and learning curves work.

I know I just repeatedly get back to this and you're probably tired of hearing about it now, but the answer in MMF3 is hierarchies (so we can build complex objects that can be treated as a single entity out of several smaller ones), and advanced behaviors for those with custom actions, conditions, and expressions (ACEs). That way, we advanced users can make all kinds of evented pre-made movements, inventory systems, text drawers, AI's, dialog systems, and distribute it as easy to use objects. Advanced users can modify how these objects work internally by editing their events while beginners can just use the supplied ACEs to interface with them, and in addition it brings MMF3 a bit closer to proper object oriented programming which is a more innovative way to work for the advanced user. Everybody wins.

[Konidias]

Back to optimization... I just wanted to point out that Construct has a page for performance tips and a lot of them easily apply to MMF as well:

http://www.scirra.com/manual/134/performance-tips

Also it's funny to note that they have this:

"Creating too many objects
While modern computers are very fast, they still have a limited processing capacity. Creating over 1000 objects will probably cause your game to slow down. Try to design your game to use fewer objects. The system expression objectcount can tell you how many objects you are using.

Checking for too many collisions
Testing for collisions or overlaps between two object types, each with 100 instances, will require 10,000 collision checks. If this is done every tick at 60 frames per second it will be processing 600,000 collision checks per second, which is very demanding on the processor. Try to only check for collisions when absolutely necessary, or on a timer (e.g. once a second), or just use fewer objects."

Sounds a bit familiar to me.

[James]

To the OP -- we (Clickteam developers) would be interested in profiling your game to see if there's an obvious bottleneck. Would you be able to share the MFA?

If so, please drop me an email.

[loglady]

There is some bit f info I would like to share, if possible...
Some time ago I was programming a short game (for Ludum Dare) and had a lot of trouble with performance.
Well, everythng was solved after I changed the Display Mode to Direct3D 8 (was in Standard). Suddently the FPS in my game jumped
from 12 to 60! Just a simple setting. Maybe, just maybe, this is happening to others.

Oh, before I forget, if you choose Direct3D 9, the screen will get blank randomly on some videoboards. Direct3D 8 gave in my tests
the same results as Direct3D 9 but withou this bug.

I hope this info help others having problems with performance!

[Dines]

With optimising things, I just tend to switch things off as I go. It's about being neat and tidy, so I try and make sure all my objects go to sleep when they're not needed. Use the Object is Getting Close to Window Edge condition to created a scaled sleep routine. That means the farther away the object is, the sleepier it gets. So in my case, once an object is 100px from the screen, he'll stop using line of sight (LOS) tests, or his LOS tests will use a bigger step. After 200px, he'll stop moving or detecting collisions. At that same distance, stray bullets will be destroyed.

Obviously use For Each and Action Loops where possible instead of Fast Loops.

Try and control multiple objects using the same code (Object Selection). Using groups you can organise objects by common properties and make those common properties... well... common to all of them.

Organise code into groups and switch them off when not needed.

Learn a little C++ so if you run into problems, you can just code your own plugin to fix them. This can be a handy way of getting more bang for your buck with MMF, and still works out faster than trying to make a whole application in code. So if you're making a game which relies on working out the relative positions of multiple objects, then rather than struggling to do it in MMF's event editor, you could just make an action which reads the current selected object list and applies your logic from C++ directly into the objects instead. With new SDKs like EDIF, this is a much easier option than it used to be.

[Outcast]

To the optimizers. A challange : http://community.clickteam.com/showthread.php?t=72792&page=2
Can you make it run better?

[Outcast]

With optimising things, I just tend to switch things off as I go. It's about being neat and tidy, so I try and make sure all my objects go to sleep when they're not needed. Use the Object is Getting Close to Window Edge condition to created a scaled sleep routine. That means the farther away the object is, the sleepier it gets. So in my case, once an object is 100px from the screen, he'll stop using line of sight (LOS) tests, or his LOS tests will use a bigger step. After 200px, he'll stop moving or detecting collisions. At that same distance, stray bullets will be destroyed.

Do you also use mmfs inbuilt activation (inactive if far from frame) in the properties a long with this? or do you turn it off and just do everything manually like this for better control?