Technical Design document

Technical Overview:
1. Game concept
Summary of game concept from code perspective
The concept of the game is to have a crane loading containers onto a ship,
with the very real possibility of this going awry for example the containers
being badly placed or dropped, the ship being misbalanced and sinking
etc The game should be more focussed on being able to cause chaos
than being grounded in reality i.e. more crazy taxi than euro truck
simulator.
From a code perspective this means we have to create a platform of
connected objects that all transform together appropriately, that together
act as a pawn. We need to be able to generate and destroy many copies
of one or several objects that are designed so that they can easily enough
be indirectly manipulated by the user. We need an object acted on by
more than the basic physics that will be included in the engine we use, and
to research said physics so that they work correctly. Finally we need to
code and create an interface that allows the user to see their actions
quantified.
2. Technical goals
Brief/simple statement on the technical goals of the project
The technical aspects we want to achieve are for the crane to move
and respond to controls as smoothly as possible, and while how the
crates are picked up may not be realistic practically, for the crane and
container physics themselves to be fairly realistic. We would also like
for the ship to be able to accurately change its rotation or list
depending on how it has been loaded. This may be at a delay after it
has been sent off by the player to showcase disaster.
3. Technical risks
Brief/simple statement on the main technical risks to the project
The biggest risk technically for this project appears to be getting
everyone used to all the different software that will be used. We will
have to make sure that the time taken to learn how to use everything
effectively will not impede our progress on this project too much. A
secondary aspect of this is also to get the entire project to work
together smoothly and without problems.

For specific mechanics, I foresee that getting the ship to balance

depending on how it is loaded will be the most difficult, even without
worrying too much about water physics.
4. System requirements
Target Platform & Development Platforms
5. Third party tools
Engine, Middleware, Tools
We will be using the Unreal 4 engine if at all possible, with Unity being
a fall back option if this no longer becomes viable. For source control
we are using a private repository on Github. We are currently looking
into using an open-source library for water.

Research:
Background research:
Identifying and describing techniques, similar products, similar
features, etc.
Experimentation:
Details of any prototypes/code tests that were conducted processes,
procedures etc. that will inform production and implementation

Implementation:
How will features be implemented?
What game engine is being used? What middleware solutions are being used?
What impacts are there on production and testing? e.g. how to get a build in
peoples hands.
What features are required? What are desirable?
What is the overall (estimated) memory budget for art and sound? How will you track
memory?

Feature List:
//Breakdown each into smaller categories e.g. Crane movement, lifting/dropping,
transportation of containers, etc
1. Gameplay
Player input:
Aiming for controller/joystick input. Crane needs to extend/retract, rotate left and
right, raise and lower the magnet and also be able to turn the magnet on and off.
Finally there may need to be a button to send off the boat early depending on exactly

how later mechanics are implemented. This is not including any input needed for
various menus if any.
Controller: left analogue stick or d-pad for left/right and forward/back movement.
Probably use one of the pairs of shoulder buttons to raise or lower the magnet and
use the X/A (depending on controller) to active magnet. If interaction is needed to
send on the ship, it should probably be square/B.
Joystick: The 3 dimensions of movement should map to a joystick well enough,
although testing will be needed for this. The trigger will activate or deactivate the
magnet and an auxiliary button can be used for sending on the ship.

Player scoring:

Scoring could either potentially be based on tonnage shipped or by containers, most

likely the latter. Ships should require a minimum load with anything above gaining
score and anything below losing it. Bonus score may also be gained for timely
loading, or lost for incurring casualties or other damage. How exactly everything is
resolved will need to be decided by testing once the prototype has been developed
far enough.

Player Loss:

The player will have a set amount of lives i.e. how many ships that are allowed to
sink until the game ends. A life will be lost if the ship is destroyed, a by-product of
improper loading causing it to list and sink. It may also be possible to lose lives if not
enough cargo is loaded, otherwise the time attack aspect of the game would not
occur. Finally some combinations of cargo, yet to be decided, may have adverse
effects which may cause the loss of a player life. For example putting something
toxic next to a food container may just make that container lose points instead of
gain them, however if the player somehow manages to detonate a container full of
explosives, then a life would be loss. These are just theoretical examples and actual
cargo types are to be determined later.
2. Core mechanics

Crane mechanics:

The rope and the magnet will not directly be affected by player input,
instead be attached to the crane that is, and will thus be subject to
momentum and inertia even if the crane itself is not.
Magnet lifts containers on contact if activated.

Ship mechanics:

Ability to list or even sink if not loaded correctly

New ship will arrive and depart either at a set timer or on player trigger

Crate mechanics:

Generation / how they are brought onto the screen

Interactions between different types of crates yet to be determined

Gameplay mechanics:

Score calculated and possible life lost on ship departure

3. Graphics
4. Physics
Most of the physics required should be provided by the engine, however some
things will be needed or will have to be tweaked to accommodate gameplay.
These are as follows:
Realistic water is in no way required and even semi-realistic water is not
crucial to the game itself. However, the ships ability to float on the
water does need to be properly simulated.
The momentum of the rope holding the electromagnet may need to be
tampered with a bit to keep it swinging about longer when the crane
stops, especially if loaded with a container. This is to try and add some
chaos increased difficulty in accurately placing containers
The coefficient of friction on the containers should be increased to make
them a bit harder to slide about, although this will not save the player if
they stack containers perilously. The necessity for this will depend on
how exactly the loading of containers and requirements thereof is
implemented.
The Electromagnet just needs to be something that the containers will
stick to if it is on, and as such does not need to have real physics
implemented for this.
5. Coding standards

Schedule: