Gamedev Lounge 0010

[Hoeloe]

Not trying to come off as provoking; I'm simply stating the facts. Yeah, you can get some "oomf" to the power of your own custom engine. But it's extremely tedious to pull library from library and make everything work together. Why not use something hundreds if not thousands of other developers can confirm already works and save yourself hours of headache?

Well, you might think so, but not necessarily. It will be extra work, but the result will be better if you can pull it off. The reason being that the specification of engines changes depending on the project, and using a pre-built one means you have to work around it, rather than the other way around. You can get pre-built engines in a code-based scenario as well, but you have the ability to tweak and tailor them to your project.
There will always be limits to what a pre-built engine can do, and that's fine, but by limiting yourself further by using a GUI-based editor, you make it harder for yourself in the long run.

Not just that, but things can be more readily managed and controlled in a code-based system. I've already talked about memory management with respect to load times, but let's say, for example, you have a shmup game, which requires that a) a lot of objects be drawn on screen at once (some hundreds, or even thousands), and b) it maintains a steady 60 FPS during gameplay (since otherwise lag would make the game unplayable, because the slightest loss of control could cause death). Chances are, a ready-made game engine won't be able to pull this off out of the box. What you really need to do is optimise it in the classes. Collision detection for example. You don't even know how your pre-made engine is going about it. It might (and likely will) collide a circle against a circle with a circular detection. But, however, you might want to use rectangular collision detection, because it is much cheaper, and would give a result that is more or less what you want. You also want to make sure your data structures are set up in a way that doesn't take much time to initialise, otherwise firing a lot of bullets at once in this example will cause lag. Again, you don't have access to this in a pre-built system. etc.
If you have an engine that is tweaked automatically, it is almost certain that issues like this will build up, simply because there's no way to manage them. Without telling the program exactly what you want (i.e. through code), it has to guess, and this can produce issues, especially in a system where performance is important.

[Kitsu]

Guys, a developer should pick his tools according to his own needs and priorities.

If one believes that ease of use and a generally shallow difficulty curve are more important than number of frames or custom-fit organization, a tool like Game Maker may very well fit better than other, more advanced (but also more powerful) ones. On the flipside, if someone wants that additional power and speed and doesn't mind a steeper learning curve, a stronger tool like C++/DirectX or similar may work better.

There is no definite best tool. There are only tools that fit certain jobs and circumstances better than others.

[coty-crg]

Not trying to come off as provoking; I'm simply stating the facts. Yeah, you can get some "oomf" to the power of your own custom engine. But it's extremely tedious to pull library from library and make everything work together. Why not use something hundreds if not thousands of other developers can confirm already works and save yourself hours of headache?

Well, you might think so, but not necessarily. It will be extra work, but the result will be better if you can pull it off. The reason being that the specification of engines changes depending on the project, and using a pre-built one means you have to work around it, rather than the other way around. You can get pre-built engines in a code-based scenario as well, but you have the ability to tweak and tailor them to your project.
There will always be limits to what a pre-built engine can do, and that's fine, but by limiting yourself further by using a GUI-based editor, you make it harder for yourself in the long run.

Not just that, but things can be more readily managed and controlled in a code-based system. I've already talked about memory management with respect to load times, but let's say, for example, you have a shmup game, which requires that a) a lot of objects be drawn on screen at once (some hundreds, or even thousands), and b) it maintains a steady 60 FPS during gameplay (since otherwise lag would make the game unplayable, because the slightest loss of control could cause death). Chances are, a ready-made game engine won't be able to pull this off out of the box. What you really need to do is optimise it in the classes. Collision detection for example. You don't even know how your pre-made engine is going about it. It might (and likely will) collide a circle against a circle with a circular detection. But, however, you might want to use rectangular collision detection, because it is much cheaper, and would give a result that is more or less what you want. You also want to make sure your data structures are set up in a way that doesn't take much time to initialise, otherwise firing a lot of bullets at once in this example will cause lag. Again, you don't have access to this in a pre-built system. etc.
If you have an engine that is tweaked automatically, it is almost certain that issues like this will build up, simply because there's no way to manage them. Without telling the program exactly what you want (i.e. through code), it has to guess, and this can produce issues, especially in a system where performance is important.

What you're saying is all true. If you REALLY need that extra oomf, then by all means go build your own engine. But from that example specifically, my game Scribble Space, which I posted here not to long ago, does just that. It's a shmup that let's you draw your own ship and even dynamically creates collision setups based off what was drawn.

When you use a GUI based engine, yeah you're probably going to have some limitations, but a GOOD one (like GMS) will let you take a bit more control than usual. I literally haven't used GMS's collision detection system; simply because of what you just said.

