Game Types and How to do Them

Some of you may be familiar with Popcap games. They have quite the stable. There games fall into specific categories and many of them are just variations on a game type. For instance, Zuma is similar to Tumble Bugs with graphic variations and a new theme.

I am wondering if we and Clickteam, can do more in the future to make certain games easier to create. Very advanced users could pull some of these game types off, but it does take a lot of figuring out and various methods.

So, I thought I would throw this out as a topic. How would you create the following games? Is there a way to help that along with extensions, movements, or new MMF features? I mean, a way to make it rather easy to create a game type, and there many types.

Some game types that are interesting, (add your own):

Chuzzle. A puzzle game where you simply slide groups of fuzzy ball creatures horizontally and vertically to match colors of three or more.

Zuma and Tumble Bugs: You have a character that shoots colored balls from the center of a spiral. Around that spiral balls roll in and along the track. You keep them from getting to the end by shooting a color that matches two or more. There are plenty of power-ups that change shots and the way the balls act.

I may list some more later.

Quote:

---

Chuzzle. A puzzle game where you simply slide groups of fuzzy ball creatures horizontally and vertically to match colors of three or more.

---

Sounds to me that AGBO can do this kind of game easily :)

Having used the PopCap framework for a long time, I feel that I can shed some light on this subject :).

The very first thing that MMF 2 needs is HW acceleration and smooth rotations.

I think we need some improvements to allow better control over object selection.

So besides being fast enough and a lack of control over objects, MMF 2 can already create these types of games. Personally I prefer programming over events though.

Over the years I have used C++, C#, Flash, VB, Torque, ect. MMF 2 is still my favorite choice for rapid prototype development, but sadly I can't use it for any of my main stream work because it is simply too slow and I don't have enough control over things :(. I worry that if I run into a bug then I might not be able to fix it, and it might take CT months to get a patch out.

I know it is easy to say "If such bugs were found, a patch will be released as soon as possible" but that isn't good enough for a lot of clients who expect hard deadlines.

I know I am a bit off topic but I felt that it was relevant to share the reasons why I can't use MMF 2 in contract games.

In terms of the games you mentioned I know for a solid fact that Zuma uses a form of spline interpolation. I would imagine that Chuzzle uses an array.

I find that not being able to create custom data structures easily in MMF 2 is a huge limitation :( .

Quote:

---

The very first thing that MMF 2 needs is HW acceleration and smooth rotations.

---

You have been out of touch while on vacation, haven't you :D

Quote:

---

Over the years I have used C++, C#, Flash, VB, Torque, ect. MMF 2 is still my favorite choice for rapid prototype development, but sadly I can't use it for any of my main stream work because it is simply too slow and I don't have enough control over things :(. I worry that if I run into a bug then I might not be able to fix it, and it might take CT months to get a patch out.

---

I don't think MMF is intended for those who are specializing in all things computer at university and beyond. For you it was just a transition product. For others, it allows them to release the inner artist.

As someone who does use MMF to earn a living, I would point out that it is entirely expected these days to use multiple development tools. I use about a dozen - most of them for creating the necessary artwork. I've also used VB and had a project come crashing to a halt because of a VB bug that I couldn't get MS to fix. It's rare to find any tool that doesn't have a few bugs you have to work around. Lateral thinking, that's the skill you need :)

Quote:

---

You have been out of touch while on vacation, haven't you

---

Yeah, pretty much ^^.

Quote:

---

I don't think MMF is intended for those who are specializing in all things computer at university and beyond. For you it was just a transition product. For others, it allows them to release the inner artist.

---

That's great, except there a large group of people who want to use MMF 2 for casual games but move to different APIs. There was a project that I could have used MMF 2 for but it would have ran much slower then my other alternatives.. It would be one thing if MMF 2 had a defined audience... What exactly is the target userbase?

To finish this point I will direct you to a quote from the MMF 2 sale page:

Quote:

---

Discover the secret tool used by so many multimedia pros, game creators, and people from all walks of life.

---

;) .

Quote:

---

As someone who does use MMF to earn a living, I would point out that it is entirely expected these days to use multiple development tools. I use about a dozen - most of them for creating the necessary artwork. I've also used VB and had a project come crashing to a halt because of a VB bug that I couldn't get MS to fix. It's rare to find any tool that doesn't have a few bugs you have to work around. Lateral thinking, that's the skill you need

---

That's very true. Personally I don't really care for VB.NET but that is another story :P . My main problem is that almost every other tool allows for the creation of various data structures to store large amounts of information effectively. In MMF 2 dealing with a large volume of data is a real pain as there is no way to say create a structure. We have arrays and dequees but they are limited to strings and integers. It is hard to group related data together... This leads to massive work arounds for a relatively common and simple task.

