So it's the new year and I decided I should probably finally contribute something to this forum besides the occasional amusing rambling. As such here is a general guide to good development practices for the less experienced/untrained dev. Oh and in case anyone wonders why they should listen to this guide I have a degree in software development with a programming emphasis so yes I know what I'm talking about. Now onto the guide, yes it will be a little long winded.
Concept Development
Not my area of expertise but I do have 3 solid pieces of advice here:
1. Make the game you want to play.
This is something any good game dev will tell you. This brings passion to your work meaning the quality of your product and the odds of finishing it will increase. Search through the abandoned titles and you'll find examples of whiny first project devs who chose their concept elements just cause they were popular only to abandon their projects after a couple months cause they weren't getting the huge donations they felt they deserved.
2. Strive for originality but don't sweat it too much.
Having a unique product is great for setting you apart but as the old saying goes "there are no new ideas anymore, just new takes on existing ones". The idea that you're ever going to have a completely original product is a fantasy more elusive than even the most elaborate harem ending so just accept it's not gonna happen. Also keep in mind that just cause you're doing the same thing as someone else doesn't mean you won't do it better.
3. Once you have a concept you're happy with DO NOT JUMP STRAIGHT TO PRODUCTION, PLAN YOUR SHIT OUT.
This is a big problem with untrained devs cause they don't realize all the work that should be done before the first line of code is ever written cause they think "well I've got my idea and I've picked an engine so I'm good to go"; no you're not which leads us to the next topic.
Pre-development Planning
Yes this shit is boring, yes it's tedious, yes you should do it like your life depends on it because every minute you spend here will probably save you one or more later by eliminating indecision, questions, and arguments while making it easier to distribute work during actual development especially with larger teams that work on multiple parts of the title concurrently. A great example of why this is important is the long in development game Something Unlimited. I don't mean to mock what the Gunsmoke team has produced but if you've followed the game as long as many of us have it's clear until recently they just sort of played it by ear developing whatever elements of the game they felt like at the time with little forethought towards a complete project which led to things like having to adjust their menu system a half dozen times and lots of "this content is in develop" messages, some of which have been there for years.
So first things first ensure you have a complete story outline. Now it doesn't have to be everything at 100% because often times you'll decided to reorder events, change dialog, or possibly add/remove scenes for lots of reasons but having a complete scene list with basic descriptions for a full game from the start will cut down on the questions and/or indecision later on. This also makes it easier to map branching stories and generally makes it easier to do incremental releases.
Once you have the complete story outline you're gonna want to write down every single menu based element, ok not every cause you can skip combat subchoices like magic/skills, on individual notecards or something similar, grab a few random people outside the project, and have them assemble them the way they think flows best and get any additional feedback they might have. As dev's we have ideas on how things should flow but often times players have a different idea so getting third party input helps ensure the best possible gameplay. They also might have ideas you didn't think of which could improve the gameplay.
After your menus are planned out make sure you have a complete list of all the systems you want to use and all your variables. They don't have to be finalized names or anything like that but you always want to know these things in advance so you're not trying to make up new systems on the fly.
Finally pick your engine. I know this seems like something you probably would have picked earlier but if you have it's time to re-evaluate that choice. Odds are some elements of your gameplay have changed through the planning process so it's best to make a final decision here. Oh it's also worth noting that if you're working with a decent sized team while everyone else has been busy with this mind draining time suck the art guys have been able to work without constantly being hounded with torched and pitchforks meaning they likely have at least the preliminary artwork done for the first release or two; say thank you art guys.
Development Time
1. For the love of fuck use a proper number based versioning schema. There are plenty to choose from but to give you an idea if you're doing it wrong if it involves more than 2 letters or those letters a "ch" for chapter then you are. If you were thinking of using things like chapter, day, etjkshld, etc... it's simple to know where that info should be since it doesn't belong in version number. If you're using the same executable as previous releases then that info belongs in the change log and nowhere else. If you're using a different executable then you can put it in the title. NEVER SHOULD THAT SORT OF THING BE USED AS A VERSIONING SYSTEM. Personally I prefer the standard X.X.X.X system where the first digit refers to project completion, the second refers to major versions, the third refers to minor versions, and the last refers to development stage of that particular version ie alpha, beta, final. I would also suggest not using dates. Ya they work but given different parts of the world format dates different it can cause problems when dealing with an international user base.
2. Comment your damn code. NO BUTS, just do it. Yes this eats up some time but if you have multiple coders on a project, people leaving/joining a project, or have to stop working on a project for an extended period of time much like all that planning this will save more time then it eats.
3. Properly declare your variables. This means many things. In the case of Renpy as pointed out by the first comment below this means using proper defines, do not use $ statements inside of labels or they will not be defined when you load a game until it hits that label which it's defined. In the case of strongly typed (ie better languages than python) this means using the correct types for both intended use and variable size aka don't go using 64 bit ints when a 16 bit will do. This also means properly scoping your variables which kinda also falls under the next point.
4. Use proper object oriented coding practices. If you don't know what this is look it up. It will almost certainly save your ass lots of time especially if you're working with a properly made IDE that recognizes user made objects.
5. Do your best not to make alterations to the core gameplay once you've started. This is part of why you do all that pre-planning so as to make sure there isn't something you've failed to think of. If you do come up with something mid development weigh the benefits against the costs of reworking the entire game (including forcing your player base to start over) to support it. If it's not worth it then try to figure out a way to justify it within the context of the story like say the main character suddenly getting a new device/ability. If you can't do either of these things then just don't do it, save the idea for another title and move on.
6. Keep a change log and include it with each release. Given most of the titles on here are produced over months if not years it's important for people to know what's new in each release so they don't have to spend forever looking for the new content.
7. Don't go quality crazy. Seriously people use compressed formats for your images when possible, you can get file sizes way down without losing quality. Also don't use 1080p if you don't have to which I'll tell you right now 99% of the time you don't. Simple rule if you're not producing pixel level details at 1080p then there is very little to no difference between native 1080p and scaled 720p other than at least a third off your file sizes. In the case of video don't go over 1Mbps regardless of the codec you're using. Rarely is it worth it unless you're going full 4k. Also if you're not dealing with high speed action use 24 frames per second instead of 30. If that's good enough for Hollywood films, it's good enough for you.
Now for a few platform specific things.
8. If you're using Unity do not use the registry as a save file. Besides the fact this is just really really shitty development practice for any software that doesn't have an installer it also makes portability/backup virtually impossible for the average user.
9. If you're using RPGM make sure you're using the newest version you can get your hands on and if you're not using MV don't ship it with the rtp included. They're available as separate downloads and most people don't want to waste the space for it every time they download/install a game.
Well all that seems like a good enough start. I might add more later but right now I can't really think of any more basic general advice that doesn't get into the realm of project management and I'm not going there unless someone intends to pay me. Proof of point my PM teacher once told the class if we were ever having trouble sleeping to just read the class text because it's that dry and boring, the man was not exaggerating.
Concept Development
Not my area of expertise but I do have 3 solid pieces of advice here:
1. Make the game you want to play.
This is something any good game dev will tell you. This brings passion to your work meaning the quality of your product and the odds of finishing it will increase. Search through the abandoned titles and you'll find examples of whiny first project devs who chose their concept elements just cause they were popular only to abandon their projects after a couple months cause they weren't getting the huge donations they felt they deserved.
2. Strive for originality but don't sweat it too much.
Having a unique product is great for setting you apart but as the old saying goes "there are no new ideas anymore, just new takes on existing ones". The idea that you're ever going to have a completely original product is a fantasy more elusive than even the most elaborate harem ending so just accept it's not gonna happen. Also keep in mind that just cause you're doing the same thing as someone else doesn't mean you won't do it better.
3. Once you have a concept you're happy with DO NOT JUMP STRAIGHT TO PRODUCTION, PLAN YOUR SHIT OUT.
This is a big problem with untrained devs cause they don't realize all the work that should be done before the first line of code is ever written cause they think "well I've got my idea and I've picked an engine so I'm good to go"; no you're not which leads us to the next topic.
Pre-development Planning
Yes this shit is boring, yes it's tedious, yes you should do it like your life depends on it because every minute you spend here will probably save you one or more later by eliminating indecision, questions, and arguments while making it easier to distribute work during actual development especially with larger teams that work on multiple parts of the title concurrently. A great example of why this is important is the long in development game Something Unlimited. I don't mean to mock what the Gunsmoke team has produced but if you've followed the game as long as many of us have it's clear until recently they just sort of played it by ear developing whatever elements of the game they felt like at the time with little forethought towards a complete project which led to things like having to adjust their menu system a half dozen times and lots of "this content is in develop" messages, some of which have been there for years.
So first things first ensure you have a complete story outline. Now it doesn't have to be everything at 100% because often times you'll decided to reorder events, change dialog, or possibly add/remove scenes for lots of reasons but having a complete scene list with basic descriptions for a full game from the start will cut down on the questions and/or indecision later on. This also makes it easier to map branching stories and generally makes it easier to do incremental releases.
Once you have the complete story outline you're gonna want to write down every single menu based element, ok not every cause you can skip combat subchoices like magic/skills, on individual notecards or something similar, grab a few random people outside the project, and have them assemble them the way they think flows best and get any additional feedback they might have. As dev's we have ideas on how things should flow but often times players have a different idea so getting third party input helps ensure the best possible gameplay. They also might have ideas you didn't think of which could improve the gameplay.
After your menus are planned out make sure you have a complete list of all the systems you want to use and all your variables. They don't have to be finalized names or anything like that but you always want to know these things in advance so you're not trying to make up new systems on the fly.
Finally pick your engine. I know this seems like something you probably would have picked earlier but if you have it's time to re-evaluate that choice. Odds are some elements of your gameplay have changed through the planning process so it's best to make a final decision here. Oh it's also worth noting that if you're working with a decent sized team while everyone else has been busy with this mind draining time suck the art guys have been able to work without constantly being hounded with torched and pitchforks meaning they likely have at least the preliminary artwork done for the first release or two; say thank you art guys.
Development Time
1. For the love of fuck use a proper number based versioning schema. There are plenty to choose from but to give you an idea if you're doing it wrong if it involves more than 2 letters or those letters a "ch" for chapter then you are. If you were thinking of using things like chapter, day, etjkshld, etc... it's simple to know where that info should be since it doesn't belong in version number. If you're using the same executable as previous releases then that info belongs in the change log and nowhere else. If you're using a different executable then you can put it in the title. NEVER SHOULD THAT SORT OF THING BE USED AS A VERSIONING SYSTEM. Personally I prefer the standard X.X.X.X system where the first digit refers to project completion, the second refers to major versions, the third refers to minor versions, and the last refers to development stage of that particular version ie alpha, beta, final. I would also suggest not using dates. Ya they work but given different parts of the world format dates different it can cause problems when dealing with an international user base.
2. Comment your damn code. NO BUTS, just do it. Yes this eats up some time but if you have multiple coders on a project, people leaving/joining a project, or have to stop working on a project for an extended period of time much like all that planning this will save more time then it eats.
3. Properly declare your variables. This means many things. In the case of Renpy as pointed out by the first comment below this means using proper defines, do not use $ statements inside of labels or they will not be defined when you load a game until it hits that label which it's defined. In the case of strongly typed (ie better languages than python) this means using the correct types for both intended use and variable size aka don't go using 64 bit ints when a 16 bit will do. This also means properly scoping your variables which kinda also falls under the next point.
4. Use proper object oriented coding practices. If you don't know what this is look it up. It will almost certainly save your ass lots of time especially if you're working with a properly made IDE that recognizes user made objects.
5. Do your best not to make alterations to the core gameplay once you've started. This is part of why you do all that pre-planning so as to make sure there isn't something you've failed to think of. If you do come up with something mid development weigh the benefits against the costs of reworking the entire game (including forcing your player base to start over) to support it. If it's not worth it then try to figure out a way to justify it within the context of the story like say the main character suddenly getting a new device/ability. If you can't do either of these things then just don't do it, save the idea for another title and move on.
6. Keep a change log and include it with each release. Given most of the titles on here are produced over months if not years it's important for people to know what's new in each release so they don't have to spend forever looking for the new content.
7. Don't go quality crazy. Seriously people use compressed formats for your images when possible, you can get file sizes way down without losing quality. Also don't use 1080p if you don't have to which I'll tell you right now 99% of the time you don't. Simple rule if you're not producing pixel level details at 1080p then there is very little to no difference between native 1080p and scaled 720p other than at least a third off your file sizes. In the case of video don't go over 1Mbps regardless of the codec you're using. Rarely is it worth it unless you're going full 4k. Also if you're not dealing with high speed action use 24 frames per second instead of 30. If that's good enough for Hollywood films, it's good enough for you.
Now for a few platform specific things.
8. If you're using Unity do not use the registry as a save file. Besides the fact this is just really really shitty development practice for any software that doesn't have an installer it also makes portability/backup virtually impossible for the average user.
9. If you're using RPGM make sure you're using the newest version you can get your hands on and if you're not using MV don't ship it with the rtp included. They're available as separate downloads and most people don't want to waste the space for it every time they download/install a game.
Well all that seems like a good enough start. I might add more later but right now I can't really think of any more basic general advice that doesn't get into the realm of project management and I'm not going there unless someone intends to pay me. Proof of point my PM teacher once told the class if we were ever having trouble sleeping to just read the class text because it's that dry and boring, the man was not exaggerating.
