Posts by Random

- What does it do:
It makes the enemy look in the direction of the player's hotspot.

- How to do it:
Add an action for Enemy called "look in direction of" or similar. There you can select the player and specify a relative offset (which you could use to make up for a bad hotspot).

- Invisible objects:
Not sure what this might be about.

- Enemy hotspot:
I dont think that has to do with the enemy being hard to shake off. You can always lower the following range (the 80s) at which the enemy "sees" the player, and you can make him give up quicker (the 30), but this only happens once the player is out of range.

There are entirely other ways to do AI, of course.. my favorite is to have your enemies shoot invisible small objects out in front of them that have their alterable value set to an "ID" of the enemy (which you'd give the enemies by spreading a number).
If those objects hit an obstacle destroy them.
If one hits the player, find the enemy with the ID, and store the position where the player was when he got hit, and the direction he was moving when it happened - make the enemy run towards that position and once reaching it, proceed in the direction that player was facing.
You might want to shoot the objects directly at the player once he was seen and in some more random angles when not.
If applied correctly, you get some nice enemies to play hide & seek with.

I agree. MMF2 projects can be finished with MMF2 - it's still a good program.
MMF3 should not be burdened by support for old projects. Maybe being able to import the graphics from objects of old projects would be nice, but that's kinda all.

I was recently been told about a new software for school kids to learn programming that works pretty much like MMF with events, conditions, actions and drag&drop etc. but writes actual script code under the hood which you can switch to at any time (back & forth) - so after starting with click-like programming kids can actually understand what the code does and continue from there. Pretty impressive. Forgot the name though But I'm sure we'll be hearing of it soon.

Well. I wouldn't mind MMF writing actual script code that you can write instead of events

Well that's kind of where MMF can get a bit nasty, but it can be done, no problem.

To have multiple instances of one object, there are different ways to handle it. For one, never make copies of the enemies. You don't want to have duplicated code.

You have to learn and understand MMF's selection system. Most conditions of an object make a selection.
E.g.: + Alterable variable "HP" of "enemy" < 0

MMF runs through every "enemy" object and checks for that condition. It then removes all objects from the selection that do not meet that criteria and goes to the next condition,
e.g.: + Animation "exploding" of "enemy" is not playing

Now it picks, from the objects with HP < 0 those that dont play animation "exploding". And then you add an action:
> "enemy" > play animation "explode"

This action will be executed for all "enemy" objects in the selection.

As you can see, having multiple instances is no problem here.
Speaking of your timer - just use an alterable value for that, that you increase for all "enemy". E.g.:

+ every 0.1 seconds
> "enemy" > add 1 to alterable value "shoot timer"

+ shoot timer > 2
> "enemy" > subtract 2 from "shoot timer"
> "enemy" > shoot at player

Now there are certain circumstances, where this system won't cut it. Especially if you need to associate the object with other objects (e.g. collision sensors, attached objects, etc.).
That's where you use the "spread value" function with 0.

+ Always
> Spread value 0 in alterable value "index" of "enemy"

Now you can run a loop over all enemy objects, using that value:

+ Always
> Start loop "enemyLoop" for Count("enemy") times

+ On loop "enemyLoop"
+ alterable value "index" of "enemy" == LoopIndex("enemyLoop")
+ "enemy" is facing left
> "enemy" > set position X = X("enemy") - 1

+ On loop "enemyLoop"
+ alterable value "index" of "enemy" == LoopIndex("enemyLoop")
+ "enemy" is facing right
> "enemy" > set position X = X("enemy") + 1

I hope that clarifies things a bit.

I think that's a very interesting point, but really only applies in some situations. In many games you, as a player, would expect units to see the world as you do - top down, or whatever it is.
Especially if they're YOUR units in an RTS, or YOUR character in any point & click game.

So often enough, this level of realism is bothersome for the player, or he doesn't really care anyways. It is a thought that becomes very apparent to you as a designer, but most players wouldn't notice the extra mile you went for more realism.
The same is often the case when you make some elaborate choice system vs. random choices.
For most players the random choice will just do fine.

Quote from Dynasoft

There's entity AI and "enemy player" AI.

You just made that up to sound smart, right? Sneaky.

Nice breakdown, Dines.
If you want to have your NPC make "intelligent" decisions, you have to provide as much information as possible - within the limits that the NPC can perceive. Having your NPC not know where the player is until he actually sees the player is pretty nice in most games (and can make some tasks easier - e.g. you can get away with less navigation / pathfinding if the enemy does not approach the player if he can't see him).
On the other hand, if you can make good use of a pathfinding extension, you have one of the trickiest parts of AI already nailed. E.g. for strategy games Greyhill's Advanced Pathfinding Extension can handle A LOT of AI issues.

And what would you consider AI? In game terms it's already considered AI when the enemy can shoot at the player on sight.

What works pretty well for me is to create a graphical mockup of how the game will look like when it's done, possibly including all planned gameplay elements.
From this I can then also take dummy graphics for all objects.

But yeah, nailing the core gameplay first is the most important thing. If that doesn't turn out right, every other effort is wasted anyway

Quote from Konidias

is there any tutorials or instructions on how to do that?

yes. Should be included with the extension.

Nothing keeps you from naming multiple keys similarly. Not sure about the assArray, but that's how I'd do it with the Named Variable Object.
E.g.:

NVO("Sword") = "Huge sword of bashing"
NVO("SwordDamage") = 30
NVO("SwordSpeed") = "very fast"

Or if you want a list of items:

NVO("Inventory01") = "Sword"
NVO("Inventory02") = "Potion of drunkenness"
NVO("Inventory03") = "Single sock"
NVO("Inventory04") = "Fancy hat of wizardry"

Then you can go and retrieve a random item like so:
GetString("NVO", "Inventory0"+Str$(Random(4)))

That's of course a bit simplified, but I'm sure you get the idea.

MMF is not exactly a programming tool. So you can't expect everything built in that you'd find in your average programming solution.
If you have a motorbike you don't expect three backseats either

Oh, by the way - have you tried the.. uh.. Array Object yet?
You can do faaaancy things like:

> Array: Write String "Sword" to (0)
> Array: Write String "Axe" to (1)
> Array: Write String "Banana" to (2)

mystring = StringAtX( "Array", Random(3))

Now rename Array to "ItemList" and guess what it resembles..

Quote from Eliyahu

Random, what I am saying is that if you don't know your way around MMF2's basic 2D game making features, there's no way you'll be able to use an extension like OpenGL successfully.

I know that you're saying that But I'm saying that if you intend to make 3d games, you shouldn't bother starting off with 2d (in this case MMF). Don't use OpenGL as an extension. Use a 3d engine that is based on OpenGL. And if that can be misunderstood, I do -not- mean an engine made with MMF. Going down the path of 2d is not one that will lead you to 3d games. That's not how it works.

And fano, with all respect, no 3d artist ever said that to me, and I've worked with quite a few and have modelled myself for some time, besides having studied this stuff at university :eek:. The key to programming in 3d is to get your math straight and the key to model in 3d is to be able to visualize in three dimensions (the skulptor's skill). And beyond that it's all about practise and experience. In 3d. So 2d just won't help.

If you had said that for making 2d graphics (e.g. paintings) thinking in 3d is the most important thing, I would actually agree with you.

What I said about OpenGL applies to Irrlicht as well, no matter how good the example looks like.

Quote

You must prepare yourself for the journey by mastering 2D and learning about all of MMF2's functions.

I have to disagree here. If you want to make 3d games, even 10 years of 2d games won't help you. It's going down the wrong path. And while I would really like to promote MMF, it is bad advice here. Your time is better spent learning to handle a proper 3d engine like Torque, Ogre, XNA, Unity, you name it. These are MADE for making 3d games. They already come with 3d examples, etc. etc.
And don't think you'll get around programming. Even if you use MMF to do 3d with OpenGL, you'll have to use and interface it LIKE you are programming, which in my opinion and experience is more difficult than programming in the first place.

So you have two (reasonable options).

a) Stick with MMF and make awesome 2d games.
b) Get the right tool for the job - pick a 3d engine and program 3d games. But bear in mind, it'll be around 5 to 10 times as much work as you think. Maybe more, you'll be surprised.

Quote from castana2009

Unfortunately, I would need to make a 3D game and that it only was Java compatible.

Correct me if I'm wrong, but OpenGL -and- Java won't work together through MMF.
But even if they would, it'd run horribly slow.

Not sure if you can get MMF's OpenGL implementation into a browser (which is why it has to use Java, right?). "Unity" can do that though (but not with java, but activeX).

If he hasn't ever made a game in MMF, I don't think an example will be enough here. More likely you'll have to code the game for him.

It is possible to do 3d with MMF (apparently), but the question is if MMF is the right tool for the job, especially if you have no experience with it.

The "Awesome Games Creation" book is definitely a good book to get started with MMF, but not for making a 3d game. You can better just buy a book about 3d game creation with XNA or OpenGL and start coding. I think it'll be an equal amount of work to get done what you want, just that in the end you can program and you have less of a performance bottleneck.

I don't what kind of game you have in mind, but you will also have to realize how much work is involved in making a 3d game. You have to program not only the game, but also the 3d engine (unless you use an existing one, then you only have to understand the whole thing!), then you have to create all the 3d assets (models, textures, animations) which is, in most cases, much more work than 2d.

So here's how you can get started:
- make a list of every object that will be in your game and the animations they will have
- make a list of all features your game will have

Then go to a 3d modelling community with the first list and ask around what experienced people think how long it would take (them) to create all that.
Then go to a 3d game development community with the second list and ask some experienced programmers how long they think it will take them to program all the features.
Now consider that you don't have any experience yet at all - which means you either have to find people who make the game for you, while you twiddle your thumbs (or pay them money!), or you have to learn first how to do it yourself. Depending on what you want to get done, I assume around 2-4 years for the modelling, texturing and animating, then 1-4 years for the programming.