Then there is the whole deal with floats and integers and just creating some complex logic (where you would normally use nested if else statements and such) is very convoluted because of the lack of nested events (Unless I missed something while on vacation :) ).

So it is when this lateral thinking would take more time then required to develope in another language that we come to the main bulk of the problems :) .

This thread is obviously not going the way Nova intended it to, but I have to agree with vortex2. MMF's side-effectish behaviour requires years of experience with it, to get only the simplest of things done.
When I started (with KNP that was), random things just happened and you got used to never getting what you expected, but then taking the closest result to what you wanted instead, just to watch it turn to something completely else when you later changed something that didn't have any obvious relation to it.
So much about user friendly :/

Rant aside, what I think MMF needs are better level editing capabilities. I talked with our CT guys about this subject once at a convention but obviously my idea was too big of a change or they did not get my point. I proposed total separation of events and objects and frames.
E.g. you have a list of event-object-sets, let's say "menu", "help" and "game". An event-object-set would consist of the events we know from the event editor and a set of objects that are used in the events (like in the sidebar of the current frame editor.
Now every new frame that you create, you select the event-object-set that you want for it, and you get the list of objects so you can place them on the frame.
The point behind this idea is that you can have lets say 100 levels, that share the same event-object-set. So if you change the animations of an object, you do it ONLY ONCE and not 100 times. If you change the events for an object, you do it ONCE and ONLY ONCE.

In current MMF(2), if you have three levels, and change how something works, you have to copy stuff around or do the changes three times. Ouch.

Another thing. MMF2 needs to be able to set up the alterable values and string of an object IN THE LEVEL EDITOR AT DESIGN TIME and PER INSTANCE. So let's say you place three enemy objects on the frame, you can click on each of them, set up a different string (e.g. a name), change alterable values (e.g. hitpoints, difficulty level or what ever).
This stuff is important! Having to write a custom level editor everytime you want a game with more than one level is NOT fun!
The only workaround is to put all levels in one frame, at the expense of performance (which already isn't very fast, especially if you consider using more than one layer or any graphical effects).

To allow people to make more professional games with MMF2, certain things have to become easier. Beyond the point of a "space invader extension" or "pacman extension". Where is the creativity in that?

While I'm at it, MMF2 needs a scripting interface. I've seen a nice attempt in another thread here, but in my opinion this should be facilitated from Clickteam! Take a look at shockwave (adobe director). Guess why they make all the cool games? Because you can script a 3d racing game within a day! I've been clicking since 94/95 (12 years!) and scripting since 2005. What a surprise, but scripting comes so much easier despite all lack of experience in it. No workarounds, straight forward logical implementation. No side effects, pure functionality. From my point of view MMF is so trapped in it's own shell of "keep things easy and drag&droppish" that it is blind for the opportunity of scripts (which in many cases actually makes things easier! Believe it or not).

Did I mention that MMF should obey to the priciples of object orientation? Ah well, maybe another day.

Random really has a point.

There is a huge difference between making a "easy pacman extension" and expanding the core functionalities that in the end also makes it easier to make a pacman game.

As I see it, MMF2 events are already very similar to a linear script like this:

Code:

---

while (true) do
//events here
end

---

But it is limited to that and only that.

I see it as a programming language but it doesn't have theese features:
You cannot declare functions.
You cannot do recursion
You cannot return data to an expression by running events (coupled with #1)
You cannot reuse code (includes), you can only copy/paste
You cannot expand on existing objects (like eventing extra actions/conditions/expressions for given active objects)
You cannot nest code for better code structure and program flow (I've suggested sub-events for so long I can't even remember now)

How powerful would MMF2 not be if you could do all this?

Imagine making custom actions for your "enemy" object like "Attack", "Flee", "AlertOtherEnemies" and so on.

You cannot declare functions.

> But you can use fastloops (with one loop)

Imagine making custom actions for your "enemy" object like "Attack", "Flee", "AlertOtherEnemies" and so on.

> This could be pretty nice :)

Quote:

---

Originally Posted by Sphax

> But you can use fastloops (with one loop)

---

But you can't return a value or string back to the callee without storing it in some counter or global value which isn't very practical.
Fastloops with 1 loop isn't very practical either. Also having the stuff string identified doesn't allow MMF2's IDE to become very smart for example the ability to show you your different functions in a list or in some sort of autocomplete/intellisense when using it.

Yes, this thread is going is straying off in a different direction than I intended, but I find it very interesting.

I hope we can cover all the ground here and keep this discussion going.

As far as the suggestion of more advanced capabilities and scripting goes, it sounds more practical the way it is being related.

However, those ideas relate to the quesiton of how many of the bulk of users would be able to incorporate them in their game creation? At what point might the sound of these advanced features scare people who want easy and simple game creation?

I totally agree with all the above, and I think that if there are going to be an MMF3, that all of this should be taken into account. Is it bad for MMF to go from an easy and simple game creation system to be an extremely powerful and (almost as easy to use) game creation system? :D

Nova, you are afraid that such implementations will scare away users that all they want is to make a game i no time, but now MMF scares away advanced users that want to get the most out of MMF but simply cannot because of its clumsyness.

Besides, there will always be a tool these people can use : MMF2 :D

Quote:

---

To finish this point I will direct you to a quote from the MMF 2 sale page:


Quote:
Discover the secret tool used by so many multimedia pros, game creators, and people from all walks of life.

---

With respect, Vortex, you are not in possession of all the facts :) Adult multimedia types don't hang out on the forums - they nip in, ask a quick question and then vanish again for six months.

