3dedrats - A Month of Festivities

Recently at MacICT we have launched our new 3dedrats festival celebrating the latest 3D technologies in education, arts and sciences. We invite you to come join us and play with robots, virtual worlds and video games!

3dedrats is an exciting opportunity to get involved in games, virtual worlds, robotics, arts and science in Australian contemporary education.

Throughout the month of October there will be world first interactive experiences, events, fun competitions, exhibitions and workshops designed for students, families, schools and the general public.

Participation is open to a worldwide audience through online content and virtual experiences as well as events held at multiple venues such as Macquarie University and Sydney College of the Arts. Aimed at all ages, the 3dedrats festival will include world class experiences. Click on the images below to find out how you can be involved:

Right now, if you have a flair for writing, enter our GAME backstory narrative writing competition for a chance to win a prize. The most popular narratives will be chosen to be used in our next challenge - designing a game! Read more on how to enter our competition on the 3dedrats website.

Along for the Ride

I have just got back from attending the Australian Council of Educational Leaders Conference where I was presented with the Microsoft NSW Innovative Teachers Award for 2010. I received this award for work I have done in the area of game design both with my own class at Cromer Public School, and with my MacICT project, Engaging Students as Game Designers, including the new work we are doing with Kodu.

I met with the other State winners, a group of amazing innovative teachers, who are all doing incredible projects in their classrooms and across their regions. What a privilege it was to spend time with such a diverse group of teachers and, after bonding very quickly, we are all looking forward to getting together next March.

Next March I will be off to Phuket, Thailand to participate in the Regional Microsoft Innovative Teachers Awards. I will be presented with many new experiences including working in cross cultural teams on different challenges. What an opportunity and what a journey I've been on. I'm definitely along for the ride and who knows where it will take me!

The huge screen at the Awards ceremony.

This award reflects the combined efforts of the amazing team I work with, particularly my immediate team, Anthony and Simon, and also all my colleagues at MacICT where we have the opportunity to collaborate around ideas, share intelligent conversations, debate and spark off one another. All the projects developed at MacICT are what they are because of the leadership of the Director (and my mentor) Debbie Evans whose leadership at the Centre promotes the process of innovation and creates incentives through giving project teams autonomy, the freedom to strive for mastery and a purpose for what we are doing. While perfection may not be attainable, the culture at MacICT is to chase perfection through repeated iterations of our projects and in chasing perfection, hopefully, we can catch excellence! (Vince Lombardi, American Football Coach)

In addition to this award, two students in my Year 6 class won first and second place in Australia in Kodu Kup, a game design skill competition aimed to recognise students who demonstrate excellence in a diverse range of technical, creative and game play depth and design in the use of Kodu Games Lab. What a fantastic achievement by these two students. I am one very proud teacher!

The Secret of the Paradigm Shift

Over the last few weeks, we took a look at what not to do when designing a game. The top ten most common mistakes made by game designers can be found here, here, here and here. Now we're going to do an about face. It's not fun looking at where games went wrong. This week we're going to recongnise the games that got it right, and maybe pick out a couple of hints to take away for our own games.

Fig 1: Nintendo employees still celebrating release of
Super Mario Bros, 25 years on.

Specifically, this week we'll be examining a technique called the 'paradigm shift'. It happens when the rules of your game are suddenly and massively changed. The world is reformed around new rules, everything old is new again, and your player basically has to relearn how to play your game. It's easiest to think of a paradigm shift as the twist ending in a movie.


For this reason, the paradigm shift is a rare occurence. There should be at the utmost one per game, and there has to be a good narrative reason for the rules as they once were to come crashing down on the player. But when done right, a paradigm shift breathes new life into a game right before the end, where it's often most needed.

Fig 2: Before the paradigm shift

So who does it right? Alien vs Predator and Rune get the idea of pumping up the player right before the end (sorry, spoilers), but the best example of a paradigm shift lies in the final chapter of BioShock. I'm not going to give away the ending but suffice to say that towards the end the game, and your role in it, is turned on its head. Suddenly enemies are friends and your own survival is no longer the only focus.

Rather than just arming the player with some mega-cannons for a spectacular final boss fight, BioShock basically throws a whole new way to play at the player right before the end, resulting in one of the most stressful and most enjoyable levels I've ever played. The paradigm shift turns BioShock from a basic yet dramatically beautiful shooter into something great.

Next week we'll be continuing this theme: looking at how games can intrigue and entice the player. Once again, thanks for dropping by, looking forward to seeing you next week.

Stay tuned!

Anthony

The Design Process

Making a game takes planning. In fact it takes a lot more planning than most people expect. Kahootz and Kodu allow people to jump on and start making a game straight away, but unless you've put some thought into it before hand, more often than not you end up with something that isn't very fun.

