Zity has been in serious development for over a year now, but if I'm honest... I've been working on Zity for something more like two years. It started out as an idea and it went through several iterations before any sort of actual game was fleshed out. During those iterations a lot of trial and error, research, and improvements were made, and while these were all necessary at the time I would not want to repeat them again.
Some things to watch out for:
Often times as a game developer I overlook aspects of the game that I assume would be easy. They never are. In order to avoid the continuous cycle of overlooking something and then having to go back and alter everything I've had to really force myself to dig deep into the systems that make up Zity and make solid decisions on the game.
1. Choosing the tools
When figuring out what language and libraries to use for Zity I often couldn't make up my mind. I would stumble across sites that proclaimed the wondrous glory of C++ and SFML and how that was the only way to do things. Then other forums would say that you cannot beat C# and Monogame or Haxe or Unity. Choices... choices. I eventually chose Xna (Monogame now) because it was something I could understand and quickly dive into.
Choose what works for you, what you understand. Choose something that matches your team size (in my case a single person). Make sure that what you choose makes sense to you, something that won't take you months of reading books to understand. Sometimes easier is better, and sometimes flexibility can't be sacrificed.
2. Design before Create
When I initially started programming Zity I was focused on discovering all the things I could do. I had the ideas of procedural generation, cities and buildings, and RPG mechanics in my mind and I just went at it. I threw in as many new features and ideas as I could and very quickly came to a standstill. It was so packed with half-finished code and messy systems that there was no way to continue. You can read more about it here, but basically It took me several restarts before I finally slowed down and decided to DESIGN Zity instead of CREATE it.
What these means is that before spending any time on programming you should spend time designing. Come up with a plan for how the game should function and all the features you want. After that draw up some class diagrams or something similar for each system so you know how it works and how to implement it. Only then should you start putting your systems into practice.
Take this with a grain of salt, sometimes things can be added on the fly and depending on the scope of the game you may not need to flesh out every system but It's a good practice overall.
3. It doesn't have to be new, it has to be good.
This lesson I learned from someone dear to me. Far too often I would get discouraged in my efforts. It's hard not to look at games other people are creating and think how much better they are then your own. It's also hard not to look at similar games and find yourself measuring your game up to theirs. What I learned after a lot of discouragement was that it doesn't matter if something has been done before, you can still make something great. Often times the best games ARE unique and new but just as often you have games that are nothing new but are still incredibly fun.
The important thing is to make the game YOU want to play. If it's fun for you then it's definitely fun for other people in the world. When I work on Zity I am creating it for myself first, and for others second. But the reverse is true; If the game isn't fun for you, then it isn't going to be fun for other people.
Most importantly though, don't compare you're game. Every game is unique in it's feel, and it's gameplay so no matter how similar the ideas or how close the mechanics, every game is different.
No comments:
Post a Comment