For example, an advertising agency approached me directly from the forums here to commission a screensaver project. :cool: They'd only ever made a couple of posts on the forum prior to that.

Game creators - no question about that - the galleries speak for themselves.

People from all walks of life - again, equally true - come to a convention and you'll see for yourself.

Sarah, my point was that they do ;) .

Quote:

---

Originally Posted by Sarah

I don't think MMF is intended for those who are specializing in all things computer at university and beyond

---

I was stating that MMF2's own sales page disputes your claim that MMF 2 is not intended for such audiences :) . Unless of course people specializing in all things computer at university is NOT a walk of life (I do admit that some of us don't have much of a life outside school, but still) ? :) .

I agree with people here about having functions and OOP. Those would be very nice to have.

Oh and Novabrain, I think we would be supprised by how much power the users can handle! While it is true that some of the userbase is rather new to game development, some have used MMF (and perhaps other programs) for quite a while. I am sure given the proper documentation new users will be able to take full advantage of additional power and control. I know this because some of the kids at the camp where I do tech support ask some amazingly complex questions while using MMF 2. One camper wanted to make a line rider game and actually got quite far with it! Another wanted to make Chess, but such a game is very hard to create in MMF 2.

I didn't mean to steer this thread so far off course but I wanted to share my views :) . MMF 2 is a great program, so great that I want to use it in more of my work! No other tool that I own allows me to create things so rapidly. However the lack of power and control is a real killer sometimes :\.

Vortex, you either have a product that has general appeal or one that has specialist appeal. You're looking for a specialist's tool, and MMF is never going to be that. Make things just that little bit more complex and you lose everybody except your most experienced users.

I use TrueSpace for some of my artwork. With each new version they make sweeping changes to the interface. At the last version, I baulked. Enough is enough. I'm not prepared to wade through 100 hours of technical videos to be able to use a tool I only need for a few weeks a year. Judging by the number of special offers Caligari keep sending me - I am not alone :crazy:

Quote:

---

Vortex, you either have a product that has general appeal or one that has specialist appeal. You're looking for a specialist's tool, and MMF is never going to be that.

---

With all respect I am looking for a tool that can make games. I am not looking for some special tool, I am looking for some added functionality so that I can use the tool more effectively. This isn't even functionality that would really get in users way if they did things the current way...

Quote:

---

I use TrueSpace for some of my artwork. With each new version they make sweeping changes to the interface. At the last version, I baulked. Enough is enough. I'm not prepared to wade through 100 hours of technical videos to be able to use a tool I only need for a few weeks a year. Judging by the number of special offers Caligari keep sending me - I am not alone

---

Yes but the majority of people will still use TrueSpace. Such changes have to be made sometimes because usually software programs try to stay ahead or at the same level of the competition... If TrueSpace never changed then it would grow stale and old and then no one would use it because there would be much better options.

You have to balance the rate of change with what the userbase can stand. It's different if you're bringing out a brand new, never seen before application - in this case, all your users will either be young or born risk takers.

With a mature tool, you already have a substantial base of users that you want to take with you. Many people are pretty reluctant to have their cosy work space messed around with. They've invested thousands of hours into getting things just so, and resent a long period of relearning.

So it's a tricky balance. People in this particular forum don't represent the majority of users - it's only the select few that are able and willing to make extensions, after all :)

Good back and forth discussion there on user types and such ;)

After giving it some thought, I think both cases are presented well. We have the idea of simple/easy and non-threatening. Then, we have the rather advanced improvements and capabilities mentioned here.

I don't think they are actually mutually exclusive. In other words, would it not be possible to have these features and promote them under the heading of advanced?

I guess my question would be, are those who are suggesting the improvements thinking of an addition or a replacement for current ones or can they technically co-exist?

From there I would go on to ask the details concerning the above. Just how much would MMF change, (superficially) in a way that might make it harder to use?

