Posted by Rampant Coyote on February 18, 2013
Today’s (and tomorrow’s) post comes from Chris “Random Gamer” Rovers, a long-time regular here in the Rampant Games community. An experienced developer in the “real world,” he’s got some lessons to share about picking the right tool to fit your game project (or vice versa). You can read part 2 here.
I’m one of those indie-developer-wanna-bes, though I’m hopeful that this time, for real, I’ve got a project I’ll push to release. There’s a lot of reasons why projects die (and I’m not going to get into all of them), but one of the big issues I had was trying to match the wrong project with the wrong game engine and the wrong game engine with the wrong art pipeline. So that’s what I’d like to talk about – some of the lessons I’ve learned, some of the engines I’ve explored, and some things to think about if you decide to go down this path.
The first big lesson, which I guess should have been obvious, is know yourself. Know what sort of developer you are. Professionally, I program in Java in a multi-million lines of code enterprise business application – my skills are primarily in data manipulation engines and the underlying guts of things. I’m not an artist nor a 3d modeller, though I can write descriptions and text reasonably well. I’m also not an interface guru. Those weaknesses aren’t a great thing in a one-person team, but they are where I am and many of the false-starts I made were from failing to match what I was trying to do with what I was good at.
The next lesson learned concerns art pipeline. If you’re a one person shop, you’re going to be doing your art end-to-end – from concept to execution to conversion to whatever format your engine is going to require. Yes, you can buy art, but unless you’ve got a significant budget, you’ll be doing lots yourself. That means at every stage, you need tools you can work with, that you can .be productive in. I have discovered that two of the most popular open source tools simply don’t work for me – GIMP (the open source image editor) and Blender (open source 3D modelling software) seem to work in ways that my brain does not. Several of my projects were going to require me to work with those tools and though many developers seem to be successful with them, it seems I’m not going to be one of them. Thus, my major lesson is that when you’re evaluating a game engine and choosing a game to make, make sure that you check out the pipelines that you’ll need to use and that everything works end to end in a way that you’re going to be happy doing over and over.
That brings us to game engines. Many of the game projects I’ve started (and the project I’m currently working on) are procedural in nature and I tried on several occasions to cram a procedural game into a game engine that expects designed and built levels. Don’t. Just don’t. Match the game engine to what you are doing. For me, I’ve found that I get frustrated by game engines that try to do too much, so less is more for me. Your preferences may vary, but there are so many game engines out there, you don’t need to compromise on this. Keep looking around till you find something that works for you and for the game you want to make. In the next part, I’ll give a quick run through of a few of the engines I’ve played with and the projects that started and ended with them. I’ll end with describing the engine and tools I’m using for the current project.
Filed Under: Game Development, Guest Posts - Comments: 6 Comments to Read