Computing Project VERSION THREEdocxx

wattlexanaduΛογισμικό & κατασκευή λογ/κού

31 Οκτ 2013 (πριν από 4 χρόνια και 7 μέρες)

91 εμφανίσεις

Computing Project

Project Planning and Approach


1.


Introduction

As a group the planning and approach of the project was decided as a team. Having a group of
five we split up the work between ourselves to be completed by the set deadline.

Each member of
group have had previous experience working on a similar project, so we all had an idea of the tasks
that would need to be completed along with an estimate on the time it would take.


1.1


Initial
Project
Plan

The overall project
consist
s

of
two documents
,

the design and technical document
, and

the
game demo. Planning began when the game idea was finalised by the group as a whole. For the
major deliverables
work would be split up between the team.
The plan was

to have three members
working on
the demo while the other two would work on the documents.

We would help each other
out if members were falling behind in work or struggling to have tasks completed.

Deadlines were
planned to ensure a constant flow of work as well as work being finished.


1.2

P
roject Planning Review

Though there was a plan to follow, problems would still come up which had the team deviate
from
the set plan.
During the initial weeks of the project the group worked slowly. We had a plan written
up for the upcoming weeks but it was

not followed and deadlines were being missed. This was due
to the lack of organisation within the group. The team did not set out tasks specifically during
meetings and did not look back on the plan that was crea
ted. Instead everyone decided on the day
wh
at they would do for the following week, which turned out to be less work than originally
planned. This set the group back
since the work planned was not completed and the tasks that were
completed were
just
minor

parts of the project that should have take
n less time to complete.



Another problem during development was the lack of communication outside of
group
meetings.

Parts of the deliverable were split amongst members; each would have a part to be completed for
the following week. Without communicat
ing with each other certain parts of the project could not
have

been completed.
An example of this would have been the communication between the
modeller and programmer. The programmer would need the models to use in the development of
the demo. Since the

programmer was unable to get the models certain parts of
the game demo
development were delayed.
This happened throughout most of the project until the team improved
on
communication.


From the first meeting the group as whole decided there would have be
en no need to have a project
leader to overlook the project. Instead we chose to work without project monitoring and control by
one person. It was up to each member to work themselves and approach other members if they
needed help or were working together
on parts of the project that related to each other. We were
all expected to hand in work during the weekly meetings and to meet deadlines.

In reality the group
started to fall behind in work since members were not completing tasks
and
as no one was
check
ing
each

member of the group to see if work was getting completed for the next meeting.

When team was organised, work was getting com
pleted

1.3

Overall
Approach

The team agreed it would be best to work as a democracy. This is not a traditional project
management approach, as it doesn’t rely on a project manager who will look over the team to
ensure everyone is doing work and to hand out tasks that need to be compl
eted. We would instead
all decide on what tasks need to be completed and when they will be due in for. By adopting this
approach it would be up to each individual to complete their task for the set date as there would be
no project leader to supervise work
. This approach allowed each member of the group to voice an
opinion of their own for what tasks need to be completed as well as tasks they would prefer to work
on instead of being delegated work by a project leader. Though this approach was chosen from t
he
beginning it did not work well initially which resulted in the group working at a slower pace.
Eventually the approach had to be changed in order to meet the project completion hand in date.

ELABORATE HOW APPROACH CHANGED.


1.3.1

Documents Approach

The docu
ments were split in two parts. The design and technical document would be made along
with the demo. Each member of the group has had experience completing these documents so we
were able to determine what was required in the documents. Knowing the document
s can be
completed relatively quickly the plan was to finish them off in a few weeks. The original plan was to
have two members take charge of each document and if they needed assistance they would ask the
remaining members for help. This approach would h
ave worked but by doing this it would have left
some members of the group with no tasks to complete. So it was decided it would be best if the
work was further split amongst the group to allow others to do work.


1.3.2

Creating Demo Approach

For the demo

the team understood it would be the more challenging and complex part of the
project. So it was decided more members would work on the demo than document. Three members
would work on the demo. Tasks were split up based on previous experience with programmi
ng and
modelling. No one in the group has had experience using the programming language JavaScript so
time had to be taken to learn the language and to become familiar with the chosen development
which resulted in a slow development during the initial wee
ks.



HOW APPROACH CHANGED.


1.3.3

Communication Approach

Communication was severely lacking during the early and midway stages of the project.
The team
thought communication would not of been important during development as we expected to able to
work on our
own tasks and have them handed in for deadlines. This was not true because members
did not complete the work set out or hand documents in for the set dates.

Due to missed deadlines,
other tasks were further pushed back as it was dependant on previous task
s to be successfully
completed.

If the group was communicating regularly
the status of each members work would have
been known which would allow adjustments made during the week, if members needed advice and
whether work was being completed at all. With d
eadlines being missed communication had to
improve.
The use of E
-
mails was used to send out tasks to the entire group as well as a development
website which would allow everyone to upload their work for everyone to see. The website would
also help with co
mmunication because members could easily chec
k up on what has been completed,
tasks that still need completed and the ability to ask for advice and help with certain parts of the
work. By communicating more work was beginning to be completed TBC.
















1.4

Reflection



Design of Deliverable


2.


Aims of Deliverable

To create a puzzle platforming game with Unity3D.


A game that would be marketable to the (whatever) audience for the (?!?!?) marketplace.

Easy to pick up and play game.

Fun Fun FUN.

2.1

Design

Approach


The first group meeting the group decided on a genre of game that everyone would be interested
and enjoy working on.

Looked into the current trend of games to see what games people are playing.

[Diagrams to show how the game marketplace is

split]


Brainstorm for a game idea that the group thought to have potential.

-
[Images of basic game idea]


Determined what development tool will be used. Unity3D?

-
explain why using Unity?


Designing the game

-
Researched game marketplace for influences and stuff.

-

[images of said games]