Answer to the original question: Nothing, basically.
When I have a good idea, I will usually finish the game. Also, I enjoy making minigames, which makes them a whole lot of faster to finish. I can't draw anything, so gfx take just 10 % of the development time.
I mean, seriously... are you even making anything in MMF2? Are you aware of the amount of bugs in it? What I coded should have worked, plain and simple. The only reason it didn't is becasue MMF has a bug that is keeping it from working properly. So,yeah, I'm blaming the tool becasue the tool is faulty. If it's through no consequence of my actions then how could I be considered a "poor craftsman?"
That'd be like if you bought a saw from a hardware store that had no teeth, so you couldn't saw a board with it. Would it be fair to say that you just suck at sawing? Hardly. The major difference here is you can't see whether or not MMF2 really has teeth until after you buy it. So try not to be a jerk, all right?
deadeye:
it sounds like you're wrong, but if you want to make excuses for your slow development cycle, it doesn't bother me.
Maybe this is more like if I bought a saw and tried hammering nails with it. Then I got mad at it for not hammering nails properly. Then I got on a message board and complained about it because it didn't work the way I wanted it to. Then some guy I didn't know quoted an aphorism to me and I got all defensive about it. Then I cried myself to sleep because girls don't appreciate my sensitivity and only wnat to be with stupid jerks like that goddamn internet guy. Fuck that goddamn guy goddamn it!!!!! Maybe it's more like that. Just saying.
By a route obscure and lonely,
Haunted by ill angels only,
Where an Eidolon, named night,
On a black throne reigns upright,
I have reached these lands but newly
From an ultimate dim Thule
From a wild clime that lieth, sublime,
Out of space
Out of time.
It more like you're just an idiot who innapropriately spouts irrelevant "pearls of wisdom" in an effort to be an asshole to people you don't even know, and follows it up with childish schoolyard bullying. On the internet, no less.
Isn't that just great for you. You're a really awesome dude.
The inability to make a game up to my own standards keeps me behind from making full blown games. Things like graphics, sounds, and music, need to be top notch or else I just wont feel like what I'm making is worth all the time and effort, hense I lose interest and forget about it.
deadeye:
Oh, you know what? I asked around and, it turns out you're just being a crybaby. I'm not going to hold it against you, though, because you might just be cranky. Maybe a nap or a nutritious snack would help. I likes grapes and pineapples. What do you like?
Aside from throwing comebacks at one another, I'm going to side with Defestrator here, only because he's correct to the extent. MMF2 is very stable if you know what you're doing with it, not to say that anyone who runs into bugs with MMF2, doesn't know what they're doing. MMF2 isn't the most stable piece of software in the world, no doubt, but in the end, it's much more stable then it's predecessor, which did a great job creating both freeware and commercial games for hundreds of folks around the klik community and even the net itself. So yes, Defenstrator has a point when it comes down to blaming MMF2 for faults that you make.
I will admit however, in deadeyes defense here, that I have run into a good bit of issues in MMF2, none of which have pushed something that should have taken a couple hours, out to a few days though. It's all a matter of having multiple backup attempts to do something, just incase the idea wasn't full proof or MMF2 just might not like it for some odd reason.
PS: I think it's easy for anyone to see however, that MMF2 is being updated and patched very nicely thanks to Clickteam keeping up on the demand we pushed on them (to fix the bugs asap) so considering that, I think it's safe to say that unless you're willing to deal with the bugs and stop complaining about them and actually reporting them, just go over to coding. Just understand that if you run into any bugs while you're coding, be prepared to debug your ass off, because unlike in MMF, you're excuse "it wasn't my fault, it was the tool" wont cut it, all problems in a game are your fault, even if it's on another computer with faults of its own. Your job is to make sure the game or application is stable as can be on just about any system you can. This includes making sure minimum requirements actually mean that the application/game runs half way decent.
I tried several different methods to get it working right. Each of which should have worked. I even tried out what I was doing in 1.5 and it worked just fine. And yeah, I came up with a workaround to the problem in the first day. In fact, I came up with a few different workarounds. None of which is very satisfying, considering the fact that I shouldn't have to be going out of my way to work around a faulty program in the first place. The extra day and a half was spent tweaking several different solutions and deciding on the most efficient one.
The game I'm making may look simple on the surface, but the engine that runs it is not. Since I'm going for a completely solid engine it stands to reason that I'm going to run into problems that a lazier coder either won't encounter, or won't care about. In doing so I've discovered new bugs that nobody else had come across yet and reported them to clickteam. So I wasn't "just complaining."
It is frustrating working with a faulty tool. And it does slow down progress. It's interesting to note that nobody seems to want to concede that point. And even though I expressed that frustration publicly it can hardly be considered grounds for some random jerk to be an ass about it.
One key that you will need to learn about MMF is that a flexible engine, especially for custom engines, is the way to do things. If you make sure that every aspect of your engine is running off of things that can be easily tweaked inside say an event, you will find yourself running into much less issues. Example:
Custom engine, you'll need things such as:
Jump Height
Fall Speed
Walk Speed
Acceleration
Rather then hard coding these into the engine, use counters that store that 1 value the entire time the game runs.
So lets say we have a counter for each of these:
Jump Height: A
Fall Speed: B
Walk Speed: C
Acceleration: D
Now if we need to use the fall speed at any time, just put in B, as apposed to an actual number. This will work because if the number of B is always the same, then it shouldn't give you any problems
Now say you wanted to change any of these numbers, have a group run at the start of frame, to set all these numbers, and just change what the number is set to. The rest of the engine will respond, and you've just made a 1 second tweak that WOULD have taken minutes or even hours do to by hand.
This also adds flexibility to the engine for things such as water, say the player jumped into water. If player is in water, raise jump height, lower jump speed, lower walk speed, and lower acceleration. Then when they come out, reset them. The engine will respond, because it's based on variables as apposed to hard programmed numbers.
This leaves a much smaller margin for human error and makes things much easier in MMF's case, so tool bugs are much less likely to occur. Overall, things will perform in your favor.
PS: If you're already aware of this method, that's fine, just know that I'm trying to help, not look down on you.
Advertisement
Post Reply
Edited by the Author.
