Make Games, Not Engines?

So, you've seen that piece of advice around the forums, have you read the blog from which the advice originates?

The topic came up earlier today in this thread. Inside you'll find a link to the original piece, my summary, and a follow-up from the original author.

The original article is a good read, unfortunately the title makes a good sound-bite, but doesn't fully convey the meaning of the article.

Quote:

Original post by Ravyne So, you've seen that piece of advice around the forums, have you read the blog from which the advice originates? The topic came up earlier today in this thread. Inside you'll find a link to the original piece, my summary, and a follow-up from the original author. The original article is a good read, unfortunately the title makes a good sound-bite, but doesn't fully convey the meaning of the article.

Actually, that exact thread is what spurred me to make my post in the first place. The blog entry and summary you mention don't really cover my questions, hence my original post.

In essence, I'm asking what the ideal means of developing tools along side a game would be, if you're not explicitly separating the non-game code into a library of some sort to be reused between them. Yes, it's possible to put the necessary code in each project, but then you run into synchronization issues when something changes in one and needs to be updated in the other(s) but is possibly overlooked.

"Write games not engines" is a warning against unnessessary complexity. If all you're doing is writing a simple game then you don't need an elaborate tools framework when writing simple collada loader (or finding a existing library) will do just fine.

Remember that it's unnessessary complexity we're trying to avoid - if you really, really do need a tool which shares code from the game then do so. But don't kid yourself that you need a massive dll-based plugin framework with lots of isolated modules in the name of building an "engine". Just moving the common code into a shared project will get you 99% of the gain for a fraction of the work, and it'll be easier to maintain too.

I, like many others, have seen that phrase thrown around here a lot. I just assumed by the context in which it's used that it means the entire point of your development should be the creation of a game, not-another-game-engine. That doesn't mean you can't still create an engine. It's meant for those people who hear all the rave about game engines and want to code one from scratch using OpenGL/DirectX and etc. so they can have an engine to create a game later. -Create the game now- and let the engine develop itself alongside for that specific game - don't think much about planning for future games. Which basically just means separate (abstract) the code as you go along ('x' belongs in folder Engine, 'y' belongs in folder Game, and 'z' belongs in folder 'Editor'). Just avoid any unnecessary work as usual but separate the code. You could keep the code together and create multiple project files as well - multiple DLL files, instead of one big one that way you have a choice for the game and editor. Anyway, it's possible you could use a game DLL along side your editor, but it would be a little messy.

That's just my 2 pennies.

My personal opinion on this one: make the game but think for the future.

Follow your game idea but think for reusability whenever possible. Split your project in engine side and game side. Put whatever is generic in engine side and game specific parts in game side (ex: menu system in engine side but some special menu pages in game side).

Not sure if this applies to you, but I personally enjoy making engines, not games. However, my recommendation is still that you make a game alongside the engine. Making the game is where you find out what your engine is missing, or where it is too hard to use, and it handles a large chunk of the bug testing. Even if your entire goal is to make an engine, I think making games on it is crucial. Even putting Tetris into your 3D engine (2D tetris, mind you) will likely lead you to find some places where your engine needs work.

Thanks for all the replies.

Unfortunately, most of them pretty well sum up the way I had been working on the project in the past and getting nowhere. While trying to make some game-specific part work, I found myself needing to write X non-game specific functionality, which in turn needed Y non-game specific functionality and so on until 99% of my time was spent writing "engine" stuff.

I suppose I'll just have to give it some more thought and try to sort things into a smoother order of implementation or something.

I've experienced the same. Particularly the problem with animations. No assets to test with = can't debug animation code = can't get any artists = can't get any assets to test with... That's the most annoying part of game development in general IMO. Would be awesome if some gamedev forumer with modeling skills would provide some free models to the community, that have animations, correct face ordering (so you can back-face cull when rendering), with correct normals and with good bump maps. The "asset problem" as I'll call it is what has taken most time and pleasure away from the rest of my game programming, but as you see the rest is so fun that I won't let it make me give up!

Asset problem? Ever heard of "programmers art"? That's where you just use anything you can find or make quickly and inaccurately. I can get a thousand assets from any game archive (Blizzard's MPQ for example, Bethesda's BSA) within a few hours. Fine if it's private and non-commercial. Replace them later.

You shouldn't have trouble developing an engine along side a game by the way, especially if you don't mind putting off compilation until both side's alterations are finished - back and forth. If you get hooked up on the engine 99% I can see a problem.

Quote:

Original post by Dae Asset problem? Ever heard of "programmers art"?

My programmer art' skills don't run to rigging and animating a character model - YMMV.

Quote:

I can get a thousand assets from any game archive (Blizzard's MPQ for example, Bethesda's BSA) within a few hours. Fine if it's private and non-commercial. Replace them later.

