The Cycle

Hi all,

Due to work commitments, I am not going to be able to come in today, but that shouldn't be much of a problem. You are in a bugfix and polish phase now, and there is a pretty defined way that you should be working, so you don't need me much at all. The Cycle goes like this:

0. Look on the buglist and fix any bugs assigned to you.
1. Play the game
2. Find Bugs
3. Lodge Bugs
4. Goto 0

Step 0 actually can be broken out a bit. Firstly, it is tightly integrated with step 3 - Lodge bugs. You need to make sure that whatever system you are using to keep track of bugs has a way to assign these bugs to particular people, or at least a way for people to look through the list and take a bug that they think they could work on, and mark it as taken (so that other people don't start working on the same thing at the same time).

The other thing about step 0 is the way in which your changes (art, code, whatever) are integrated into the game. When this is done right, in a fluid manner, we call it continuous integration - the last thing you want is everyone to have to stop work and wait while Jimmy updates the codebase with Johnny's new title screen. The last thing anyone wants to hear is 'nobody do anything to sprites.py - Timmy is working on it!'.

Team B is doing it this way:

Andrew (P) has a subversion repository set up on his portable drive, and he has installed TortoiseSVN on his local computer. This gives him the ability to check things in and out of the repository, label 'snapshots' etc. He is the 'integrator' for the team. It is his responsibility to take whatever code/art changes people are making and put them into the game. Normally, everyone would have their own subversion checkouts, but since we could never get this working, we have to do it with a central person arbitrating all the changes. It's not ideal, but it will work.

So at the beginning of the lesson on a Friday, Andrew takes any work that has been done by people during the week and commits it to the repository, changing code to reference new art, or play nice with other new code, whatever. Once all that is done (hopefully in the first 10-20 mins of the lesson), he tags it in subversion as DEV_xxx (some development label). Once that has been done, he does an SVN Export of that tag, and this export is distributed to all members of the team to test, or work on (on a USB drive, whatever).

Every time there is some new code to fix a bug, someone comes to Andrew with their changes, and he integrates it into the release. By the end of the lesson, he has integrated a number of changes, and now he does another SVN tag = REL_xxx. This is a 'release' label. He does an export of the SVN release label onto the USB drives of his teammates, and they take this home to work on and test during the week.

The good thing about the labels/tags (same thing) is that anybody finding a bug should enter it into the teams bug database as being found on that particular label - so the bug might have a 'Found In' field. which would contain 'DEV_034' or 'REL_002'. That way, you know when it appeared, and it was fixed (yep, you need a 'Fixed In' field, too).

The reason we Export onto people's USB drives instead of SVN Checkout is because the rest of the team, other than the integrator, aren't using Subversion. Export will copy out all the files in Subversion, without all of Subversions metadata directories - '.svn' stuff. This is useful because when the team member fixes a bug, they simply hand Andrew their USB drive, and he drags and drops their file tree onto the checkout/working copy he has on the local machine. The updated files immediately show up as being changed, and there is no conflict of SVN metadata weirdness.

The only thing Andrew needs to be aware of is making sure he has updated and committed, BEFORE he drops someones changes onto his checkout. You do NOT want local changes in your working copy when you are dropping someone elses export in - if they have changed the same file as you, your changes would be overwritten. You want a nice, clean, working copy to drop changes onto. (i.e. There should be nothing but green ticks next to all the filenames/directories before you drop changes in).

These little gotchas are all because we don't have a central server - it is a lot less painful if you do have this type of setup. Still, doing it this way (with a central 'integrator'), is better than nothing.

Planning to Test

The only way to make sure software works correctly is to test it. But what do you test? What are you testing against? What criteria determines whether a test passes or fails? This is all part of the Test Plan. Each team's Test Lead is about to get busy.

You need to write a test plan. It is going to be the guideline for your team when they come to do test your game. There are lots of different ways to write these - we are going to keep ours simple. We pretty much want to generate a testing checklist for the team to run through when they test the game.

Starting Points:
In general, what assertions does the game design document (GDD) make that you need to verify in a test?

• e.g. "The player uses the arrow keys to move". Does this actually work? This probably ends up as a bullet point on the testing checklist: 'Verify that arrow keys move the player'
• e.g. "The counter counts down from 5:00 mins. When it reaches 0, the game ends". Does it actually count down from 5 minutes? Does the game end when it reaches 0?

The Test Lead makes a list of the 'assertions' in the GDD, and as specified by the team members also, when not covered by the GDD.

The Test Lead then defines simple processes to test each of these points. Sometimes this isn't so 'simple', and there is only so much that you can reproducibly test, but do what you can :).

• e.g. Run the game, verify that the title screen shows for 3 seconds.
• e.g. Verify that the player walking animation is shown when pressing right or left, but the jumping animation plays when pressing up.
• e.g. When the player collects a tomato, their score increases by 3.

The next part will be to define what happens once someone finds something wrong. A team member is running through the checklist and finds a defect. What do they do? How do they record it? How does it get fixed? How do we know it is fixed?

These questions and more, answered next time..

Sprite Resource

Here's some sprites (not just the one's pictured here) I've collected from the 'net for rapid prototyping. Give credit where it's due, if you use them commercially, or just use them without needing to acknowledge the author, for placeholders. It really helps getting the animation and collision code working as an example. It means Art can continue working on the final assets while the Coders have something to use without holding up production.

Click here to download -> Sprite Resource (6MB ZIP)

