■ Look into these graphics engines and weigh up their benefits and
■ LWJGL 3
■ Look into the following approaches to audio & weigh up their benefits
■ Java Sound API
○ Game Engine/Logic/Integration
■ What are the quintessential programming patterns used in writing
■ Have a look at a few different types of game (platformer, bullet hell,
racing, strategy, etc.) – come up with a few examples of each and give
a brief description of the genre.
■ What protocols are generally used when writing games?
■ What is the difference between these protocols?
■ Look into the client-server model. What does it mean if the server is
○ (Game) AI
■ What are the differences between ‘mainstream AI’ and ‘game AI’?
■ Design and describe a simple AI for mario (high-level, pseudocode)
■ Look into the following application frameworks, and weigh up their
benefits and downsides
■ QT (and the Java bindings)
● I suggest that you have (roughly) one person on each, and MAKE SURE to keep each
section modular and independent of one another. This will save you all so much
time I promise!
● Make sure all of the code you write for each bit is modular! Each should work
independently of one another as much as possible – this makes your code much
cleaner, and easier to extend & modify.
● You should absolutely be using Git/GitHub flow as a model for your version control
(read: https://guides.github.com/introduction/flow/ and
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow ) –
I’ll go over this, but it’ll save you *loads* of hassle and time. This also allows whoever
is working on the game engine/integration to continuously integrate changes
that you make.
○ ‘master’ branch – stable & working – the stuff you’d be happy to present as
part of your final project.
○ ‘dev’ branch (branched off of ‘master’) – stable & working code, but perhaps
not fully integrated. This is where the integration will happen once features
○ other branches – these will be where each of you will be doing most of your
work – each one contains bits from a different aspect of your specific section.
You’ll each use feature branching when adding new stuff to these, and when
you have made enough progress such that specific parts are ready to
integrate into the full game, these will be pulled down onto dev ready for
○ The only branches that may contain unstable code or work in progress should
be the feature branches off of the other branches.
● Communication is key – make sure to be clear about everything you’re working on
with your teammates. Find out what’s required from you, and keep checking etc.
● If you’re struggling, don’t be afraid to chat to your team (or me) for help – everyone’s
learning, and it’s definitely a steep curve!