That doesn't help you on the recruitment front, as you can't demo the game with stolen assets.

Quote:

You shouldn't have trouble developing an engine along side a game by the way, especially if you don't mind putting off compilation until both side's alterations are finished - back and forth. If you get hooked up on the engine 99% I can see a problem.

I stopped making engines a while ago, to focus on a couple of games - do you know the result? 75% less code, and considerably more functionality. To be honest, most of the engine stuff people write never gets used, because by the time the game actually needs that feature, you find out it wasn't implemented quite right, and end up rewriting it.

Hello all.
Seems like multiple people here have the same issue. Not having a hard already made component to put into the engine to test. This being of course to see how things work and figure out what needs to be fixed and tweaked.

Well loads of great programmers and sucky ones want the same thing I think. Is there a way to form or set up a database where people can access and input that so lots of people can access it..

Kind of like a free goldmine with nothing fancy in it but enough to help people solve problems.

Quote:

Original post by Puncher Seems like multiple people here have the same issue. Not having a hard already made component to put into the engine to test. This being of course to see how things work and figure out what needs to be fixed and tweaked.

Not sure what you mean by 'hard already made component', but the only meaningful test of an engine is to write a game using it.

Quote:

Original post by swiftcoder My programmer art' skills don't run to rigging and animating a character model - YMMV.

Same thing here

Quote:

That doesn't help you on the recruitment front, as you can't demo the game with stolen assets.

Again, same thing

Hi,

Regarding asset problems, it can be easily solved.

- You can look out for simple tools which will help you develop those assets. I am using Wings3D for designing a 3D mesh and Milkshape to add animation parts. I even went as far as computing by hand vertex positions and face arrays for simpler meshes (50 faces max). Then you just need to be able to handle milkshape file format in your game.

- You can also use simple platonic solids for your game instead of advanced meshes (cubes, cylinders, spheres, cones). Paper and pen game prototyping often use tokens which have no relation with the final pieces that will be produced (pant buttons, cents, wooden cubes, ...). Then you won't lose time on tokens and will concentrate on gameplay.

- You can use animated sprites for your game instead of 3D meshes. You just design static meshes for your background and add sprites for your game characters. There are many tutorials and sprite templates you can use to derive your own sprite.

What is important is to know that asset development does take more time than developping a functional game. If you are alone, you will need to:
- create the game story
- create the level (a static mesh)
- create the level artwork (the texture for the mesh - perhaps with lighting baked in)
- create the menu artwork
- create the characters artwork
- create the music for the different parts of your game
- create the sound effects for different actions in your game

This will take you time unless you already have preexisting assets or go for the simplest route possible. For me:
- I concentrate on the game story (most important).
- I keep the level to a strict minimum (low poly static mesh with basic textures - or even no mesh for space based games).
- I reuse existing menu artwork or use simple colors.
- I create low poly static meshes for character artwork (there will always be time later for animation).
- I reuse free existing music for different parts of the game.
- I reuse free existing sound effects for different actions of the game.

Hope that helps.
Ghostly yours,
Red.

Quote:

Original post by sardak The biggest that I'm trying to get my head around is in regards to tool development. Perhaps I've just spoiled myself with having a separate, dynamically-linked engine that I could quickly whip up various tools and test applications with, but I'm not seeing how this would be possible if I were strictly writing the game itself. Does anyone have any suggestions for this?

How about keeping that separate, dynamically-linked engine for the tools?

Speaking about that, why are you working on a pet game engine that's still not ready? Can't you use that other engine instead, so you can get started on some games?

Quote:

Another problem I run into a lot, though not specifically related to this change in focus, is one of asset management. I seem to have a lot of trouble, for example, building an animation system without something to actually animate to test with. I have a few friends who are 3D modelers and such who have said they would be willing to help with the game, but without many of the tools, such as a model viewer and meta data editor, and of course various exporters/importers as necessary for their modeling environment of choice, they can't provide me with a whole lot, nor I them.

Why would you write custom tools for something that's already widely supported by modeling packages? They can create and view their models in their modeling tools of choice. You write some conversion tools to convert their output format into a format that your engine understands and go from there. Your friends only need viewers and tools if they want to see how their models will look in-game and if they need to add game-specific meta-data to them.

Quote:

I've toyed with a few custom exporters before, but the maya API is an absolute nightmare to work with, and that's the program of choice for one of the more prominent artist friends of mine.

How about simply writing an external conversion tool? It doesn't necessarily need to be a Maya plugin to work...

Quote:

While trying to make some game-specific part work, I found myself needing to write X non-game specific functionality, which in turn needed Y non-game specific functionality and so on until 99% of my time was spent writing "engine" stuff.

That might be an indication that you're doing too much on your own. What I mean is this: when you're building a house, you're not also going to bake your own bricks and chop down your own trees. You're buying those materials, perhaps even buying prefab walls and all that, because you need to construct a house, in a certain time-frame, with a certain budget.