Thanks.

The good thing about extensions is .... that they're optional. If you don't want to worry your head about MOO or ODBC, they might as well not exist.

So the LUA extensions are great - they parcel off scripting for those who want it, and don't strain the brain of those who don't.

The more CT can follow a similar philosophy for other major changes, the easier it will be for both the new users and the golden oldies who are quite happy with things as they are :)

They are not exclusive at all, if done correctly. Many programs hide more "advanced" features and allow the program to basically grow with the user. As the user becomes more advanced the program can become more advanced to meet their demands and needs.

We don't want or need these additions to get in the way of the current way people use MMF 2, but we want them to be a compliment to and an addition for those who want or need more power.

It should be possible to "dabble" in some of the advanced features to make projects easier to create. The thing about these mentioned additions is that they will make the tool EASIER to use as there will be less workarounds!

Of course with good documentation and tutorials the users will be able to adopt the new concepts easily anyway ;) . I have some video tutorials for Flash CS3 Professional (Work bought it for me) that I have worked through, and they have greatly increased my understanding of the program.

Quote:

---

Originally Posted by vortex2

It should be possible to "dabble" in some of the advanced features to make projects easier to create. The thing about these mentioned additions is that they will make the tool EASIER to use as there will be less workarounds!

---

This is exactly my point. Why should any of the features make MMF2 harder to use?
Currently achieving some simple things requires insanely complex thinking and difficult solutions. Why? Usually lack of transparency over what MMF actually does, lack of control over how MMF does it. Just because it requires an advanced user to come up with what could be improved it doesn't mean that beginners do not benefit from it.

Quote:

---

Originally Posted by Sarah

So the LUA extensions are great - they parcel off scripting for those who want it, and don't strain the brain of those who don't.

---

I don't agree. Integrating LUA in MMF2 is quite a clumsy experience. If you have ever used LUA for .NET you know what I'm talking about (there LUA can access each and every function, method, object, etc. of the entire framework, without any extra code required).

Quote:

---

Originally Posted by Sarah

I don't think MMF is intended for those who are specializing in all things computer at university and beyond.

---

MMF2 claims and tries to be a professional tool. But to be taken serious, it has to be reliable! You cannot plan or schedule work with a tool that will randomly throw rocks / bugs in your path that can take you half a year (or eternity) to fix.

Functions or OOP may sound complicated, but if you have tried to achieve their effects with MMF's current options, then you know what is complicated. We need it easier. Not harder.

MMF2 also requires a lot of work on parts of the debugger. While the debugger is kinda "cute" to see how some values are between frames, it is far from useable. Most extensions (all?) do not support it, it is really difficult to keep an overview (it shows all kind of stuff that clutters up the screen but is not nescessary, e.g. unused alterable values).
I'm afraid we will never get a step through editor that can display what objects are selected by conditions, and display their values between actions - but without it, it won't be possible to efficiently debug applications or games.

Quote:

---

They've invested thousands of hours into getting things just so, and resent a long period of relearning.

---

How about improvements that would allow the same things to be done within a couple of hours, instead of thousands?

I like extensions, don't get me wrong. But some things have to be changed fundamentally to allow MMF to become more professional.

I agree. The reason that my Lua extension is not fully integrated into MMF 2 is two fold. A) It was designed for MMF 1.5 and there was no point integrating something only to have to redo it later, and B) I wanted the extension to be lightweight and only have functions that the user wanted as it was designed to be used for game scripting.

You do raise some great points and I really hope that CT can implement some of these ideas in the near future.

On the topic of improvements, there are also many little places where conditions, actions, and expressions could be streamlined in the sense that they are faster, easier, and produce more readable code.

I have been looking for those places and have some solid ideas that I feel should be implemented. I am wondering what other's think about my proposed solutions, (that are just brainstorming for now):

Because MMF2 is still working with many older concepts from the early days, we see some of the results in rather complex methods required to do simple things.

I know there are tons of ideas and suggestions just begging to be implemented. It think these ideas are workable, should not be too hard to implement, and would have a major impact on ease-of-use and the amount of time spent creating.

I am including a file that illustrates the problems I see and comments on the solutions, (you must have the VectorLine Beta to run it).

Keep in mind that whatever names I am using for the new items are merely prototypical for now.

Here is what we need to make it simple and easy to connect, pick, and manipulate created objects:

Conditions:
On mouse over-click, (or whatever name)

Repeat while mouse over-clicks

Pick Connection "MyCreatedObjects"

Actions:
Add Object to Connection "MyConnectionName"

Remove Object from Connection "MyconnectionName"

Attach object(s) - Uses BOTH x and y to attach one or more objects coordinates like an object to the mouse or objects to objects). Can also pick a Connection. Perhaps this could be expanded upon later?

