How We Make High-Quality Maintainable Code for Educational Games

The core of what we do is making educational games and simulations for clients. Often those clients either do not have a development team or they do have a development team but their team doesn’t make games. When our clients engage us for a project, we know that our software has to be built to run not only now but in the future.  Filament’s engineering team follows a number of standard practices to maximize the extensibility and minimize the technical debt to create high quality code. Some of the key practices include:

• Separating data and presentation: In traditional application design, this could be considered a variation on separating model from view, but this the more generic idea that data should live separately from the user interface and scene so that it can be easily updated and modified, and potentially driven by remote sources. Filament has tools to load content from CSV/Excel and JSON formats that all of our teams are trained on.
• Enabling non-engineers to test: We write our code so that it can be tested against the acceptance criteria written in the user stories by a non-developer, both QA for functional testing and designers for user acceptance testing. By allowing these stakeholders to test at the sprint and story level, it’s more likely they will uncover cases that the engineer did not envision, with time to correct.
• Knowing our tools: We try to limit the numbers of frameworks and tools that we use so that we can be deeply familiar with the ones we do use across the studio. If we know our tools well (for example Unity), it’s less likely that we will be tempted to write an inner-platform, or repeat ourselves by writing functions that already exist in the .NET or Unity APIs as well as adhere to conventions and common practices in the community of developers surrounding that tool or platform.
• Writing loosely coupled components: Codebases become unmaintainable when refactoring one component requires refactoring many seemingly unrelated components due to coupling. Decoupling techniques include depending on interfaces instead of concrete implementations and event and callback-based indirection. We heavily use both approaches when implementing gameplay systems. These techniques are also sometimes referred to as inversion of control.
• Using the wisdom of the team: We have a staff of 10 full-time engineers and 3 technical managers with different specialties. Each project goes through an architectural review at the outset where the lead engineer presents to other members of the engineering team to get feedback on the architecture of key systems. At this point, we also identify certain systems that should be implemented by a specific engineer who has expertise in that area and is more likely to avoid common mistakes that will generate technical debt.

If you want to learn more about how our process can work for you, we’d love to connect. Contact us here!