Really, I think more editors should allow this sort of control and beyond. I like the option of not having to use the collision, not having to use their masks, and if you do it provides options for the TYPE of collisions/masks for efficiency (And for most games; collisions usually is where pre-built engine's usually fail in terms of speed).

Guys, a developer should pick his tools according to his own needs and priorities.

If one believes that ease of use and a generally shallow difficulty curve are more important than number of frames or custom-fit organization, a tool like Game Maker may very well fit better than other, more advanced (but also more powerful) ones. On the flipside, if someone wants that additional power and speed and doesn't mind a steeper learning curve, a stronger tool like C++/DirectX or similar may work better.

There is no definite best tool. There are only tools that fit certain jobs and circumstances better than others.

This. This a thousand times! My only problem in the current conversation is that the guy is making a top down 2D "zelda-like." In this situation; a program like GMS or (maybe Unity; Personally I've never used it so I couldn't really say) would be superior than writing your own engine. There isn't a lot going on at one time; and everything done could be easily coded within the pre-built engine itself.

Edit: heh..had to remove the ":" and "S" from being next to each other in "GMS" because it made the smiley..

[Hoeloe]

I agree with a lot of what you've said. For this particular title, it does very much depend on what you want from it. Optimisations can be necessary in these sorts of games, too, but with more subtle uses (usually based around memory management), for things such as keeping enough memory to have seamless, large maps (such as most 2D Zelda games have). Storing the entire map in memory is not going to cut it, so you can decide whether you split the map up into segments (loading in each segment as you enter it), or take a more procedural approach, and load in tiles as you come nearer to them.

A lot of it does come down to preference, I will definitely agree (and as you may have noticed, I strongly prefer the code-based system), however, most languages will give you greater control than a GUI system. This is simply because the GUI systems compile down to a specific language (usually C/C++, or sometimes Java). However, they tend to concentrate on just the elements of the language that the creators deem useful to game making. While this is fine in a lot of cases, you can no doubt see how this might be a limitation, as it may even cut out features of the language to such an extent that it ceases to be Turing-Complete (though most won't strip it down that far).

There is another benefit to code-based systems, other than physical changes in performance, and that is simply that you have access to what the program is doing. With a bit of deeper understanding, you can trace this back and work out precisely how the computer is interpreting your instructions, and often this can make debugging a much simpler affair, as well as allowing you to take shortcuts and such.

[coty-crg]

I agree with a lot of what you've said. For this particular title, it does very much depend on what you want from it. Optimisations can be necessary in these sorts of games, too, but with more subtle uses (usually based around memory management), for things such as keeping enough memory to have seamless, large maps (such as most 2D Zelda games have). Storing the entire map in memory is not going to cut it, so you can decide whether you split the map up into segments (loading in each segment as you enter it), or take a more procedural approach, and load in tiles as you come nearer to them.

A lot of it does come down to preference, I will definitely agree (and as you may have noticed, I strongly prefer the code-based system), however, most languages will give you greater control than a GUI system. This is simply because the GUI systems compile down to a specific language (usually C/C++, or sometimes Java). However, they tend to concentrate on just the elements of the language that the creators deem useful to game making. While this is fine in a lot of cases, you can no doubt see how this might be a limitation, as it may even cut out features of the language to such an extent that it ceases to be Turing-Complete (though most won't strip it down that far).

There is another benefit to code-based systems, other than physical changes in performance, and that is simply that you have access to what the program is doing. With a bit of deeper understanding, you can trace this back and work out precisely how the computer is interpreting your instructions, and often this can make debugging a much simpler affair, as well as allowing you to take shortcuts and such.

True, true, true and true. Well now that we're at an understanding; I think the question for that guy really should come down to how well of a programmer he is in specific aspects of programming.

Personally I can think of at least 5 ways off the top of my head to go about making an infinitely large map in GMS, but I can also see why it would be much much easier to do in your own engine.

Edit: Also, this definately depends on the platform he's going for. If he's going for a 2D game on the PC platform..honestly it doesn't matter what he uses as long as he gets the job done. Now if he's going for mobile (like I've been doing lately), that's where he needs to really pay attention to speed and general optimization of -everything-, really.

[Hoeloe]

Yes, definitely. For a 2D game on the PC, the engine makes little difference for this kind of game (as long as you avoid Flash. Trust me, I tried). It is mostly about personal preference. When you want to introduce things such as shaders and lighting effects, then it starts requiring a bit more optimisation, and if you make the jump into 3D, then it takes a lot more. The platform does also make a difference, since some engines won't support some platforms, and things like phones do require that extra push.

[Phaze]

All this conversation on engines, APIs and languages makes me glad that I'm at least gonna be trying to make my first 'real' project in C++ with OpenGL. I honestly don't know what platforms it'll be on but I do definitely want it to be portable across OSes with a degree of options for other platforms if I ever decide it's a good idea to (consoles? Handhelds??).

Not to mention I wanna make this hopefully run on anything, performance wise. That dinosaur computer from 10 years ago might not appreciate fancy shader-based light and water effects and I would certainly like to have a broad range of hardware capable of running it, even if it requires gimping the graphical quality of the game to run. Question is if I'm a capable-enough programmer at that point to implement it in this way

[coty-crg]

All this conversation on engines, APIs and languages makes me glad that I'm at least gonna be trying to make my first 'real' project in C++ with OpenGL. I honestly don't know what platforms it'll be on but I do definitely want it to be portable across OSes with a degree of options for other platforms if I ever decide it's a good idea to (consoles? Handhelds??).

Not to mention I wanna make this hopefully run on anything, performance wise. That dinosaur computer from 10 years ago might not appreciate fancy shader-based light and water effects and I would certainly like to have a broad range of hardware capable of running it, even if it requires gimping the graphical quality of the game to run. Question is if I'm a capable-enough programmer at that point to implement it in this way

Wanting it to run on "anything" isn't always the best idea, either. It may end up just being a waste of your precious time; and hurt end users with better setups. The average pc or laptop today has a dual core with some sort of video chip/card and at least 3-4gb of RAM. Keep that in mind. It also depends on your audience!

Details, details.

[Hoeloe]

Making it run on 'anything' is always going to be impossible. There are so many different specifications out there that you just aren't going to be able to do them all. Also, with a language like C++, you'll need to make sure it works on different OS' and different processors, since it compiles down to a binary, and a program that runs fine on an ARM processor may not work on a MIPS one, etc.

However, what you said has some merit, in that you shouldn't just go for the top-end computer, since that will exclude your audience. Also, keep in mind that most machines WILL NOT HAVE more than 4GB of RAM. This is because, despite a transition happening, most machines still use a 32-bit address space. Each byte in your computer memory has an address. With a 32-bit machine, this stores an address as a 32-bit integer. This means that the maximum address you can get is 4294967295. This means you can only store up to 4294967295 bytes of information in your computer at any one time (ignoring and HDD or SDDs you may have, since they need loading into RAM first, usually), and this gives you 4GB of available memory. Not matter how much more you put in, you can never get any more out of it unless you upgrade to a 64-bit machine.

In short, you'll want to try and make sure your game can run with less than 4GB of RAM at any one time. This shouldn't be a problem, but it's something to consider.

[Phaze]

Wanting it to run on "anything" isn't always the best idea, either. It may end up just being a waste of your precious time; and hurt end users with better setups. The average pc or laptop today has a dual core with some sort of video chip/card and at least 3-4gb of RAM. Keep that in mind. It also depends on your audience!

Details, details.

Well I certainly don't intend to let up when it comes to advanced features but I'd really want to make sure that you don't need a stupidly overpowered rig to run it, via the possibility to turn the fancier stuff off. Heck, I doubt it'd even be that hard to run with the effects since it's not really 3D. I've constantly been hearing from friends with pathetically underpowered systems that they're unable to run a ton of games, which is silly.

To be honest, I don't end up doing a whole lot valuable with my time, though I understand your concerns. To be spending a lot of time working on something productive in some fashion is better than my current state where I don't really do much.

-architectures-

However, what you said has some merit, in that you shouldn't just go for the top-end computer, since that will exclude your audience. Also, keep in mind that most machines WILL NOT HAVE more than 4GB of RAM.
-addressing-

In short, you'll want to try and make sure your game can run with less than 4GB of RAM at any one time. This shouldn't be a problem, but it's something to consider.

Well I should've been more specific, but I was referring to 'anything' in the x86 or x86-64 range. I'd like to try to make something that can run on lower-spec machines. I'm not sure if I'd go about with more exotic architectures because the benefit per effort may not be worth it.

Yeah I know how addressing systems work and I highly doubt my game would come close to exceeding even 1GB. The only things that even approach that level of memory consumption are the 'sandbox' type games like Minecraft/Terraria or the seriously heavy duty games like Team Fortress 2. My game would be top-down 2D with (hopefully) some fancy stuff like shadows, as mentioned above - though it could probably be a generic dark overlay if the system can't support shadows.

[Hoeloe]

Yeah I know how addressing systems work and I highly doubt my game would come close to exceeding even 1GB. The only things that even approach that level of memory consumption are the 'sandbox' type games like Minecraft/Terraria or the seriously heavy duty games like Team Fortress 2. My game would be top-down 2D with (hopefully) some fancy stuff like shadows, as mentioned above - though it could probably be a generic dark overlay if the system can't support shadows.

That's not necessarily the case, especially if you're working in C++. Your game may not need more than 1GB at any one time (which is probably true, since I've made a 2D engine that barely uses more than 1MB at any one time), however, keep in mind that C++ does not have built in garbage collection. The reason Minecraft crashes a lot is because of Java's flawed GC, and from Notch's careless code, which causes memory leaks and eventually the system to run out of stack memory and crash.

Without a GC, your game may only be using 1GB at a time, but will keep everything it had used previously in memory anyway. This means that after a short while (and if you're using 1GB, probably only a few minutes), your game will toss you a stack overflow error, and crash. You'll need to find a library with a decent GC (which most will have), or implement it yourself. Don't make the mistake of assuming that just because it's in 2D, it will never use all your memory. Memory leaks are a horrible thing, and can make even the smallest game horrendous if not dealt with.

I managed to keep a 2D engine at around the 1-2MB mark on menus, pushing up to 3-5MB in game, by paying close attention to what my resources were doing, and ensuring I disposed of them when they weren't being used. The language I was using (C#) did have a built in garbage collection system, but I ensured it could do what I needed it to, by deallocating unused resources, and at every screen transition, manually calling it, to clean them up. This way, I only have what is absolutely necessary in memory at any one time.

Basically, be warned that, especially if you want to keep this working with older x86 models, you'll need to do careful memory management.

[Phaze]

-memory management-

Yes, I am well aware of this too along with the fact that Garbage Collection is a thing that Java has that C/C++ doesn't. I know that if you just keep new/malloc-ing stuff the game's memory usage will eventually spiral out of control, then it can't allocate any more and - crash! Naturally, stuff that is no longer being used needs to be properly freed/deleted, not only to keep the program running but in order to keep it from needlessly chomping down on memory (and possibly even CPU cycles, though obv. this isn't strictly related to memory management) that other programs would probably like to use. I notice that a lot of people, when they develop programs, they simply attempt to throw more resources at the problem instead of actually fixing the underlying problem - or heck, actually seeing it coming and planning accordingly.

I'm by no means an expert but I have made programs in C before, so I do have experience with regards to memory allocation and dancing around arrays and pointers in general, though I realize C++ does handle things a little differently and I need to research the language properly as a result in order to get the best use out of it, since a lot of handy abstractions that Java provides are missing at this point.

There's also the fact that even with Java's GC it's easily possible to run out of memory if you're a clueless ditz and keep endlessly creating Objects and maintain references to them - score 1 for leaky abstractions, eh

Honestly though, despite the potential risk for memory leaks I'll probably go about managing allocated memory, myself.

[coty-crg]

When I have to deal with stuff like that, I always keep a notebook handy. On bigger projects, I mean. I make this big chicken scratch of circles and squares to keep track of what calls what, when what is destroyed, etc. On really big projects (or something like a zelda-clone, like we discussed earlier), this is something you'd really really have to watch for.

[Phaze]

When I have to deal with stuff like that, I always keep a notebook handy. On bigger projects, I mean. I make this big chicken scratch of circles and squares to keep track of what calls what, when what is destroyed, etc. On really big projects (or something like a zelda-clone, like we discussed earlier), this is something you'd really really have to watch for.

Yeah I'm actually gonna be doing something Zelda, myself. Could've just gone for doing it in Java for ease of coding but I want to do it in a lower-level language since I intend to use said lower-level language in my major projects - better to learn now than later, eh?

Sounds useful, but knowing me I'll throw away the notebook 2 days into the project or something

On an unrelated note, I'm only really learning about trig functions (not to mention their use in gamedev for transforming co-ordinates) now. Fun stuff, I don't remember my maths teacher(s) being useful regarding this; the only thing I learned from one of them was a dumb acronym, SOH CAH TOA and that wasn't even really something of his own!

[coty-crg]

When I have to deal with stuff like that, I always keep a notebook handy. On bigger projects, I mean. I make this big chicken scratch of circles and squares to keep track of what calls what, when what is destroyed, etc. On really big projects (or something like a zelda-clone, like we discussed earlier), this is something you'd really really have to watch for.

Yeah I'm actually gonna be doing something Zelda, myself. Could've just gone for doing it in Java for ease of coding but I want to do it in a lower-level language since I intend to use said lower-level language in my major projects - better to learn now than later, eh?

Sounds useful, but knowing me I'll throw away the notebook 2 days into the project or something

On an unrelated note, I'm only really learning about trig functions (not to mention their use in gamedev for transforming co-ordinates) now. Fun stuff, I don't remember my maths teacher(s) being useful regarding this; the only thing I learned from one of them was a dumb acronym, SOH CAH TOA and that wasn't even really something of his own!

I totally understand. Highschool student, right?

I didn't learn crap from my math teachers until Calculus in college. Even my calc teacher in highschool was useless.

Oh well! Although honestly; now that I'm at this university I'm doing more research on my own than I do in class.