Personally, I intend to keep using MMF2, but I'm definitely having a go at making games using the Javascript+HTML5 combo. So far, I really like Javascript - it's simple and intuitive, and I like how widespread it's going to be (I'm sure it won't be long before all browsers and most mobile devices support HTML5 games).
It took me 3-4 years to learn to code in mmf2, with no prior knowledge of coding. So currently im not thinking about expanding my knowledge.
But if i would decide to i would probably choose C++ or java cause i heard it's the best basis to learn everything else.
I started with C# a while ago but stopped for some reason... anyway, I was surprised how easy it was to get into - all the logic I've learned from MMF2 carried on quite seamlessly! The only hurdle is getting to grips with all the terms and syntax, and I'd have to be working with it for a long time for that to stick in my head.
I intend to expand at some point, but I'm just so comfortable with MMF2! I think I'll continue using it for a very long time, if only for quick prototyping.
I feel like there's much more to learn from MMF2 than what I have grasped so far. There's no need for me to move on to another encyclopedia when I've barely cracked the book I'm holding in my hands.
I'm not good at it right now, to put it plainly. Additionally (and personally), software development is too low on my priority list to pursue beyond a hobby at this point in my life anyway. I like being a support person for more skilled coders/authors (as in testing); I contribute to their success without feeling the pressure (or need to summon the motivation) to produce more myself.
Interesting...
With all these other options becoming available, I thought more people would be lured away from MMF2. I guess not (for most people anyway).
And yes Adam, I did say "in the near future", not that it matters.
When was the last time Clickteam announced anything at all about MMF3?
I can see it being obsolete by the time it's eventually released...
I don't plan to learn anything any time soon - i barely have enough free time to make any games with MMF2 as it is! Shame though, as my ambition and ideas always remain so high and varied. I really enjoy having other hobbies and responsibilities though.
Originally Posted by Sketchy Interesting...
With all these other options becoming available, I thought more people would be lured away from MMF2. I guess not (for most people anyway).
And yes Adam, I did say "in the near future", not that it matters.
When was the last time Clickteam announced anything at all about MMF3?
I can see it being obsolete by the time it's eventually released...
Well you could just say that all klik products were obsolete when released because people could have just learned C++ or something else more powerful instead.
As long as MMF3 improves upon the formula I'm fine.
That's not really what I meant. Obviously Clickteam products have never been able to compete with real programming languages, from a technical point of view.
I was thinking that maybe the kind of games you can make in MMF2 (ie. mainly relatively simple arcade-ish games) will all be online, and having to download and install a simple game won't be very appealing to gamers any more.
Yes, there's the Flash exporter, but how long is Flash going to be competitive, given that Steve Jobs is doing his best to kill it, and there's HTML5 now?
Maybe MMF3 will be designed to make HTML5 games, as Construct 2 is - who knows?
Personally, I don't think it's enough to just "improve on the formula"...
I've been feeling the need to start looking into C++, not because MMF2 has in any way proven too "weak" for any of my ideas, but rather it feels like a natural progression after 13 years of high-levelling it.
Though I won't ever stop using Click products, love em too much!
Plus the fact that they can be a better alternative for many types of games.
Originally Posted by Sketchy That's not really what I meant. Obviously Clickteam products have never been able to compete with real programming languages, from a technical point of view.
I was thinking that maybe the kind of games you can make in MMF2 (ie. mainly relatively simple arcade-ish games) will all be online, and having to download and install a simple game won't be very appealing to gamers any more.
Yes, there's the Flash exporter, but how long is Flash going to be competitive, given that Steve Jobs is doing his best to kill it, and there's HTML5 now?
Maybe MMF3 will be designed to make HTML5 games, as Construct 2 is - who knows?
Personally, I don't think it's enough to just "improve on the formula"...
I don't see why all games will be online. Games have been online for a long time now . . . . Nobody wants to play a full-fledged game in their browser. edit: err I just re-read what you said. . . there are tons of games that aren't "simple" that are made in MMF.
MMF2 was a pretty big leap in the right direction from MMF 1.5, MMF 1.5 from TGF/MMFX, TGF/MMFX from klik n' play or click and create, etc. etc. Are you just not realizing that?
Who knows what clickteam may have up their sleeves? I don't think they've failed to satisfy just yet so I'm not going to imagine being disappointed just yet.
I have no plans to expand beyond using MMF2. That said I know some C++, Pascal and various other programming languages and have never had the urge to move on from click. I guess It's just easier to use MMF2
@Gamester - I'm not going to argue with you, because I've seen what happens when people try to engage you in polite debate - but suffice to say I don't agree.
I wish I could could say the same. I've been in a major slump for a few months now with everything, even though I have it easier than ever and more time than I know what to do with. Superbum.
Originally Posted by Sketchy @Gamester - I'm not going to argue with you, because I've seen what happens when people try to engage you in polite debate - but suffice to say I don't agree.
Err maybe you should go back and read my posts where people "try to engage me in polite debate."
I don't care if you disagree with me. I'd like to know what makes you think games being playable in a browser would cause downloadable games to become significantly less popular. Most games you play in the browser are going to be simple and many downloadable games are going to be larger and more complex. Given the fact that both have co-existed for a long while I just don't see it happening.
Originally Posted by Sketchy @Gamester - I'm not going to argue with you, because I've seen what happens when people try to engage you in polite debate - but suffice to say I don't agree.
The thing is, lots of people use click products because they don't like/are not good at/don't have the time for coding. That is why they are not likely to move on to something that does involve a lot of hard assed coding.
When I started working at my current job I was about 30-45 minutes away from home and worked 8:00-5:00. When I started I was told I would be able to move to another area that is much closer to my home if the opportunity came up. A few months ago that opportunity did come up and I took it. Now I live 10 minutes away from my workplace, work 8:00-3:00, leave at 2:00-2:20 on most days, and still get paid for 40 hours a week.
Instead of working on games, or even playing videogames, I just browse the internet most days when my gf isn't home . I started doing that when I moved, which is odd, because I actually enjoy my job and it is quite easy.
Yeah I've tried to get a friend to make something simple with me, just to get warmed up to actually getting crap done, but he usually gets too ambitious with it and things go downhill quickly.
I do have a lot of sprites to work with left over from the xmas competition, I just need to get crackin' >_>
I'd like to get into Unity and Flashpunk some more as I've only dabbled in them a little. I just need more time.
Eventually I'd like to move on from MMF. Not in the near future, though.
If I had much more free time I'd already be actively looking at other game dev tools or languages; the desire to change is already there, but as things are I'm stuck using MMF.
Definitely going to move out of MMF eventually. MMF is supposed to be a tool to make things easier. I've hit way too many barriers, and the workarounds are proving to be more work than just doing it differently. The worst thing is that klik and typical programming methods don't go well together. In programmability, MMF2's a huge improvement over MMF1 (which didn't even color code the expression editor) but still poor.
I already do a lot of C programming, it sucks for making games. I don't even see why people are so eager for it, C's better for low level programming rather than gaming.
So, Construct looks like the best alternative so far, even with the bugs.
Of course, not saying everyone needs to switch out of MMF2. But MMF2 is just way too inefficient for the way I prefer to do things.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
I've really been hiting those limits with MMF2. Some people complaining about my last game that it's slow and resource intensive, even though I used every trick I know to make it as efficient as possible. Plus coding in MMF makes things pretty rigid.
So I'm reworking it in C++ Definitely takes a lot more time, but the flexibility and efficiency make it worth it.
I'll return to MMF2 after it though For simpler games it's perfect. And maybe then we'll have shiny new runtimes from clickteam.
I am looking at IRRLICT and the Dark GDK, both are pretty cool. I have not quite made my mind up which one to go for yet.
I will still use MMF2 for most 2D games, although I am finding my isometric game a bit of a drag in MMF2. That said I find MMF2 quite therapeutic at the end of a hard day.
I do a lot of programming in C - it maybe long winded but I always get the results I desire at great efficiency - so a C based language seems the right direction for me to go in.
I was looking into the possibility of making games with C/Java/etc a long while back.
The general impression I got (right or wrong) was that the actual game-logic part would not be too bad, but that common tasks such as simply drawing an image on screen, would require an awful lot of code (and then for a game you'd need to use double buffering, etc as well). I'm sure there are libraries you could use which would make it easier though. The other thing, is that there's all the hassle of having to compile the source code to test anything.
This is why I like HTML5 & Javascript - you have the canvas element to make it easy to draw graphics (the browser does all the complicated stuff behind the scenes), and any time you want to test something, you can just hit the refresh button in your browser.
Obviously performance is not comparable, but it seems like a nice stepping stone if you wanted to move from something like MMF2 to an actual programming language.
Originally Posted by ..::hagar::.. I am looking at IRRLICT and the Dark GDK, both are pretty cool. I have not quite made my mind up which one to go for yet.
Isn't there an IRRLICHT extension that has been in development for MMF for quite some time?
Originally Posted by ..::hagar::.. That said I find MMF2 quite therapeutic at the end of a hard day.
Haha I feel the same way. MMF 1.5 was a frustrating pile of redundant bs though .
I am moving to java, Hooghaar Classic will eventually be finished and made with it. And as it's java based, it will work on windows, linux and mac os.
Also I am trying to setup my engines in java and a (nearly) parallel one in javascript with html5, the target audience just got bigger with the support of canvas in Internet Explorer 9.
In my opinion java doesn't need an awful lot of code to draw things on screen or to do double buffering, especially when compared with html5. But when you make the comparison with mmf2 then it does take quite some code, mostly because mmf2 handles that code for you.
You're right about compiling and testing, that's why game logic is often coded in a scripting language which can be loaded on the fly for debugging. For testing in html5 there is no need to compile, just hit the reload button or F5
When I started working at my current job I was about 30-45 minutes away from home and worked 8:00-5:00. When I started I was told I would be able to move to another area that is much closer to my home if the opportunity came up. A few months ago that opportunity did come up and I took it. Now I live 10 minutes away from my workplace, work 8:00-3:00, leave at 2:00-2:20 on most days, and still get paid for 40 hours a week.
Instead of working on games, or even playing videogames, I just browse the internet most days when my gf isn't home . I started doing that when I moved, which is odd, because I actually enjoy my job and it is quite easy.
Soooo, when you get a real job you might stop trolling this place?
I've never really had the patience or will power to ever complete anything other than simple games or ideas.
I could potentially go in any direction i wanted. I know almost every popular modern language there is, and am very adept at quickly learning any new language, as core concepts are easy to learn, and while new syntax/semantics can be a bitch to get a handle on, they are never too hard to grasp.
@Sketchy - drawing in Java is so simple its not even funny. Its more or less the following. Use a JFrame or JPanel or both and just override the public paint method. then in your game logic you just make calls to repaint() and java decides when stuff needs to be drawn again using the overriden paint method.
@Override
public void paint(Graphics g) {
g.setColor(Color.RED);
g.fillRect(10,10,10,10);
}
Java Graphics class has plenty of methods to do basic primitives, or drawing sprites loaded into an Image class object ( g.drawImage(Image img, int x, int y, ImageObserver observer) ).
This is the current state of my Final Project for my Advanced Java Class. Its a PacMan clone. Ive been working on it for maybe 2 weeks in my spare time between work and school.
http://www.cecilectomy.com/index.php?page=Home&id=44
Haven't really tested it on anything other than my laptop and desktop, both of which are mid ranged computers (2.2ghz+ dual core, 2GB+ RAM), and it runs at full speed 80fps + or - a few fps.
n/a
Assault Andy Administrator
I make other people create vaporware
What I don't like about Java is how you can't compile things "natively", which is the whole point of Java in the first place. You always rely on the JVM, and it looks unprofessional in many ways, out of the box. There are some work arounds, in the form of launchers right up to something expensive like Excelsior Jet which truly compiles Ahead-Of-Time. But for normal usage, I find that restriction quite annoying in game development.
@Sketchy - drawing in Java is so simple its not even funny. Its more or less the following. Use a JFrame or JPanel or both and just override the public paint method. then in your game logic you just make calls to repaint() and java decides when stuff needs to be drawn again using the overriden paint method.
Ehrm you don't want to do that, because you don't want java to decide when java will paint something on screen. At least for games, which is usually the scope here at tdc. You want active rendering and probably with a double buffer. On which is currently being displayed and the other one to draw on. Which is easy once your image is loaded and the graphics object is know. Just use the drawImage() (see note for html link) method for the graphics class, even better the Graphics2D class.
After all drawing has been done, flip the buffers et voila. No just try to limit this process to say ... 60 fps?
@Assault Andy
You're right about the JVM, with MMF you don't have that problem, except there might be some other dependencies. Java and the JVM works a little bit like microsoft and its .net framework, you need to have the .net framework installed in order to use some .net application, also very annoying.
To exaggerate a bit: I need to have some version of windows in order to play my mmf game. What if I am running Mac OS X or Linux? Then you would need to compile a different binary. With java this isn't needed, just install the vm for windows, linux or osx and run the same packaged java byte code. It's what I like about java.
Just at some point dependencies come in, it's just a matter of your likening: a virtual machine? directX? openGL? a minimum amount of ram? a decent gpu or cpu? Lot's of hard drive space or almost none?
The windows computer with decent hardware is already available probably with directx and no other things need to be installed, just unzip and run your game. I like that idea too, but I want it on all platforms with the same software package. Java allows me to do that.
And compiling native code is an option with java, it's just harder to do and drags in some more stuff in the package.
So I say, html5 is the way to go, with your browser and those blazing fast processors of nowadays! And if not it's probably managed in some kind of framework.
Note: html link for drawImage() (remove the "" marks before or after pasting, this complicated url isn't supported in tdc forums at the moment)
"http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Graphics.html#drawImage(java.awt.Image, int, int, java.awt.Color, java.awt.image.ImageObserver)"
Actually, come to think of it, my future might be in education. I have been teaching TGF2 now for 3 months and it is really fun. So instead of "moving on" I might just start reeling in new click product users
When I started working at my current job I was about 30-45 minutes away from home and worked 8:00-5:00. When I started I was told I would be able to move to another area that is much closer to my home if the opportunity came up. A few months ago that opportunity did come up and I took it. Now I live 10 minutes away from my workplace, work 8:00-3:00, leave at 2:00-2:20 on most days, and still get paid for 40 hours a week.
Instead of working on games, or even playing videogames, I just browse the internet most days when my gf isn't home . I started doing that when I moved, which is odd, because I actually enjoy my job and it is quite easy.
Soooo, when you get a real job you might stop trolling this place?
Heh.
Considering that I support 2 people, pay for a home, land, all bills, entertainment, soon 2 vehicles, and more, I think I'm dabbling in the realm of mediocrity at the least. By the time I'm in my 30s I'll have more money than I'll know what to do with. Poor me.
I may be extending a business with a family member soon and I'll probably be spending most of my not-at-work time there, so you may or may not see me less.
Ehrm you don't want to do that, because you don't want java to decide when java will paint something on screen. At least for games, which is usually the scope here at tdc. You want active rendering and probably with a double buffer. On which is currently being displayed and the other one to draw on. Which is easy once your image is loaded and the graphics object is know. Just use the drawImage() (see note for html link) method for the graphics class, even better the Graphics2D class.
After all drawing has been done, flip the buffers et voila. No just try to limit this process to say ... 60 fps?
sorry, you obviously don't understand how java does its rendering. or how rendering is done in general.
if you make continious calls to paint "active rendering" you are using unnecessary cpu, and will slow down your game even more than it might if you only render when the entire scene has been rendered. this is how java works. you make a call to repaint which is like telling java "hey i would like you to draw my scene now" and java either says "okay!" or "look, im not even done drawing the last scene yet, let me finish then i will draw your new scene". this is a lot more efficient, and what makes java a great platform. or you can implement your own way of determining when to paint, and just call your own paint method directly. but you should never just continuously call any rendering method. I was just giving Sketchy an example of how easy drawing in java CAN be.
as for double buffering, this is also very simple. it is a bit more complicated than drawing itself so i wont show an example, but yes, you draw to a surface that is not visible, then draw that surface to the screen (flipping the image).
because of both of these, flicker is almost non existent.
and about limiting it to 60 fps. You actually really should seperate your Frames per Second and your Updates per second. you can still be updating at your preferred rate, but draw at a slower rate if the resources are not available. this way all logic is still done and the game doesnt skip a beat. logic should never be tied to the games rendering.
Originally Posted by Chris Street MMF3 development hasn't started yet; I believe Clickteam are planning though.
Says who?
If I remember correctly they mentioned at the convention that they had a list of things they wanted to implement in MMF3. In the Questions and Answers segment.
Originally Posted by The Cecilizer I was just giving Sketchy an example of how easy drawing in java CAN be.
Yeah, it does look pretty easy. HTML5+JS still seems a little easier, because javascript is so simple, and because of all the things the browser does for you (double-buffering is not required, for example).
Obviously I'm not saying HTML5 is "better" - it's too much like comparing apples and oranges.
Originally Posted by Chris Street MMF3 development hasn't started yet; I believe Clickteam are planning though.
Says who?
If I remember correctly they mentioned at the convention that they had a list of things they wanted to implement in MMF3. In the Questions and Answers segment.
That's over a year ago almost maybe Development has started, but it is still in a very early stage.
Have you even been far as decided to use even go want to do look more like?
Originally Posted by The Cecilizer
sorry, you obviously don't understand how java does its rendering. or how rendering is done in general.
Perhaps I am reading your post wrong, but what part don't I understand? That is, you don't want active rendering because it will be using all cpu/gpu power for a game? Isn't that a matter of choice?
I know of implementing time-steps, decoupling the main game loop from your render and indirect rendering, but probably I don't want that and you do.
My purpose was also showing how easy drawing in java can be, just like the drawImage() function in html5 which was more or less modelled after java's function. But I also wanted to show a different point of view on the rendering process, that's a little habit of mine with no harm intended. I just want to give some more information so the big picture might become clearer.
But perhaps you can then explain it to me, because I don't know what's wrong with drawing on a buffer and then flip the buffer on screen?
Perhaps I am reading your post wrong, but what part don't I understand? That is, you don't want active rendering because it will be using all cpu/gpu power for a game? Isn't that a matter of choice?
a pretty bad choice if you decide to let your game just hog cpu/gpu.
I know of implementing time-steps, decoupling the main game loop from your render and indirect rendering, but probably I don't want that and you do.
again a pretty bad choice if you decide not to. not as bad as above, but it makes things a lot easier to maintain and scale.
But perhaps you can then explain it to me, because I don't know what's wrong with drawing on a buffer and then flip the buffer on screen?
I...never said anything was wrong with double buffering...??? O_o
Advertisement
Post Reply
Edited by GamesterXIII
. I started doing that when I moved, which is odd, because I actually enjoy my job and it is quite easy.
For simpler games it's perfect. And maybe then we'll have shiny new runtimes from clickteam.
.
jenswa.neocities.org
