Introduction
This document specifies the requirements for the first assignment of
the Mobile Game Development course. This assignment will develop
your skills by allowing you to put into practice what has been taught to
you in class during the first 5 weeks of the course. This assignment requires you to design, implement, test, and debug a
simple game using the LibGDX framework that will run on Android
phones. The work for this assignment is to be performed individually
and will be submitted via LearnOnline. If any parts of this specification appear unclear, please contact us for
clarification. Task Description
The style of game being made is an arcade-style game in the style of
Lunar Lander. The player controls a vehicle that constantly moves to
the right with a fixed camera, as with most side-scrolling arcade
games. The player can move a short distance forward (to the middle
of the screen) and a short distance back (to the left edge of the
screen). The player can shoot one short range shot (approximately
one third of the screen width) forward. Enemies can can from above
or in front. Enemies from above are flying which move across the top
of the screen; enemies from in front move towards the player can can
be shot. If an enemy hits the player they loose a life. If a bomb
dropped from the flying enemy hits the player they also loose a life. Main Features
Main Menu: when the game is launched a menu will appear with two
buttons - one marked "PLAY" to play the game, another marked
"EXIT" to return to the OS. The main menu’s background can be
coloured in or left black. This screen may have a name for the game
displayed as well. Game Screen: For the purposes of this assignment a game screen of
800 by 480 pixels is assumed. You will be given a series of
spritesheets for the protagonist and spritesheets for the enemies, with some bonus explosions, projectiles, bombs and backgrounds. Gameplay
Gameplay is relatively straightforward. The player is located on the
left side of the screen close to the bottom (note that this should be in
landscape). On starting the game, the player immediately starts
moving to the right, with the camera following the player such that
the player does not change position while the background scrolls past. While playing the player can move a shot distance forward or back by
increasing or decreasing their speed, but cannot go off the screen or
pass the middle of the screen. Periodically a flying or ground-based threat will appear. Ground-based threats appear from the right and move towards the
player; flying enemies appear at the top of the screen from either the
left or the right and move towards the other side where they go off
screen. The player shoots forward and can only hit the ground
enemy. Forward shots travel at most a third of the screen width. Shots can hit and kill ground-based threats. The player dies if hit by a
ground-based enemy or a bomb. When handling collisions, I'd rather you avoided using Box2D and
instead relied on the simpler overlap feature of a rectangle or
bounding box. Box2D is great, but we'll be covering it later in the
course. A demonstration video will be provided to show how the basic
gameplay should function. Fail State
If the player hits an enemy or bomb the player will die using a
provided animation and the player will stop. A button should appear
labelled "RESTART” which will reset the game again from the start
with the player at the far left side of the map. Assets
You will be provided with all of the assets required to make the main
features of the game. You must also ensure any new assets used are
either made by yourself or licensed under a permissive license for use
in an academic project. Use of public domain resources is
recommended. Also, just to keep things professional, make sure any
assets you add to the game are safe for work. Additional Features
For the last few features you have a choice of which features you
would like to add to complete the game:
A pause feature
Sounds
Looping background music
Unique graphical style
Second level (or more)
Jump action and associated threats (holes in the ground; rocks)
Variations in enemy movements and types
Each addition is worth a number of marks (see Marking Criteria for
details) and their combined total is more than the maximum number
of marks available for this part. The listed marks indicate a
high-standard of completion, where there is no visual clash with other
elements on-screen and manipulating any new controls does not
come at the cost of inconvenient movements on the player’s part. These new features may require some additional research by you to
implement as the course will not have covered all of these possibilities
yet. Basically this is a chance for you to show off and go above and
beyond what is expected of you. New features added are still subject to the requirement for your game
to run quickly and smoothly and so make sure you do not use an
excessive amount of memory or write poorly optimized code, either of
which could cause your game to hang or stutter. Descriptions of each
additional system are available below:
Sounds
Adding sound will give the game much more atmosphere. Ensure you
have a complete suite of effects including jumping, the player being
hit, as well as win/lose conditions. Remember to only use sounds you
have the rights to use, freesound.org is a good start, as is BFXR. Music
Adding a nice soundtrack can also improve the play experience. If you
do this make sure the song loops continuously. Finding appropriate
royalty free music can take some digging around, many people swear
by incompetech for their music needs. Unique Graphical Style
Instead of using the provided assets, you may choose to replace or
modify some or all of the assets to make them more striking and
unique. If you want to get the full marks for this feature, you must
ensure all of the assets added look like they’re part of a consistent art
style and they must all appear consistently scaled. Additional gameplay
This option is a little more vague than the others and will require some
additional creativity on your part. Essentially you add some sort of
progression to the game with additional mechanics. Code Quality
Docmentation
Use Javadoc-style documentation on methods and constructors. Documentation can be omitted for simple methods if their
functionality is obvious and they have no side-effects. Code
comments can be used sparingly, aim to comment blocks of code
rather than individual statements unless the outcomes of the
statements are not obvious. Code Style
You must write your code in a consistent style. Keep your style close
to Java guidelines and if you choose to deviate from it, please do so
consistently. Note that you are not specifically required to follow
Object-Oriented design, you merely need to make sure your code is
legible - however, you will find that a good object-based structure will
pay off. Version Control
You must use a git repository to track your implementation progress
and to keep a record of your work. You may choose to exclude the
majority of the project from being tracked to keep your file version
history compact and make it easier to switch between computers, but
you must at least include the source directory of the core module. If
you make any changes to the source in the android or desktop
modules then be sure they are included in version control as well. Submission Details
You must submit your complete Android Studio project folder in a
single zip archive file. The zip archive must include all source files and
asset files required to compile and run your project in both android
and desktop modes. The submitted archive must also include your
version control directory (there should be a .git/folder inside the
project), and a document outlining what features you have
implemented. Once you have created the zip file according to the specifications, you
are required to upload it to the Individual Assignment Submission link
via the course website on LearnOnline. The deadline for the
submission is on 11 April 2021, 11:59 PM. Marking Criteria
Criteria Mark
Main Features 45
Main menu with Play and Exit buttons 5
Control of player 10
Collision response 10
Animations 10
Fail and success states, including retry button 10
Stability 15
Android module stability without stuttering, errors or crashes 10
Code Quality 15
Documentation and commenting 5
Consistent and readable code style 5
Correct use of version control 5
Additional Features 30
Ability to pause the game 5
Sounds 5
Looping background music 5
Unique graphical style 5
Second level (or more) 10
Additional behaviours 10
Total possible marks 100