In these first two weeks, I clocked in 42 hours of total work (even though I'm busy full-time during the day) and made an amazing amount of progress in a very short timeframe. I started off by doing a lot of brainstorming about what the game is supposed to be, and most importantly, defining the scope of the project. This is a critical phase that, in my opinion, can make or break an indie game. Seriously. If the scope is too big, then you'll never get it done. If the scope is too small, then it will most likely be a very simple game that most people won't want to pay for.
Secondly, I took care of all the project management aspect. This is often overlooked by aspiring game devs, but it's another critical part of the initial development phase. Making clear deadlines, defining what each "phase" of the project will look like and estimating how much work is required to complete these phases. These are the main goals/phases I defined for Tokyo Tycoon:
Nov-Dec '22 - Complete the MVP (Minimum-Viable Product)
This means having a game with all the basic features it needs, in order to be good enough to start marketing. It doesn't have to be polished, but it needs to do everything it's supposed to. Testing phase starts here.
Jan-Feb '22 - Finish the demo and publish it on Steam
For the demo, the game has to be polished. It has to work well, have only a few minor bugs. Don't publish buggy software. The only thing it's lacking, is content. For the demo, I intend only to have 2/4 main heroines, and 3/12 dating spots. This will limit the scope and allow me to publish a demo quickly.
May-Jul '22: Publish the game
Finish making the content for the game, add extra polish and bugfixes. Finally, publish it on Steam.
Aside of this, I organized all the tasks for each week using Trello. It's a very useful tool for managing your projects. Go and use it!
That's right. Coding right off the bat without any planning, is the game development equivalent of jumping off a cliff. Without a parachute.
First of all: Define all the objects your game needs. What entities are there? Players? Enemies? Power-ups? Locations? Anything in your game that can be represented with a noun, is probably an entity.
What behaviors should each entity have? Can a Player jump? Can an Enemy shoot? Can a PowerUp be consumed? Anything your objects are supposed to do, is probably a behavior.
We don't care about HOW these entities execute their behaviors. All we care about, is defining them, in order to get a good idea of the structure of the game, and how the pieces will interact with each other. In Object-Oriented Programming, which is what we do in Unity using C#, there's something called a Class Diagram. You should make a simple one before writing any code, in order to make your development a lot easier in the future.
It took me about 4 hours to finish my basic class diagram for the game. But it has probably saved me dozens of hours of debugging and refactoring code in the future.
After all the groundwork was done, I set up a GitHub repo and created the Unity project. I made a basic main Unity scene for the game, namely, what players will be looking at "most of the time" while playing. Other than that, I began writing the skeletons of all the C# scripts for the entities (AKA Game Objects).
After the coding setup. I finally began developing the game. Making the UI, adding listeners to the buttons in the UI, adding the essential backend code for all the objects. At this point, I realized something important. Making a complex Dialogue System is a lot of work. What's a Dialogue System? Well, something that handles all the dialogues in the game. When do the dialogues get triggered? What lines get played and by who are the people speaking the lines? All this is insanely complex, and I think most games with characters absolutely need some sort of system to handle all these variables in an easy manner.
If making some sort of system for your game, say, a Dialogue System, or a Physics Engine, or whatever, could take you dozens, if not HUNDREDS of hours of coding, then don't code them. It's a total waste of time. Find some solution online that you can adapt to your game, and use it. What if it costs money? Chances are, it's a good idea to buy it. You heard me right. If the "solution" costs $100, but it saves you hundreds of hours of development, then it's really darn worth it! In other words: Stand on the shoulders of giants. Don't reinvent the wheel.
So, I decided to search for various dialogue systems for my game. I tried implementing a simple system using a YouTube tutorial, but it didn't really work out. It was too basic for the kind of game I'm making. I needed something really flexible, which allows not just a Visual Novel mode, but also an "adventure" mode where you can have dialogues trigger in-game, and then continue with regular gameplay. Finally, I found my solution. NaniNovel, a Visual Novel engine. Most people use it for making Visual Novels, but technically it's a complete dialogue system that can be adapted to any sort of game. It cost me $150 USD, but it saved me endless hours of development. With NaniNovel, I can just focus on writing the dialogues themselves. You import all the resources (BGM, sprites, etc.) into the engine, and things just work.
So, this is a summary of my two first weeks of developing Tokyo Tycoon. I hope this post inspires you and gives you an idea of how to start developing your own game. The most important advice I can give you, is: Don't wait. Keep developing, keep improving, keep doing stuff. Little by little, you'll have a wonderful, finished game, and TONS of experience from all the challenges you overcome along the way.
And so, I embarked on my quest to make the best dating sim/real estate management/visual novel the world has ever seen!
Stay tuned for more updates! Follow me on Twitter @HanaGamesEN
© 2022 Hana Games. All rights reserved.