You can save some time by using the right engines (and not starting from scratch). MMF is good for 2d games. Making 3d games with it is VERY VERY difficult, and the outcome might not (will not) be what you expect - that's because MMF is not made for 3d games.

I think the day you're ready for 3d is the day when you don't have to ask how to do it anymore
I'm not kidding.

Very nice report! You got everything covered!

Oh sorry, must have missed that. You're right then. Using regular conditions wouldn't work. Don't we have something like "sample stopped" or so that gets triggered exactly when the sound is done playing?

Quote from Nifflas

That's not a bug or an error. That's just logical and makes sense. Loading a sample is not instant, and MMF2's events are executed once every frame rather than magically perform the "play sample" action out of place exactly when the previous sample stop. Then, there's the soundcard latency too. If CT included the feature to play separate samples after each other without a delay in between, you'd have to specify what sound to play next before the previous sound has stopped playing, so the program can pre-load the sample and take all the things above into account too. Having an event doing it triggered by a sample's end is not possible by plain logical reasons.

That doesn't even make sense, given what people say. Apparently the gap is when you set a sample to loop, which means the sound is already in memory and essentially MMF knows exactly what's going to come.
And the workaround seems to be to use a "every x seconds" event to start the next sound after the duration of the previous, in which case MMF does not know what's going to come, and yet it's fine.

Why other games and programs can do it fine is because they precache the sounds / music. And so does MMF.

Why do so many different parties "hold rights" to what you recorded?

Quote from landersey

Well, I am also a newly addicted on flashgames, but I usually play SPAM. Cool games!!!

Not only necromancy, but it doesn't even relate to the topic. His first post here is just to tell us about that website? Right.

Before you add them, you should fix the outline to black.. The white AA you have there looks pretty bad on a dark background.