Getting the Gameplay Working

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

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

88 εμφανίσεις

Chapter 15:


Getting the Gameplay
Working

Baki Can Öztepe

Hollywood movies vs Video Games


T
he largest unknown is “Where is the money coming from?”


Not
“How will we ever make this film?”


Hollywood has an
efficient system
for creating films.


Hollywood is making a predictable product.


The development of a game design is a chaotic and

unpredictable process


P
roblems not even the most experienced producer,
designer, or programmer can foresee
.

VS

Hollywood movies vs Video Games


shifting technology targets,



where programmers must learn about new consoles,


operating systems,


and 3D accelerator cards for each project


cutting
-
edge graphics engine


a truly original game
is far more
unique

compared to other
contemporary games than a movie is to other film
s


Civilization, The Sims
, or
Doom
. The gameplay contained in
these games was radically different from anything that came
before them.

Video Games


M
any games are far
less experimental and innovative




games that have followed more of a
formula

have had a
much
better success rate in terms of coming out on time
and on budget.



T
hough including
new content
consisting of new stories and
graphics, offer gameplay very much
the same as the
previous year’s offerings
(racing games)



When a game tries to implement a new form of gameplay,

all
hope of predictability is gone.

Prototyping & Experimentation


D
esigners do not have crystal balls
.


They

have an improved chance of anticipating what will
make for compelling gameplay. They
do not truly “know”
more than anyone else.



The closest thing game development has to a reliable
system for developing an original game is to get
some small
part of the gameplay working first
, before moving ahead to
build the rest of the game.

A prototype is crucial
.


This demo should be something any member of the development team can pick up,
play, and say, “Yes, this is fun, I want to play this.”


Should prototypes be shown to public and their opinion should be considered.
Kickstarter anyone?


Unsuccessful prototypes
-
> redirect
in a more promising direction or, in the worst cases,
aborted entirely.



Organic?


T
ry not to plan anything out beyond what is necessary at that
stage in development.
(
opposite of the approach many
development studios prefer
)


A

more organic process leaves room and time to
experiment


G
et some portion of the game to be fun before I start adding
detail and length to the game
.




Adding too much content

is

very wasteful



Excessive

detail
:

elaborate

design

document,

a

script

for

the

game’s

dialog,

detailed

maps

of

the

various

areas

players

will

explore,

or

even

fully

built

levels

for

the

game


Waterfall is dead, long live agile
!






Markus Persson




(creator of Minecraft )


http://www.youtube.com/watch?v=t0eqSgkDuW0

Agile

According to Kent Beck, the Agile Manifesto is based on twelve principles:


Customer satisfaction by rapid delivery of useful software


Welcome changing requirements, even late in development


Working software is delivered frequently (weeks rather than months)


Working software is the principal measure of progress


Sustainable development, able to maintain a constant pace


Close, daily cooperation between business people and developers


Face
-
to
-
face conversation is the best form of communication (co
-
location)


Projects are built around motivated individuals, who should be trusted


Continuous attention to technical excellence and good design


Simplicity

the art of maximizing the amount of work not done

is essential


Self
-
organizing teams


Regular adaptation to changing circumstances



W
ithout a prototype
there will be

assumptions about


how the gameplay will function,


A
ssumptions that may turn out to be incorrect once the gameplay is
actually functional


concentrate first on getting all of the gameplay working


F
ocus on making the gameplay fun before making a large number
of levels,
-
>
avoid a lot of extra work and waste effort.


S
tick to the initial design completely

-
>

the entire game suffer
s

and
the end product would
be not so fun.


Nothing proves to the financiers that your game is moving in the
right direction better than
a compelling prototype
.



Building the Game


The best way to build your game is incrementally.


C
omplete one system before moving on to the next


B
asic and essential systems first, and then build the systems that depend
on that system.


Programmers often enjoy working on their own isolated part of the code
without fully considering how it will have to interface with the rest of the
project
.

( These programmers only want their paychecks, not a headache )


C
onstantly focus on
the big picture of making the game playable and
fun.


Game Engine.


M
ake sure that this underlying technology functions at a
certain level before any work can be done on the gameplay


If the technology is simply not ready, start off prototyping
the
game using technology from a previous project.


It is rare that technology will actually make or break a game
design
though it may
make or break the game itself
.


Source engine

Quake engine

Gamebryo

Infinity Engine

Unity

Unreal Engine

Infinity Engine

Baldur's Gate

(1998)

Baldur's Gate: Tales of the Sword Coast

(1999)

Planescape: Torment

(1999)

Icewind Dale

(2000)

Icewind Dale: Heart of Winter

(2001)

Icewind Dale: Heart of Winter: Trials of the Luremaster

(2001)

Baldur's Gate II: Shadows of Amn

(2000)

Baldur's Gate II: Throne of Bhaal

(2001)

Konung: Legends of the North

(2000)

Icewind Dale II

(2002)

Konung 2: Blood of Titans

(2004)

Baldur's Gate: Enhanced Edition

(2012)

Baldur's Gate II: Enhanced Edition

(TBA)


Unity3D


U
sed to develop
video games

for web plugins, desktop platforms,
consoles

and mobile
devices, and is utilized by over one million developers.



Unity is primarily used to create
mobile

and
web

games, but can also deploy games to
consoles or the PC.



Incremental Steps


T
ry to break down the game design into the most
fundamental tasks that need to be accomplished


Throughout the project’s development it is important to
always
keep a version
-
of your game playable.


A Fully Functional Area (
one particular level of the game.
)


G
et one level as close to a final state
A
s possible before
moving on to the creation of other levels.


Early parts of the game need to be at the highest level of
quality possible


Difficulty
(
can be adjusted and tweaked later in the development process
)


Fundamental difficulty

Going Through Changes


B
eing able to throw away your own work and, potentially,
that of the rest of your team.


Destroy, Erase, Improve


A
rt, code, levels, and even general design itself


C
hange as gameplay evolves


Many developers are unwilling to do this, and it shows in
their games.


admitting that you have a problem


First impressions are very important, especially in game
design

Programming


A designer/programmer
are

able to have an idea for some
gameplay and then can instantly attempt to implement it
exactly how
they
want it


A designer who does not program is forced to first
communicate her idea for the gameplay to the
programmer


Often the communication will break down


T
here must be a constant circle of feedback between the
designer and the programmer.


The programmer assigned to set up
some
functionality
curses the designer
(
practically impossible task
)


Programmer
spends a lot of time on a challenging
implementation
.
(
simpler one would have satisfied the designer
)


Programming


Another problem arises when the designer and programmer
have different ideas of what the gameplay for the project
should be
.


P
rogrammer

can simply not implement what the designer
has requested
.


I
t is worth learning to program if you want to
be a designer
.


L
earning how to program will help teach you how to think
logically and abstractly



modern projects and fifty
-
person development teams, it is often difficult to be
both a designer and a programmer


have a lead programmer with a good sense of gameplay


When Is It Fun?


N
o book can ever explain

what is fun about a game
.


A

designer who is not actively working on the game during that period can
truly be considered to have designed it.


L
ead programmer is probably the one who is actually designing the game.

Game developers do their best
work when working on games they
care about and enjoy. The
excellent
Grim Fandango
appears
to be a perfect example.



it is very hard to design a good game that you yourself do not enjoy playing.