Throughout the many years of developing games I have learned so much through trial and error. Hopefully, I can pass my knowledge to the young and aspiring developers so their journey can be less rocky.
So you have decided to make a game. Great, the indie community is currently booming and we are looking for more entertainment. Perhaps you will create the next Dwarf Fortress or Flow, but you must take baby steps. Do not aim to create a game that will receive national praise, having positive expectations are great but you must face reality. Not too many indie games receive the recognition that their developers desire, this market is saturated with numerous unique games, you would have to one-up quite a few developers.
So you have a decent grasp on the DM language and you feel as if you are ready to create a game. A great ideology to start with is to create a game that you would enjoy playing. Trying to gather information on what the majority wants is not the best route to take. Nor is trying to select a specific sub-genre, such as an action role-playing game, and then create your game word-by-word based on its definition. It is your game, do what you deem as fun. If your game turns out to not fit the exact definition of the initial genre you were aiming for, so be it. If you still enjoy playing your game, you have accomplished one of the many goals in developing a game.
But before you open Dream Maker and start programming away you should first setup a design guide. This design guide is a rough generalization of your game; it does not need every single feature you plan on implementing. Throughout the course of development, you will make many important decisions which may differ from your original plan. This is why you need to design a structure in which you may refer to every time you encounter a significant decision. It is never good to stray too far off from your design guide; you will end up lost at some point.
Now that you have a design guide, you should settle on which libraries would best fit your project. I suggest this because your design guide may require systems that may be quite difficult to create. If a library does not provide you with the system needed, nor do you posses the knowledge to create it yourself, a change in your current design structure is needed. Imagine how devastating it would have been if you got moderately far in your project and became stuck on an unsolvable problem.
You have a design guide fleshed out, your core systems are in place, now you need a map in which you can test these systems out. While creating your initial map, you should not over-generalize; objects can always be added in the near future. The goal is to place objects on the map and test out the numerous systems you have implemented. Bear in mind, you are currently developing a game, it is most likely in the pre-alpha state. The public should not have access to your game, thus there is no need to create a detailed map.
So your game is ready to be tested. You must keep in mind that first impressions often have high merit when it comes to games. No one enjoys playing an incomplete broken game, nor will they be willing to try future releases if the first impression was terrible. If your game is ready to be tested: play it yourself, give it to your good friends, test the mechanics you have implemented thus far, see if the game is fun. Gather the feedback and change everything that needs to be changed. If you find yourself frequently spacing out and surfing the web while playing your game then you have not accomplished your goal of creating a fun game. Go back to the drawing boards.
Once the tedious and time demanding process of testing is over and the overall feedback amongst your friends have been positive, you can look into implementing the type of features that do not necessarily need to be in the initial release. But most importantly, if your game is ready for the public's eye, try polishing it up. People want to play a game that looks and feels as if it was produced by a professional team. A game that reeks of poor grammar, clumsy controls, inconsistent graphics, poorly drawn out maps, and broken game mechanics is a huge turn off. As I have said, first impressions are crucial!
Do not try everything on your own, BYOND offers a wide variety of talents ranging from pixel artists to composers. When you are in your polishing stage, try acquiring such talent. Remember, take your time! Unless there is a set deadline, take as much time as you can to develop your game. You may work on your game on-and-off for years, but it will be worth it once the finish product has been released. But if you were to take any message from this post, make it the goal of creating a game that you would enjoy playing.
ACWraith wrote:
I think the value of open testing is underestimated. There's a difference between letting people have access to a project and promoting it as a finished product. Only a few people are going to check a game out before it's marketed. If you can't overcome a portion of them having negative responses then you're already screwed. Take advantage of whatever feedback you can get. My suggestions were crafted from what I have experienced. In the past I have created small demonstrations, which were riddled with bugs, and allowed it to be accessible. Although many bugs were found, the demonstration left a lasting impression on those who tried it out. Along with that, I created a small thread which discussed my demonstrations' release, I certainly would not call it promoting it as a finished product though. Because BYOND essentially has a pre-made community for your games, it got out to the masses. Due to our community members being rather close to each other, the broken demonstration spread by word-of-mouth amongst each other. "Person A: Hey, is RJ's new game any good?" "Person B: No. It is riddled with bugs and is unfinished." "Person A: Alright, I will go try a different game." But you also must remember, continuously releasing broken demonstrations will continuously diminish the amount of testers you receive each time. If possible, gathering acquaintances/friends is sometimes the best route to take. Some of us actually prefer to play incomplete and broken games because suggestions can be made while the projects are still flexible. It's a developer community so we keep a certain mindset and hope we'll be so fortunate when testing our own work. Of course, my suggestions will not be appropriate for everyone. I only felt that it would apply to most, I could be wrong. Frankly, we don't all have good friends to help us. It is never too late to start making good friends! Heck, they do not have to be a good friend, just someone you have associated with and would be willing to provide honest feedback. |
Some of us actually prefer to play incomplete and broken games because suggestions can be made while the projects are still flexible. It's a developer community so we keep a certain mindset and hope we'll be so fortunate when testing our own work. Frankly, we don't all have good friends to help us.