Don't get me wrong, when you're first learning to make games, jumping in head first may be the best learning tool you've got. You're just playing around, seeing what happens when you do this or that. It's the way I recommend when people ask how to make games. Problem is, once you start to get familiar with the game making tool you're using, and you start to get an idea of the type of game you want to make, it's time to step away from the computer and go back to basics.

And I do mean BASICS. Pen-and-paper is perhaps more important to game design than keyboard-and-mouse. The design process is a set of steps that are meant to maximise your efficiency through design. Basically, the design process means you know exactly what you're doing at each step of making your game and there's no time wasted to confusion.

The Design Process

The Design Process, also known as the Development Cycle, covers five basics stages. The Design Process is an old friend for any designer, and while the names of each stage might change depending on who you ask, their purposes remain the same. I prefer the cycle written as it is above because it better suits a learning environment and provides easily assessable outcomes. This cycle covers everything from start to finish in the game design process, or in any designed or creative endeavour. Keep in mind as we run through each stage that stages 1 and 2 are best done by pen and paper, and you shouldn't even look at a computer until stage 3.

Stage 1: Identify a Problem
Everything starts here, your problem - quite simply - is that you want to play a particular game but you don't have it. It doesn't exist yet, it's just a figment of your imagination.

Here you think about everything you want your game to be. Don't let anything hold you back at this stage, you can be as creative as you want. All too often I'll hear kids in this stage asking questions like "I want to make my character fly, swim, explode, etc. How do you make him do that in Kahootz/Kodu/etc?" I'll invariably tell them that at this point we don't even care about how we make our game work. We're just imagining the end product and writing down what we want it do to. We worry about the hard part of making it all work later in stage 3, otherwise we'd never get our game made because everything would seem too hard, or impossible to make.

At this stage we ask ourselves:
-Who is this game for? (Who is our audience?)
-What does our audience want our game to do? (What is the context?)
-What can I do that is fun and new?

Stage 2: Design a Solution
You've got a problem well thought out now. Let's start drawing! On a piece of paper, draw what your player will see on the computer screen. Draw up how some of your enemies will look, how some of your maps will look. Start writing down in dot points how your enemies act, points of interest in your maps or worlds, how your player interacts with the world.

This Design Stage is much to big to go into great detail at this point, but I will dedicate an entire blog to it in the near future. For the moment, a brief introduction to the entire process will suffice.

At this stage, we ask ourselves:
-How does my player interact with my game?
-What powerups or threats can change the way the player plays our game?
-How do I make my game suit my audience?

Stage 3: Build a Solution
We've made it past pen and paper. It's time to start actually making our game.

Of course, I can't tell you exactly how to make your game. Each one will be your own. However, I can give you advice. Start small and build outwards. This is called bottom-up programming. Divide your entire game into manageable portions. For example, you might want to focus first on getting the player to run and jump around your world. Then once that's done you can look at making the enemies run and jump around. Then, maybe we work out how to get the player to turn invisible, hang off ledges or fly around with parachutes.

Bottom-Up Programming (as opposed to Top-Down Programming) sees your game as blocks in a pyramid. Build the foundation first, the basics of your game, before working on the harder parts. Let your game come together from separate pieces rather than trying to make it all in one go.

Stage 4: Test and Refine the Solution
This stage, I would argue, is the most important stage of them all. If you've rushed through your game and haven't spent any time testing it you could have all sorts of bugs and glitches waiting to ruin the fun for your player. And if your game isn't fun for the player, it isn't a game at all.

You've got a working model of your game at this stage. So show it to your friends and family, watch them as they play around with it. Do they get confused or lost? Do they not know what to do sometimes? Of course everything seems perfectly obvious to you, but you made it. You have to take a step back and ask yourself why your testers are getting confused. Maybe you need to put in more instructions, or a hint or two. Maybe you need to use different colours and sizes to show stronger and weaker enemies of the same type, or maybe you need other visual or audio cues when the player is getting hurt, or when they're winning.

And don't forget to write down each time the game crashes, or does something it isn't supposed to do. This stage can take a long time. Every time you find a bug, you have to go back and fix it and then get your players to test it again and again. Just remind yourself, this is all making your game better.

Stage 5: Evaluate the Solution
The game is done. It's been tested, all the bugs have been ironed out, and the hard work has paid off. It's time to release your game to its intended audience. It's important to watch them play your game, get feedback from them, see what they like and didn't like. There's a reason that the Design Process cycles round back to stage 1. If your audience doesn't like a part of your game, or doesn't understand it we're back at stage 1 with another problem, and hopefully another solution to design.

Now that you've got an introduction to the design process. It's a powerful tool and it's something that all designers use. If there's any part of this blog you'd like more information on, or you'd like to suggest a topic for a future blog please feel free to drop me an email and I'll be happy to accommodate you.

Next we'll start to look at the types of games out there, and the games you'll commonly be making.

Stay tuned!

Anthony