Sorry, but you have the VectorLine Beta to run the file. I can post the comments I made in the file, here, if needs be.

Back on the concept of game types, I guess we need to have some really simple, easy to follow, well-commented template examples created for each one that can be done with the current tools.

Making a "simple" version of Chuzzle or Zuma is much easier said then done... It is possible to create such games but they are by no means simple to make..

While many new ideas to make stuff simpler to use through extensions is great, I still feel you should expand on the core.

Instead of making it simple to make one thing by creating an extension, why not make everything easier to make by making the core more flexible?
Many new ideas for MMF2 suffers greatly from not being useful in other than maybe just a few games.

Also some new ideas to the core functionality seems to go against the ideology of Object Oriented Programming and well known design patterns.

My advice: Expand the eventing system to allow people to make events like they would program them in another programming language but still keep it close coupled with the object orientation MMF2 already has.

Stuff I see as important (don't necessarily mean that you may feel it is important):

• Nesting events into each other
• Eventing new actions/conditions/expressions for existing objects (like active objects) - (kinda like inheritance)
• For-each loops (Like discussed earlier)

Also CT should really change the order of execution when it comes to actions that affects more than one duplicate of an object.
- It fixes the (IMHO) bug that happens when you spread a value and start a fastloop in the same event. Also fixes MoveIt object, SaveGame object and others.
- Doesn't break any existing games.
- Much less confusing

I agree with Andos. Though I am a great believer in extensions for doing particular jobs, it is better if the core program can achieve certain results quickly and easier. The event editor being the one place where features would make this come true. I certainly think the last 12 months have seen TGF2 and MMF2 getting more powerful growing in leeps and bounds (as will be shown at the convention ;)

I am sure Y&F have those items in their list, if not i am sure they will look at it and see if it will fit into the program :D I am sure in the future some major changes will be made to make everything easier and more powerful.

Even though one or two users didnt think that version 2 was a step forward...Getting to version 2 was actually a massive step IMHO, removing assembly code/corel filters etc. It was a massive job, but had to be done to ensure easier updating of code in the future. And allow for some future nice features ;)

Now version 2 is here, as far as i know it does make things easier to implement than if those items were still in place. So going forward i suspect there is more scope to make these big code changes....

So the more ideas and comments about what features people want are very much appreciated/wanted.

Jason

I agree with what Andos proposed.

Together with nesting a super simple "else" condition would be great that just is true if the previous event was not. I believe Francois once pointed out that's tricky because the events kinda don't know each other - but hey, if I can do it with variables/counter whatever, why shouldn't MMF?

To make selections more controllable, maybe the Select Object Extension should be expanded (a lot). It'd be good to be able to store selections to retrieve them again later (maybe by string).

Well I'm looking forward to the Hardware Acceleration first, as this will allow the user to put more of the power of MMF version 2 (layers, rotation, scaling, large graphics, anti-aliasing, ink effects) on to the 3D card and leave the processor to do the important eventing. From what I've read to date this work is looking promising :)

The core features of MMF are surely important, I'm for anything that makes the difficult things easier. The for each loop would save time and provide a tool that does a common job in an easier way.

I'm really looking forward to Vortex's physics extension, and who knows maybe this can be absorbed into the core program in time.

I'd still like to see some way of making re-using the things you build in the frame editor and the event editor. As it is designed now everything is ring fenced into a frame and you have to duplicate everything if you want the same in another frame.

I'm sure there is a backward compatible approach that can be implemented, my last ideas were around using principles similar to Director with casts and libraries, but I've since been thinking about something that might fit how MMF is designed better...

