We’ve been working on a game. Here are some of the approaches we’re taking, and a collection of tips we’re picked up along the way.
Every Developer has a different background – We’ve all worked on different projects, in different studios, with different constraints and concerns.
Read everything you can, learn from it, change it, tear it up, change it, form your own opinion of it, discuss it with the author and others in your professional circles.
Ultimately, this is a list of opinions; Opinions backed by years of experience working the Interactive, VR, and Installation/OOH industry; But just opinions none the less.
UE4 vs Unity. Max vs Maya. JSON vs XML.
It. Doesn’t. Matter.
Learn the advantages and disadvantages and make informed decisions based on your specific skills and needs. Nothing makes you look more like an amateur than blanket statements that alienate massive parts of your industry because of your specific use case and personal bias.
When starting a new project, start by dividing the project up into its component systems.
Usually, it’s a grab bag of the following: Input, Output, Rendering, Audio, Lighting, Animation, UI, Scoring, Networking, Tools, Data.
Think of these systems as islands in a vast ocean, far from one another. Whenever they need to communicate with each other, consider how important the message is, and whether it really needs to be sent. The more isolated your islands, the better.
Take each system in your application and break it down into your specific needs. For instance:
Axis & Buttons
Events or Queries
Engine or Third Party
Decoration (PS4 Lights etc)
Make decisions about how you are going to handle each part of the system and wireframe your classes, so that you can see which classes contain what data and what functions. At this point look at your dependencies between classes and consider where classes are becoming too connected.