next »

[Juhkystar]

Hmmm... Some good resources to look into, although I think it only expands the amount of research I have to do. 

The biggest problem I have with Gamemaker is the drawing. The particle system collisions are too basic and uneditable, the drawing-to-surface trick doesn't work with animated primitives. If you draw, for example, a vine system using One object, you have to use collision_line() checks which bogs down the system.

Specifically the Primitive drawing problems. If I want to draw a moving snake using textured primitives, drawing to a surface EACH frame is worse than just drawing individual triangles. And a lot of the larger creatures we have flying around the air have moving appendages like wings, tentacles, undulating bodies. Things like a small bat-like creature are fairly small and easy to draw, but a large swaying creature will hurt the framerate a lot.

I actually did a group by group test with our objects. However, the specific test was on a ridiculously bad computer and a general test on a more modern computer so I can't  really compare it to newer ones. I was getting about 12/60 fps with everything, and on some normal 2007 computers I was getting 45/60. With no backgrounds running I got 45/60 on the older computer, and (55-60)/60 on the newer. I won't go into specifics here, but our attempts to fix the fps have basically made us think about using something besides GM.

Honestly, I'm willing to accept if some part of our grand scheme is too impractical, but by golly I'm going to squeeze every last bit I can out of our code. Basically we were realizing that quite a few things we want to do are going to eat up resources in GM so we came here. It may just be that we can't do what we want at all, but I think it's more like we don't know exactly how to go about doing it in a general programming sense. But GM's drawing is really killing us with the backgrounds and weather.

Okay, on to specific replies not addressed above:

@Moi:
Yes, I agree that most "first game" ideas are super large, but Aquaria was made by two people and merged RPG elements with an under water shooter basically. Besides, we know that games aren't made overnight. For all we know it might take us 5 years, but it'll be worth it. Besides, this isn't either of us first game. Just the first large scale one.

@st33d:
Would Flash be able to handle using many alpha'd sprites? Like Bullet trails? Clouds? explosions? Ice rocks? I'm not very familiar with Flash so i assumed it wouldn't, but then again, assuming things is most people's downfall. Care to shed some light on this?

@Aik:
Holy crap those are some sick graphics. Their gallery only really shows off 3D stuff, but I guess the same functions can be applied to 2D renders correct?

@lpmaurice:
Wow, that's a very intuitive way of organization. I actually started to do something similar with bullet/plant collisions because it was such a waste to have to override or not use the parent's destruction collision code.

[ஒழுக்கின்மை (Paul Eres)]

isn't the speed in GML capped

Whaaat? That's the first time I heard of this.

Are you thinking of frame rate, not processing speed?

neither is capped.

frame rate can be up to 9999 fps (if your computer can handle it). that's a cap but -- nobody will ever need to exceed that (okay, maybe not nobody, but nobody i know).

processing speed is as fast as your processor can go.

it's an interpreted language so of course it'll be slower than other languages (it's about as slow as python or flash) but if you learn to code effectively and learn what to do and what not to do there's virtually no 2d game you can't make in it. if there's a minor feature that's not essential that absolutely won't work in gm, you can always make the game and cut that feature out, but i've never actually had to cut out a feature i wanted due to the limitations of gm in the four years i've been using it.

[st33d]

You can blit in flash. There's a copyPixels method that the BitmapData class uses that can be used to paint thousands of sprites every frame. I use it a lot for effects, particles, smoke trails and now to render all of the scenery - it's a lot faster than using MovieClips.

Flixel is based on this method, so you can look at that for a start. I use my own framework personally.

I used to quote the particle amount you could muster as 1000, until I went and checked a test program I wrote. It went up to 10,000 without slowing.

[BorisTheBrave]

(it's about as slow as python or flash)

Orly? Has it changed for GM8, because in 2008 I found it to be twice as slow as python, and vastly slower than flash. I am still of the impression that GM is totally unsuited to complex projects, which the OP is nearing.

[salade]

Honestly, performance wise, it's all downhill from assembly...

I would consider LÖVE as a jumping off point. It's best for prototyping, but since the whole thing is open source under the zlib license it's a pretty small step to open the source up and see what's making stuff work.

If the only thing keeping you from making game maker is your weather effects though then I certainly wouldn't rule it out. Without seeing it in motion there is no way to tell what is causing you so much trouble, but in the grand scheme of things, throwing in the towel because you can't get some effect to work would be a bad idea. Still though, without seeing it in motion i'm really just taking shots in the dark...

[increpare]

I am still of the impression that GM is totally unsuited to complex projects, which the OP is nearing.

OP?

[Falmil]

Original Poster. The one who started this thread.

[Aik]

@Aik:
Holy crap those are some sick graphics. Their gallery only really shows off 3D stuff, but I guess the same functions can be applied to 2D renders correct?

Yeah - I'm pretty sure all you do differently for 2D is set the camera to ortho mode, so everything else should just be the same.

[Dacke]

Yeah - I'm pretty sure all you do differently for 2D is set the camera to ortho mode, so everything else should just be the same.

Sounds about right. I did the same thing with C++/OpenGL for three earlier projects I have worked on. The benefit is the awesome power you get when rendering certain things. The drawback is that it can get overcomplicated, when using something that is more general than you need (3D instead of 2D).

But there are great libraries that use that power, but give it to you through a 2D-api. I find that more elegant and easier to use.

[drChengele]

a) Procedural generation, dynamically generated seamless 3d world, physics.
b) You know C++ already.