[font:Microsoft Sans Serif][color:#000099]
Keep the Global events. They are tagged on to the frame events as they are now.

Keep the behaviour events too.

Keep the frame events also, but rename them to be local events.

Keep the frame object shelf, but again rename this to be the local object shelf.

The local frame events and object shelf would be how existing applications are loaded in.

Add a new property to a frame that allows you to allocate what type of frame it is. I think you could re-use the "Screen Saver Setup frame" tick box under the runtime options for a frame. Change this to be a drop down box instead with the following:

• Normal frame
• Template frame
• Screensaver setup frame

The Template frame flags this frame to be a re-usable frame. It can not be run directly itself, so you could not go to it in your game (the storyboard actions, conditions, and editor would need to reflect that). You would add in your objects to the object shelf in the frame editor and you could add events to the event editor. The frame editor is really just a sandbox - so you would be allowed to put your graphics on there as normal but only to test what you build in this template frame.

Then in any Normal frame you create you could attach Template frames to them. I imagine a property category like the alterable values or event behaviours where you could add as many template frames as you want (and remove them).

The frame editor would show it's local object shelf as normal, but this would be divided up to also show the objects from each of the frame templates object shelf's under their own headings.

The user could drag and drop these items on to their normal frame -note that whatever was on the frame editor of the template frame is ignored in the normal frame it is attached to, so you only see the objects on the object shelf from the template frame and nothing else. Should the template frame be removed from the normal frame (a user confirmation required) the objects added to the normal frame would be removed.

In the event editor, the object columns for only the objects that have been added to the normal frame (by dragging them from the object shelf on to the frame in the frame editor) would be shown, and they could be kept separated from the normal object columns.

The user could add additional events that use the template objects in the local event editor. Some concept of scope would be required to keep object names unique for example combining the frame template name with the object name. If you had an object called "Lift" in the local normal frame, and an object also called "Lift" in the template frames "Player" and "Baddies" then the objects would be called as follows:

• Lift - the local version
• Player.Lift - the version in the Player template frame
• Baddies.Lift - the version in the Baddies template frame

Finally, when the frame is run we'd have the global events, the behaviour events, the local events and the (new) template frame events all combined together. The template frame events are therefore similar to global events but do not suffer from the object reference issues.

As a user, I could write game engines or re-usable frame object/event content in my template frames and use them on any normal frame. If I need to make a change to one of my template frames, I'd only need to make the change in one place and all normal frames that had the template frames attached would be updated (objects from the object shelf and events).

As usual, I've rambled on but I think the above fits into the current way that MMF works yet solves the limitation MMF has when you are making a single game that has many frames (and many objects+events duplicated in each frame).
[/color][/font]

Kinda got lost reading all that goodness.......

But I wanted to throw in my two cents....

MMF is a tool like any other programming language, and it is up to the user to see what they can achieve with the tool, in the end a Hammer is a Hammer, and though some Hammers might be better then others it is still up to the User what to build...

The Value proposition of Multimedia Fusion is and has to remain it's ease to use while maintaining and expanding it's versatility to do all sorts of app types...

So would I create "Clone Game Template" files?, no probably not because will our users really learn anything in that transaction. We need to balance their initial introduction with MMF one that demos the ease of use but reinforces the fact that they Created the Game a didn't just drag and drop and poof game appeared. Especially if you are trying to attract more professional type developers.

I Do think we can do a better job with certain simplifications, a strong area would be in the Movement Selection and the fact you can add new ones, instead of a extension or MFA that gives you a Pacman Clone how about a movement that does maze movements easily, then it can be used in pacman, boulder dash, and other mazed based games, I would say the more options we have in the Make a basic Game in five minutes demonstration (Ie instead of just Pong) be able to demo other types of games, Arcade, puzzle, etc will really demo the power of MMF...

Oh and you can do Zuma in MMF

http://gamesare.com/games/bali/bali.htm

:)

I add a very small idea which already exists through some extensions :
- functions (void, number, string) with parameters, global or not.

I know a lot of extensions with these features exists but, like fastloops, I think it's a small and important feature which must be included in MMF2 core (and optimized like MMF2 fastloops).

EDIT: Ho, and it's a nice example Novabrain ;)

Bumpfest going on here! ;)

Just getting ready to move towards a brainstorming session over the course of testing the current extensions.

We can get a specific thread going with ideas and potential directions, this Fall.

I know I'm really late here, but I would like to expand on what Random said a bit:

Quote:

---

From my point of view MMF is so trapped in it's own shell of "keep things easy and drag&droppish" that it is blind for the opportunity of scripts (which in many cases actually makes things easier! Believe it or not). "

---

That is really true. There is a secret that MMF'ers don't seem to know: It is much easier to solve problems using a programming language. Now, it is a lot easier to make a game or program in MMF, but the individual problems you have are harder to solve in MMF than they are in C++ or especially Jamagic.

The answer doesn't have to be scripting though, although I think that would be a good feature too. MMF needs to get easier and so more powerful. The thing is, extensions are not the way. An extension which does something to make things easier is usually rather clumsy, or opens its own issues, or isn't obvious to use, or whatever. Movements and things are a good solution I think to some issues (although extensions controlling movements is an awful idea I think. Keep it self contained. Make it add stuff to the menus if it needs to but not a seperate extension)

One thing I think needs to change is the expression editor. Maybe keep it there as an opition, but it isn't great. It is just text. Here is how I would have it if I were designing it: Have a mathematical formula input control (some exist for free online). When you want to refer to values, have a button which opens up a screen with all the information (no > Value Here <) which allows new screens to be open, and then represent that in the original by an icon. I'm not sure if that description makes any sense. If not, I will make a 'mock up' if anybody is interested.

