next »

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

Because I just posted this in another forum and argued about a similar topic here I think this would be an interesting topic: what do you think is better, game engines or pure programming?



The arguments for pure programming games in C++/C and similar hardcore languages come down to:

1. It's not a "real" game if it's made in a game engine.

2. Absolute control over what you create (except for the restrictions of the libraries and language itself, of course).

3. It's how the mainstream industry does it.

4. Games made in game engines look cookie-cutter and are easily recognized.



The arguments for using game engines come down to:

1. Game design and programming are not the same thing, and being good at one and poor at the other shouldn't stop you from making games.

2. The user doesn't care what your game is made in, as long as it works and is fun.

3. Although there are some performance and absolute control sacrifices to make, this is more than made up for by how fast and easy it is.

4. It's not really necessary to re-invent the wheel over and over by writing the same code that virtually every other game uses already anyway.



Anything else?  And what do you guys think?

[Alec]

Terminology:

I think by Game Engine you mean "Game Making Software" / Game Maker type stuff...

Game Engines can just be code that people write to make their games, i.e. C/C++ code.

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

Yeah, my terminology is off, I meant things like this: http://en.wikipedia.org/wiki/Category:Game_creation_software

But it's a blurry line.  There are things like Torque which are almost directly half-way between the two extremes. An analogy is how small the pieces are that you're using to make the game with; machine code and assembly uses really small pieces, too small to be usable for most people to pick up with a tweezer, MUGEN and RPG Maker XP use really big pieces, so clunky that they limit the type of game you can make.

[Bezzy]

I think you've got a pretty good rundown there.

The reason we made our own engine is because there wasn't any engine set up to deal with the kind of gameplay I wanted to make. Every assumption made in an engine narrows its scope - that's not to say that you can't make some wacky stuff in an FPS engine (RTS games, racing games, sports games, even chess has been made in various Quake engines), but quake wouldn't naturally allow for a vast open living world... not readily atleast.

I just think of engines as tools. You pick the right tool for the job. If the tool for the job doesn't exist, you make it.

[Anthony Flack]

I would say that, if your game idea fits comfortably within an existing format, then take the path of least resistance and use that tool.

I would say that, except that in practice you will always end up adopting a few more standard conventions along the way than you signed on for, when you could have been forging your own path instead. Even if it's just little details like using a standard RPG interface instead of a slightly off-kilter one of your own design. The great thing about reinventing the wheel is that the new wheel comes out a little bit different.

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

Good reply, good reply.  But some of these game creation software are extremely flexible, they provide the cookie-cutter but they also allow you to bend it, so you can get the best of both words.  This isn't the case with, say, RPG Maker XP or the Ohrrpgce, but with, say, Torque or Game Maker you can (and in fact have to) create your own interface.

By re-inventing the wheel, I meant things like creating your own bitmapped font display routines, or your own particle effect engine, or your own system for handling collision detection and gravity, that kind of thing.  It's fun when those are done in new ways, but that stuff is sufficiently low-level that it's more productive to innovate the gameplay than to innovate that stuff.

[Bezzy]

By re-inventing the wheel, I meant things like creating your own bitmapped font display routines, or your own particle effect engine, or your own system for handling collision detection and gravity, that kind of thing.  It's fun when those are done in new ways, but that stuff is sufficiently low-level that it's more productive to innovate the gameplay than to innovate that stuff.

That's almost true, but what if you want to do clever methods of blending to textures, or normal mapping on the fly? You have to have efficient ways of dealing with textures on those terms.

I'm being a bit of a devil's advocate here, but every assumption in an engine, no matter how low level, limits expression in some way. Technically. Just saying.

[guille]

Good topic, it all really depends on what you want to do. I have used Multimedia Fusion for quite some years and I've also coded games in lame languages like Pascal or BASIC :D So I kinda know both sides of the story.

Game makers are good because they are easy to develop on; They are somewhat restricted; They are lame resource managers, at both, runtime and disk space.

Programming languages are good because code can be ported to other platforms easier; They are harder to learn and master; A good coder can get the most of the computer power with 'em, unlike game maker developers.

Always plan your idea beforehand, don't let the game maker limit your project!

I think a very good coder can make decent stuff using a game maker, and a mediocre coder can make awful games using C++.

If you were to put the best MMF/Gamemaker/whatever coder VS the best C++ coder the C++ coder would code a game that runs better and is smaller in size but would take much more time than the other coder.

So, sometimes it's just a matter of power VS development time. Some other times your game maker restrictions won't let you do what you want.

Quoting Carmack on a PS3 vs Xbox360 comparison: "...being 20% easier to develop on is much more important than being 20% more powerful."

As an example, my old computer can't run a low-res game like A Game With a Kitty (MMF) with a decent frame rate, yet it runs perfectly a high-res, multi-scrolling, action packed game like Anthony Flack's Paltypus -Retro64 version- (Blitz?). Blame it to the language, blame it to the coder.

In a nutshell, I think it's about the coder and not really the language or the tool you use. Although I can see coders benefiting from using game makers (fast prototyping) and game maker users from learning some coding.

I pity all the MMF coders that are so dependent on graphic elements to code almost anything... The tool shaped your minds!

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

That's almost true, but what if you want to do clever methods of blending to textures, or normal mapping on the fly?

