Monday, March 28, 2016

Making games as a single developer (pt. 2)

Before I continue my rant about how everything was better in the olden days.. err about creating a completed computer game as only one person. I want to take a moment to define a few concepts as I see them in relation to games created by only one developer. The concepts that require refinement, are in no particular order; complete, game, successful and good. Starting with successful, you usually think of a game as being successful if you and your friends have heard about it, it sold well for its time or some other less obvious metric. Those metrics will not work well for you if you apply them to your own one-man games. Surely, there are several examples of games made by a single developer that fit those criteria, but for each of those, there will be hundreds that do not. So, unless you can reasonably expect to create the next Minecraft, I offer a another, and softer definition of success, which I believe work well for the hobby developer. Success is when your game is picked up by others, when it is distributed by magazines, mentioned on blogs and forums and, if it is open-source, is included in third-party or official software repositories for popular and less well-known Linux distributions. Further criteria are mentions/pages on wikis or archive sites such as moby games, is being ported to new platforms by other people without your knowing or consent, or is being distributed by a platform such as portableapps. I realize that a single developer could achieve some of these things by themselves, but if other people are doing it, it shows that others like your creation enough to do work to spread it, and in my opinion that is a great honor. I must admit that these criteria comes from how my own games have fared, I've not put a large amount of work into spreading the word myself, and I've been so greatly positively surprised when I Google my stuff and find it spread throughout the Internet, for me, personally, that is a great motivation to try to do good stuff which brings me to the next definition that I would like to make; Good, what is it? It is highly subjective, and it is a requirement for any worthwhile game to be it. I've read a definition elsewhere with which I agree and shall repeat here. A game is good when it meets or surpasses the expectations of the player. Simple as that. If you're like me, the type who sometimes go to MC. Donald's, you know what I'm talking about. I'm so very rarely disappointed at Mc.D, not because the food is amazing, but because my expectations are usually met, a warm slob of fat, just like the last one I got, with the correct amount of ketchup, served fast and relatively inexpensive. Thanks. Expectations met, happy fat guy who will say, "the food was good" without meaning great. You can make the MC. Donald's burger of computer games, if you adjust not only your own but also your players expectations. You're trying to make something that feels finished, complete and, for what it is, good, which, in turn brings me to the last definition: Complete. When is something complete ? As a developer, and especially programmer, nothing is ever complete. Games are large enough that there will forever be something to improve upon, be it some algorithm which is less than elegant, a pixel that's definitely wrongly placed on a sprite, or the way difficulty increases. So again, with no other credentials than the wish to write something down, I give you a definition of done that I'm struggling to accept myself. A single-developer game is complete when there are no placeholders, no dead-ends and nothing missing from the menus. When you can start the game without knowing any of the command-line parameters, configure the game and have the settings be saved in a configuration file, have a way to store and retrieve progress so that the player does not have to start over each time, and when the game is long enough that anyone would actually want to be able to continue. This of course, depends on the type of game you're making, and the type of audience you're trying to entertain, but making load/save functionality is great fun, and shows that you've got at least some idea of the state of your game. Your game should not only start and exit flawlessly, it should be packaged in such a way that players can download and play it. That means that the game is either web-based and hosted somewhere, or that it can be downloaded for Linux and Windows without the need to compile from source-code. But a game is not really complete before users can add their own stuff to it, and change the existing stuff, if your game is loading levels from files, are those levels going to be created in a specialized tool ? If so, that tool will likely need the same rendering routines as your game, and it will need to be able to load the data the same way as your game, so, how would it be less than obvious to build the level-editor right into the game, design and implement it already from the beginning, with the idea that someone else is also going to see/use it, this way, you also get a nicer level-creation tool and a more enjoyable time creating levels yourself. The last thing I want to touch on, is game. To the purist, a game is a set of rules, or laws, under which the player must complete a specific task or set of tasks. To the holist, a game is the whole system. So, to make your own game, you first need to go to the beach and dig sand for the transistors you will use to build your CPU. Okay, that's taking it too far, let's skip the CPU architecture and also the operating system (if you're making a game on a platform which has one, which I'm going to assume). So, the game is the whole executable and all the linked libraries. It's the OpenGL library and audio driver, it's the joysticks, mice, keyboards and monitors, and it's also about defining entertaining rules and enforcing them in an entertaining manner, because, entertain. The reason I include the whole executable program in the definition of game, is that every choice is going to affect the finished product, the things that limit you will have you find alternative solutions, the things that are easy will have you sink way too much time into trying to come up with the right shade of pink for your invisible unicorn. To the player, the game is the executable they start up, the whole thing. Your players won't distinguish between the graphics library, your drawing routine or the reason behind there being entirely too little ammo on level 2. The experience is holistic, how files are handled will affect your decisions on level sizes and loading screens. The input latency will affect (along with the genre, and intended audience, surely) the tightness of the controls. Rendering methods will affect not only how the game looks to the player, but how moving and looking around "feels". In some games, such as Quake3, vsync on makes me feel "weird", and I always notice it, even if the game is stuck on 60 fps, it's just "weird".

With that rant out of the way, maybe next time, I will talk about my thoughts on creating a complete RTS game.
blog comments powered by Disqus