Second. I was making a little level editor thing today for the INI++ object example. When I wanted to save everything, I ended up using a really silly method (of picking random objects then deleting them). What I really want to do is have something like:

When button clicked...
REPEAT
....
UNTIL something

or similar constructs like:

When something
REPEAT FOR EACH OBJECT (refered to somehow)
....

Then MMF can run these, but don't make it pause the program, make it seem like it is running it in another thread (although it doesn't actually have to do that. Just do one loop per MMF loop)

It is exactly the sort of thing that is easy to display visiaully like MMF currently does. It can all be like an expanding and collapsing tree. It is perfect.

The other thing which is hard to do in MMF is just calculating what is going to happen. Like imagine a game where there are lots of mirrors and you have to arrange them so that a laser beam hits something (I had a game like that and it was much fun for 10 mins or so). How do you find out where the beam is going to go? MMF pretty much forces you to physically (well, technically not 'physically' as such, but 'virtually physical') have an object (albeit invisible) and fire it and move it along the path and see where it turns out. Okay, so you can pass with that in that case, but what when it isn't so much of a physical problem? I can't really think of one right now, but I can't think of a solution either so not much is lost.

Well I *reallllly* think the two ideas here (expression editor re-jig and loops) should get implimented in MMF3.

EDIT: Here! Look at my picture. It is fairly awful but it should give an idea of what could be done. If I were Clickteam, the expression editor would be what I would want to improve, and I this sort of layout (With improvements or whatever) is both clear, powerful and so forth. It also would be a good thing from a using it in schools viewpoint (as it makes it look less technical and more educational, even if nothing has really changed). The idea would need changes but I really think it should be taken seriously.

I'd still like to see some ways to re-use code, something like I described above, but I've also been thinking about behaviours a lot recently. In another thread I made some behaviours give properties to an object it was dropped on to, such as a custom player and computer controlled movement. For the latter I had to use a fast loop to enumerate through the list of instances of the same object so that they could be controlled.

What I'd like behaviours to evolve into may solve some of the issues described above, without the need to go into scripting.

At the moment, a behaviour is just a list of events added on to the end of the event editor. Perhaps we need behaviour types that the user can choose to create as in the following example:

* Normal behaviour. As now, events tagged on to the end of the frames event list.

* On creation (a constructor). Events in here are run only when an instance of an object is created, and it is run for each object created individually. This may be at the start of a frame or when the Create action is used to make a new instance of an object. I can do this now with a fast loop to index each instance, but wouldn't it be great to have this done for you?

* On destroy (a destructor). As above, but run just before an object is destroyed. I can do this using a fastloop but it would be great for MMF to handle this for me, and run any events against each instance of an object defined in this behaviour type.

* On Loop: A special list of events that are run against each instance of the object. I can do this in MMF now with a fast loop, to go through each instance by an index number. However, once again it would be better if MMF can handle this. For starters I would not need to set up a loop and attach a fast loop condition to every single line. Instead it would be implied by the behaviour type.


This could be expanded further. I could (through event actions or during edit time set up) assign a special behaviour to run when an event happened. For example, when an instance bounces, when a collision occurs etc. The behaviour events could fire off like a fastloop but for the user it would be easy to set up.

Secondly, you could create behaviour types that could simply be called. For example, on your object you make a behaviour called "Attack" with some specific events to be run through for an instance (or instances) on demand. In the main event editor you would have a condition that resulted in a selection of one or more instances. For it's action you could execute the special behaviour called "Attack" and the events would run for each instance (in turn) that are included in the condition. Essentially a method on the object :)


What I'm describing above can be done now with fastloops, only it is something you have to learn how to do and requires lots of fat conditions which take time to create and are harder to read. If this type of functionality can be incorporated transparently into MMF so the user gets the power without the added complications, it will be very easy to learn how to use and would help encourage better structure to the solutions created, even to the point of being able to re-use your events between different projects.

This is something I hope to see MMF3 delve into.

I think one thing that has always been a problem with MMF and it's predecessors was object selection and how these are affected by actions.
It is what causes 90% of (at least my) game bugs and what takes longest to fix.
There is no way to see what objects are selected in your event so you have to do it all in your head. Basically there is no description how it exactly works, so you can only find it out by try and error or very specific tutorials (or your own experience with it). It is often counter-intuitive and even buggy, because it is not clear how it SHOULD work either (see example further down).

In my opinion MMF has to become more consistent with object selection and it somehow has to display how it makes selections.
If I was a new user of MMF this would drive me insane. The only way I figured this all out was being a kid with almost unlimited time when I first got KNP.