This isn't something independent games normally innovate in, though.  Publisher-funded games that time to spend on that kind of thing, but with independent games, I don't really think a game could get done if it spent that much time on new ways of blending textures and normal mapping.  Is there even an independent game that *uses* normal mapping?

I'm not saying it can't or shouldn't be done, but it just doesn't make sense to me to be that concerned with graphical innovation when you're working on your own.

[siiseli]

I think game creation software restrict the guality of your games alot. I used to use them at some point but once I moved on to programming, the guality of my games went up by n^10

[pyabo]

Luckily it is possible to get the best of both worlds:

1) Use a "game maker" that is completely open source.  This way you have complete control, but take advantage of built-in features.  Torque falls into this category.

2) Create your own flexible framework/prototyping system.  Once you've created a game or three from scratch, you'll have pretty much anything a game-marker is going to give you... with the possible exception of very genre-specific kits like RPG Maker.

[BenH]

I enjoy using Game Maker because it allows me to get straight down to working on the game without any fuss. I used to try and do things the hard way with various programming languages, but it just wasn't for me. I've come to terms with that fact, and now I'm more than happy using software that allows me to get my ideas out as fast as possible. It definitely varies from person to person, and I don't think there is a correct answer for which is better or worse. Some people have the patience and programming skill to make full-blown game engines, others are just designers/artists wanting to experiment with a blank canvas.
I enjoy pushing Game Maker to its limits, and when you do that it doesn't necessarily  need to look 'cookie cutter' anymore. I don't think it really matters though, if its a good game, I'll play it. I don't really care what software it was made in, unless of course the software is actually hindering the game in some way (i.e too slow to run it properly), but other than that it really shouldn't make a difference.

[ZombiePixel]

Indies talk a good game about needing the flexibility and true ninja powah! of coding from scratch but it doesn't seem to ever play out in the real world.  From Gish, to Dwarf Fortress, to Mystery Case Files, to any of the Japanese shmups - I don't see anything so groundbreaking and revolutionary that it couldn't be approximated or outright duplicated in a different language or gamemaking system.  It's your call if you want to reinvent the wheel but at least be honest that it's about your ego as a coder and not about what's best for the game.

[Anthony Flack]

I don't really think it's a question of ego.

Sure, the end results may be pretty genric-looking from the outside, and you might feel that they could all be achieved more easily in a game-maker. But even in, say, a generic shooter, there are so many ways you can achieve the desired result and they all will impart a different flavour to your game. Maybe you want to generate attack patterns procedurally and then hand-pick the best seeds? Maybe you want to create a spline-based editor, or be able to define the attack patterns with mouse gestures? Perhaps there is some other programming trick that you would like to try out, just to see what would happen?

The other thing is, for a lot of programmers it's actually a lot easier to simply code up the thing they want, rather than try to figure out how to work the interface of some unfamiliar application. I know it took me a lot longer to learn the ins and outs of Photoshop than it did to learn the building blocks of programming.

I think that once you are experienced at programming and have built up a good set of your own libraries, it would seem that that's usually the most efficient way to work.

[PoV]

Engines, Middleware, and game makers/kits are great.  I would love to use them.  The problem for me is portability.  If I can't share code from the PC and go to the Mac, the Playstation 3, the Nintendo DS, or some new unreleased system/platform, then I'm missing opportunities.

That's why I use C++.

[Bezzy]

That's almost true, but what if you want to do clever methods of blending to textures, or normal mapping on the fly?

This isn't something independent games normally innovate in, though.  Publisher-funded games that time to spend on that kind of thing, but with independent games, I don't really think a game could get done if it spent that much time on new ways of blending textures and normal mapping.  Is there even an independent game that *uses* normal mapping?

I'm not saying it can't or shouldn't be done, but it just doesn't make sense to me to be that concerned with graphical innovation when you're working on your own.

Erm. In our case, yeah, it's pretty important. For gameplay, even. The game's sort of centered around a graphics hack. I understand the whole idea that very often, an approximation of a hihg tech game's gameplay can be made in even low-powered technology (the "Every game is pong", or "Gran Turismo is just Pole Position with more polygons" arguement), but I believe there are cases where you're going to have to have a base level of technology to pull off some gameplay paradigms (and arguably, different representations/fidelity change the overall experience of a game and zzzzzzzzzzzzzzzzzzzzzzz).

But we're completely an exception. I'm just saying - even if the exception wasn't there, it'd still be true.

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

But even in, say, a generic shooter, there are so many ways you can achieve the desired result and they all will impart a different flavour to your game. Maybe you want to generate attack patterns procedurally and then hand-pick the best seeds? Maybe you want to create a spline-based editor, or be able to define the attack patterns with mouse gestures? Perhaps there is some other programming trick that you would like to try out, just to see what would happen?

Actually you can do a lot of that in these engines too; the Game Maker game I'm currently working on uses procedural generation for many things; I don't hand-pick the random seeds, but you can do that in the engine. And I'm even working on a spline-based editor for the game, coincidentally (actually a "path" editor, but the Game Maker's path system uses splines, saving me a lot of work).

On the other hand, the game runs slower than it would in C++, I can't even get a solid 60fps in 1024x768 resolution on my computer in Game Maker, so I had to settle for 30fps, but I personally don't mind the sacrifice (particularly because the blurring effects I use make the 30fps not noticeable, at least to me).  I can see people not wanting to make that sacrifice, of course.