The same goes for game-development. Your spare time is not unlimited. Neither is your motivation, and there are probably many other limitations you're working with. So, then, you should take an efficient approach. For many things, there are libraries available that already do what you need. Some may not fit your project very well, so there's some research involved in picking the best libraries for your purposes, but it often still beats writing your own - and ending up in a swamp of recursive functionality_n-needs-functionality_n+1.

Quote:

Original post by all_names_taken Quote: Original post by swiftcoder My programmer art' skills don't run to rigging and animating a character model - YMMV. Same thing here Quote: That doesn't help you on the recruitment front, as you can't demo the game with stolen assets. Again, same thing

These are indeed important issues - important enough to think them over before you start coding. After all, if you can't find a solution for this, you're essentially stuck with an invisible game framework.

There are indeed free models in various formats available, if you know where to look. It's also possible that a friend or someone else is willing to make a few test models. Still, I think it's best if you yourself possess these skills, simply because you can cater them to your own specific needs. I'm not speaking about beautiful art, only about modeling tool skills (hey, it's a bunch of moving triangles!).

If none of these is an option, then think long and hard before you continue, because how are you going to get art done for the actual game if you can't take this hurdle? Is creating a content-heavy game even a wise decision? Are there no alternatives that suit your situation and skills better?

Quote:

Original post by Captain P Still, I think it's best if you yourself possess these skills, simply because you can cater them to your own specific needs. I'm not speaking about beautiful art, only about modeling tool skills (hey, it's a bunch of moving triangles!).

I think this is quite important actually. If you're wanting to actually import animations into your game, you need to understand enough about the animation process that you should be able to create an animation in whatever tool you choose (be it Milkshape, Blender, or whatever)

It could just be a couple of bones attached to some cubes or cylinders or whatever. Doesn't matter. I don't see how you can expect to be able understand animation if you can't even create a simple one yourself...

Quote:

Original post by Captain P These are indeed important issues - important enough to think them over before you start coding. After all, if you can't find a solution for this, you're essentially stuck with an invisible game framework. There are indeed free models in various formats available, if you know where to look. It's also possible that a friend or someone else is willing to make a few test models. Still, I think it's best if you yourself possess these skills, simply because you can cater them to your own specific needs. I'm not speaking about beautiful art, only about modeling tool skills (hey, it's a bunch of moving triangles!). If none of these is an option, then think long and hard before you continue, because how are you going to get art done for the actual game if you can't take this hurdle? Is creating a content-heavy game even a wise decision? Are there no alternatives that suit your situation and skills better?

Yes, that's why I try to make as much as possible procedural, but the big problem is still that of animated characters, which simply can't be procedurally generated - or can they?

Quote:

Original post by all_names_taken Yes, that's why I try to make as much as possible procedural, but the big problem is still that of animated characters, which simply can't be procedurally generated - or can they?

Partially, look at the actors demos. Most people, except soldiers, won't stand still, and you can use e.g. Perlin noise to stimulate characters into small motions, like tilting the head. But procedurality also has limits, as Doc Mojo hisself said once.

Quote:

Original post by all_names_taken Yes, that's why I try to make as much as possible procedural, but the big problem is still that of animated characters, which simply can't be procedurally generated - or can they?

That's probably possible, but it looks like it'll take a lot of research to get right. I think it's easier to learn how to animate well than it is to create an animation generating tool that actually produces nice results.

So the point in your case is, is it doable to create a game with (many) animated characters? Maybe you need to tune down the number of characters, or the number of animations, or both. Or go for a solution that doesn't need such animations, like a different art style.


My main point was, however, that you need to think about this beforehand. If you're a great programmer who's horrible at painting, you shouldn't pick artistic quality as the selling point for your game. You should pick an abstract art style that benefits from procedurally generated content, or something else where you can make the most of your skills while not being hindered by your handicaps.

I happen to be both an artist and a programmer, having spent years in both areas. I can focus on art just as much as on programming, so having to create nice art and levels isn't going to be much of a problem for me. However, I don't have a lot of spare time, so I can't afford to spend too much time on anything. That's why I'm building a 2D rather than a 3D game, and why I'm using Ogre 3D and SDL for rendering and input, and why I'm using Python to prototype things I'm unfamiliar with. That's also why I've started building an in-game editor; to be able to create levels as quickly as possible and to reuse the code for the game itself. I'm also writing down the requirements and design for my game, so I always have a clear goal. Working without a goal leads to wasting time, and that's just not an option for me.

So, make the most of your strong points and try not to let your weak points become a stumbling block. Also, don't just start coding right away. Make a plan and prepare to finish what you start, don't just think you can deal with things when they come up.

[Edited by - Captain P on February 2, 2009 9:29:33 AM]