Relevant VE2 documentation is linked at the bottom of this page

<aside> 🎓 If you’re attending this course through the Graduate school, this page contains the contents of the third & final in-person lesson. It could act as a useful reference for you after the session, but please don’t go through the material before the session or you’ll be bored!

</aside>

<aside> ℹ️ This is the final lesson! If there are any exercises from previous lessons that haven’t been completed, go and finish those up!

</aside>

Software Engineering

When creating a game (or any piece of software) it’s crucial to be mindful of how each of your components are fitting together.

A general overview of the architecture of the game created in this course

Some key things to consider when putting together your system are as follows:

• Each script should have as few responsibilities as possible. In the same way that you should break up your methods so none are too big, we should also (when practical) break up our scripts so nothing is doing too much at once.
• Avoid having every script reference every other script! If every part of your system depends on every other part, changing one thing can end up breaking everything else!
• Whatever your architecture pattern is, keep it consistent! E.G if a script moves or imparts forces on an gameobject is attached to that gameobject, you should stick to that pattern for other scripts (e.g TargetController moves the target, BallController imparts force on the ball)

Testing

<aside> ⚠️ If you are not taking this course through the Graduate School and you want to test your built VE2 Plugin, get in contact with us! We can either set you up in the VR lab, or send you the installer for the end-user-facing VE2 application. Contact ftoveyan@ic.ac.uk

</aside>

A crucial element to game development (and software engineering, in general) is testing! You’ll have noticed that we’ve been testing incrementally as we go along, but it’s also crucial to have your game tested by other people! Much like getting someone else to proof read your essay, getting someone else to play your game will show you all kinds of things that you might overlook. When you’ve built the game, you’re going to be intimately familiar with what that game is expecting you to do. Where it’s expecting you to go, what the controls are, etc. What seems obvious to you, might not be obvious to others!

Some things to consider regarding testing

• Test early, and test often! If you make too many changes at once before testing them, and then find a problem during testing, you won’t know which change introduced that problem!
• Test the edge cases! Try to anticipate weird and unexpected things the player might do, don’t just test your game the way it’s “meant” to be played
• Test the build! Testing in the editor is quick and easy, but sometimes you’ll encounter problems that only present themselves in the built version!