Game Design Document Template

Hi All,

We need your game design documents today! Put them in the following format, and fluffy kittens shall worship you. Dont worry about writing a huge tome of knowledge - a couple of lines on each heading is fine. Remember, this is going to evolve over the course of the semester.

Brad

Game Design Document

Generally the name of the game goes here somewhere.

Overall Design Summary
What sort of game is this (genre/format). What is the setting? What does the player do, and why (goal) .

Design
Here you describe the game design in more detail. This part is normally broken up into a bunch of different headings and sub headings. Some of the things you might want to cover are:
-The goal/object of the game - how does the player 'win'?
-How does the game flow? Do you have a main screen? Does the screen scroll? Does it transition to other scenes? Once you describe the game flow (feel free to use a diagram), you can break each of the 'sections' or 'screens' down into a seperate heading and describe it there. And so on and so on...
-How does the player interact with the game? How do they use the controls to manipulate what they are seeing?
-How is the game scored?
-Can the player die? How?

Artistic Overview
An overview of the game visual style. You can use pictures here, as well as describe how it will look.

Technical Overview
An overview of specific technologies used on the project - Platform, programming languages, frameworks, image formats, sound formats, and anything else relevant.

Game Parameters
Anything that is a sort of 'game constant'. For instance:
-number of lives
-gravity
-speed of movement
-amount of ammo you start with
(these are just examples).

IGDA Meeting 10th March

Hi All,

A quick note to let you know about the next IGDA meeting:

State of the industry

Time / Date: 7:00pm 'til late; Tuesday, 10th March, 2009 Location: The Velvet Lounge, 639 Beaufort St Mt Lawley (behind The Flying
Scotsman) Come and catch up with fellow game developers at our first meeting of the
year. The nights presentation will be by Nick Lowe and RJ Spencer on current
state of the industry and the skills available in Perth.

It's a licensed venue, so if you are under 18 you will need to sit this one out, or do your best to look 18 and sit in the corner and hope nobody notices you :).

The topic should be quite interesting - Rj and Nick (both soldiers from the very guts of Interzone) will be talking about the state of the games industry in Perth - where we want it to be, and how to get it there.

Hope to see you there.

The Game Loop

So here is a quick rundown of how a game might work. I guess at times I refer to a game skeleton or a 'game loop' - this is what I am referring to. The cycle that happens over and over again during a game's execution (often every frame!), and the things that need to be done in that cycle. It is obviously essential for programmers to understand this since they have to code it (or something like it), but I think it is important for everyone working on a games project to at least have an appreciation of just what is happening under the hood.

In the most basic of descriptions it would be:

1. initialise resources (screen, images/textures/sounds)
2. initialise game state (score, lives, all the entities (enemies, player, etc) )
3. while not ready to exit:
4. ....get input (keyboard/mouse)
5. ....test for collisions between entities
6. ....update all the entities positions/state
7. ....draw everything
8. clean up

Thats about it. Obviously some of the input (say, ESC key) or some game state (player ran out of lives) might cause the 'ready to exit' case to be true, and the game would end. You also need to fill in the blanks a bit with the 'test for collisions' step - obviously you arent interested in every little collision - just the ones that affect game state. Normally these are things like player/enemy, player/enemy_bullet, player/powerup. This generally means separating entities into groups, and testing for collisions between the groups that make sense - pygame has some neat data structures for this.

Another thing I am not really touching on here is timing. Some games (admittedly, these days it is not many) are written without any thought to how long each cycle (the part in the while loop - input, processing, and output/render). They just go as fast as they can. The problem with this is that people playing the game on different systems with different run speeds will have completely different play experiences. This is not desirable - it really undermines your game design. So what you have to do in these situations is have a clock timing how long it is taking to render each frame (the so called dt - normally in milliseconds), and do everything based on that.

For instance, instead of moving the spaceship 3 pixels every cycle or frame (which would have the ship moving at *vastly* different rates on different systems), we instead say that the ship moves at 100 pixels per second, so that each frame the ship moves (100*(dt/1000)) pixels. This means the ship moves at the same rate (more or less) on every system you run it on.

It sounds complex, but it's not.

The other nifty thing we will be doing comes when we want to 'update' all our entities. Essentially what we will do is make a base class in python for entities that has some useful methods, among them update() and draw(). Whenever we define a new type of entity (a bullet, a monster, a powerup, a zombie dinosaur), we will subclass from here (i.e. inherit from here) and override the functionality of update() and draw() to suit whatever entity we happen to be working on. The beauty of this is that we end up having our entities in some sort of list or group, and when we are ready to update or draw them, we just call entity.update() or entity.draw() on each element of the list, and each element then runs its custom update() method, depending on what it is. Inheritance comes in quite handy for games.

So our (slightly more advanced) game loop might be:

1. init resources (screen, images/textures/sounds)
2. init a clock
3. init game state
4. groups entities for collisions
5. while not ready to exit:
6. ....tick the clock (gets the time taken since last tick) to get 'dt'
7. ....get input (keyboard/mouse)
8. ....go through and test for collisions between groups we are interested in
9. ....go through each element in the element lists and call .update() based on 'dt'
10. ....go through each element in the element lists and call .draw()
11. clean up

Next step: How will we do this in python/pygame? Stay tuned!

Team Blogs

Team A
http://tafeteamaterm109.blogspot.com/

Team B
http://tafeteambterm109.blogspot.com/