Lessons Learned #3 : Design before Coding

Really spend time thinking about what you want your game to contain. Design a few levels, design a few sub systems, design as much as you can. Changing a design is infinitely easier than changing code.
Our team spent a month sitting down and designing before we ever touched code. We went over our Fact System (this will come in a later blog post), battle system, menus, etc and at the end pretty much had an overall vision of what we wanted to build. We took this vision and started to mock up potential screens, levels, and maps to see how the game would evolve. After that we took the common LEGO components and started to break those down and come up with the game engine that was going to handle all of our scenarios. It’s important to note that we didn’t cover all of the use cases that eventually made it into the game, but we did give ourselves a pretty good head start.

Lessons Learned #4 : Code before you get others involved

Before you start asking tons of people to join the team, beta test, create art, create music etc. have a working demo! It could be one level or one section or whatever. What you want to avoid here is having people join who are not interested in the type of game you are building. Once you have a working prototype, you can then use that to start bringing in the people to fill out the skills you are missing! You will waste a lot of money on someone who is half involved and the quality that they produce will not be as good as someone who has the passion and commitment to seeing the game through. 

Stay tuned for part 3!