There's your answer right there, really.

Not to be a snob, all languages have their strengths and weaknesses after all and god knows C++ is not pretty by any definition of the word. But it executes fast, and from what I see it suits your needs, plus you already know how to code in it so there will be no learning overheads. XNA is also an option, but the usual considerations apply. I would NOT recommend Game Maker, Java or Flash for a project of these specifications.

Either way you will be none the worse for coding a game in C++/XNA/C#/whatever, because it gives you a lot of control and opens up a lot of doors.

Sadly I cannot recommend an appropriate game engine because I rolled my own. There are millions of libraries for every language out there, so there is no need to reinvent the wheel.

[Dacke]

Hey now!
Not to start (yet another) language discussion. But Java executes just as fast as C++, if you don't specifically optimize your C++ code (which is quite difficult). For example, the Java garbage collector is more efficient than what a fairly skilled programmer can accomplish in C++. Java and Python (etc.) have access to hardware accelerated graphics these days, too. Unless you are going to make an AAA game, Java or Python will do fine.

[drChengele]

Hey now!
Not to start (yet another) language discussion. But Java executes just as fast as C++, if you don't specifically optimize your C++ code (which is quite difficult). For example, the Java garbage collector is more efficient than what a fairly skilled programmer can accomplish in C++. Java and Python (etc.) have access to hardware accelerated graphics these days, too. Unless you are going to make an AAA game, Java or Python will do fine.

Of course, of course, didn't mean to imply otherwise, and noone wants to start a pointless language war. But it's not just about speed of execution. The specifications for the project seemed to heavily rely on seamless open 3d worlds, and my reasoning was you can't accomplish easily without some GPU work and mesh magic. So you need DirectX or OpenGL. Now, I know there are bindings for these in Java, but the majority of code base for the powerful 3d stuff out there is in C++. Or maybe I am just not moving in the right circles?

Anyway, that's the reason I suggested C++, not because I think Java is inherently too slow or something.

Oh and personally I don't use garbage collection at all in C++, and I don't know how it can get any more efficient than manually deleting your pointers.

[st33d]

Hey now!
Not to start (yet another) language discussion. But Java executes just as fast as C++

What. The. Fuck?

This some kind of troll?

[Dacke]

Bad choice of words, sorry. The execution speed is slower. But an unoptimized program written in Java can accomplish just as much as an unoptimized program in C++ in the same amount of time. Many clever optimizations are built into the language, including a blazing fast garbage collector, which allows you to write fast programs faster. This is OT, though, but I'm happy to have a language war in another thread

Edit: As a reference, I give you this extremely low-quality Wikipedia page: http://en.wikipedia.org/wiki/Java_performance#Comparison_to_other_languages.

[Juhkystar]

Hmmm, just to clarify, this is a 2D game we are trying to create, although we can just as easily do it in 3D. Just throwing it out there (jtiot), but what does anyone think about Unity? I personally don't think it would be as flexible for us, but hey, you never know...

[Ina Vegt]

Oh and personally I don't use garbage collection at all in C++, and I don't know how it can get any more efficient than manually deleting your pointers.

Well, then you run into the problem of manually keeping track of those pointers. Which in any sizable project is -quite- difficult. You also need to remember to free the memory those pointers point to, etcetera.

That's asking for memory leaks there.

[Mikademus]

  Dacke, please take your language wars elsewhere. (1) Tigsource is mostly free of them and that's the way we like it, and (2) the late 1990's called and it wants its Java-vs-C++ conflict back.

Bad choice of words, sorry. The execution speed is slower. But an unoptimized program written in Java can accomplish just as much as an unoptimized program in C++ in the same amount of time. Many clever optimizations are built into the language, including a blazing fast garbage collector, which allows you to write fast programs faster. This is OT, though, but I'm happy to have a language war in another thread

Edit: As a reference, I give you this extremely low-quality Wikipedia page: http://en.wikipedia.org/wiki/Java_performance#Comparison_to_other_languages.

[Dacke]

Mikademus, that was two days ago. I had no intentions to start anything like that, and I don't think I did. First there was (what I thought was) a claim that Java wasn't fast enough. I felt it was relevant to point out that it is. When doing so I said some stupid things, which st33d pointed out. I then wanted to clarify what I meant. In both cases I wanted prevent bad information from spreading (in the first case no-one was wrong, in the second case I was wrong).

Edit:
Ina Vegt: You have accidentally misquoted me. It was drChengele who said that

[Mipe]

People on the internet admitting they were wrong? What has the world come to? 

[Dacke]

Hmmm, just to clarify, this is a 2D game we are trying to create, although we can just as easily do it in 3D. Just throwing it out there (jtiot), but what does anyone think about Unity? I personally don't think it would be as flexible for us, but hey, you never know...

I think you may be better off using an API that is specifically designed for drawing 2D-graphics for games. There are so many things that can go wrong and take time, to begin with. When prototyping I think you want as distractions as possible (like the ability to use 3D-effects). If you have the opportunity to start using super-fancy stuff, it's way too easy to get distracted by it (I think).

Though if your main focus is making cool graphics, using 3D can he very helpful from what I understand. (But even then, prototyping in pure 2D with programmer-graphics can still be a great idea)