Example:
You have 3 object types - active objects called "A", "B" and "C", and a couple of each, all having qualifier "good".
You want to select all instances of the qualifier "good" that plays animation "Stopped". So you say "Good > Animation Stopped is playing". So far so good. Now you want to pick a random one:
"Good > Pick Group.Good at random". For this example also add "Run this event once". Now an action, let's say "Good > Destroy".
What will happen?
First it selects all instances that are playing "Stopped". Then it picks one random object in the Qualifier. Sounds good so far - BUT: What does the action do?
It destroys the object that was selected, leaves all other instances of that object type "alive", but destroys ALL other object types in the qualifier.
For some reason this is linked to the "Aniamtion stopped is playing", because when you remove that, it works correctly.

Anyhow. That was just to illustrate my point that most of the time it does not do what you would expect. Pity the beginner.

This is a fascinating discussion so far and I think it is a great way to get ideas out and in the open for consideration.

As things are being described, I can see how they might be viable, where I might not have thought so before.

Good ideas there, Jack! Maybe you can whittle that down into something that could go on the wishlist that Yves is currently sorting out with its thousands of items.

I like your behavior ideas, Andy and agree with them. Maybe MM3 can focus more on behaviors as well? I don't know if my idea makes sense, but I would like behaviors to have a little more independence. In other words, the ability to carry other objects with them without the annoying need to replace objects when you move the object with the behavior to another app. That makes it easier to construct behaviors that are like "objects". Currently behaviors are more flexible just because the object has Alterables.

The problem with the point I am making is that the behaviors have to be able to share the objects they use with the main event editor. However, I am thinking that Alterables could just as well be used as variables to control features of a behavior.

So, maybe something like this:

Behaviors:

* Can have objects that come with it when the object is moved to another app.

Problems:

If the author does not have the object in their list, then their would have to be a notification and the object cannot be added.

The objects used in the behavior would normally show-up in the main Event Editor for the frame. In the way I am thinking about it, that would be optional. You could have those objects hidden within the behavior or exposed to the main app, depending on what you are accomplishing.

Another problem, if this were possible, is what happens when you duplicate that object during runtime? It is possible to have very large sets of objects being duplicated with it. Hmmm?

That's what I have been thinking for a while. Now, I don't know if users would take advantage of that or if behaviors can be made more "independent" that way.

Good, clear points there, Random. Agreed.

I just saw your post after I submitted mine ;)

I hope Yves and Francois get a look at this thread, if and when they have time. There is some far-reaching, potential vision here and things worth exploring more and considering.

Again, hoping Yves and Francois have looked in on this thread:

Something that comes up often from users, (and I have had to chug through when figuring out why something is not going right) is picking objects. It lends itself to confusion and unexpected results.

I think that needs something. Not sure what or how yet, but it is an important function and needs some attention. Maybe we can find a way to be more precise about picking, especially in complex situations?

Also, another common complaint, (on the forums) for those doing large games is the problem with having to update each frame when you change even minor events in others. When you get to 30-40 frames, that can be rather counter-productive. I think part of the problem is related to qualifiers/behaviors/global events.

This is something to think and talk about, while we are at it. IF we could enumerate the problems, maybe the more expert developers here can propose solutions that CT can consider.

One start would be global behaviors. Let's say I have 10 unit types and a behavior "drive around" which is controlled through the alterable values.
Now if I refine this behavior in one unit, I have delete it for all the others and copy it there again.

Recently I worked on a game with such a situation and had to see it can become VERY time consuming.
Now if the behaviors were global, so changes in one reflect to all others.. so the names used for the behaviors should be unique, so if a behavior is called the same, it IS the same, no matter which frame you're on or which object you edit.

It should be possible to enter the behavior editor even faster (it already improved a lot since MMF1.5). Usually I have to zap back and forth between frame editor and some behavior.
Maybe MMF3 could memorize the last couple of windows that you've been to, and there's a "navigate back / forward" button with which you can jump back to your behavior and forward to the level editor or another behavior, etc.

Concerning object picking, it may be nice to have an action that outputs / dumps the whole selection into the debugger or some other object, maybe a text box? Or maybe even somehow highlights that selection on the screen.
This way the user could at least explore one selection at a time and see what is wrong with it. On the other hand this may prove useless, as it also depends on the action that you perform, which objects are affected. Any other ideas how to help this issue?

To be honest I am not keen on the way MMF implements global "things" at the moment. I've posted some ideas on alternative ways to handle such concepts (see part in blue) which I think could work and be crystal clear and easy to use, I'm sure there are other ways mind, but what is certain is at some point MMF needs something to help with working with re-usable events and objects rather than flagging objects in a particular frame (or frames) and same for global events.

BTW, I don't think global events should be removed - they are good for just that. What we need on the event side of things is something to fill the gap mentioned above about re-using frame level events.

I think this is all stuff for MMF 2.5 or 3 though, the Java and HWA are the current priorities ;)