Mid Semester Update

It's (more than) half way through the fall semester, and that means projects are starting to get playable and move towards their final state for the ESE. We had our mid-semester expo a couple of weeks ago, so I thought I'd give an update on where the projects stand so far.

- Kinect Pong has made good progress, and are now reading in a moving skeleton from the Kinect and letting you bounce a ball back and forth off a wall.

- Sequence has a test level going where you can match and extend the pattern that the game gives you.

- Marblematic has a working 3D scene using the Ogre3D graphics engine, with some great lighting and shadows. Next up will come physics and track building mechanics.

- Beat Descent has beat detection working and lets you fly around a test dungeon while playing random tracks off of your computer.

- Node Defense has a working tile engine and some basic tower mechanics set up.

Mid-Semester Expo

The Mid-Semester Expo has been scheduled for Wednesday, October 19th at 6pm in Olsson 120. Come to see the progress of the 5 cool projects!

XNA Crash Course

On Tuesday we hosted a tutorial session for Microsoft's XNA Game studio.

You can download a recording of the session here, and the code sample from the presentation here.

To use XNA you will need the following, which are both free/free for students:

• Microsoft XNA Game Studio 4.0
• Visual Studio 2010 Professional on Dreamspark
  

Pitch Meeting Scheduled!

The pitch meeting for the Fall Semester has been scheduled for Tuesday, August 30th at 7:00pm in Olsson 009. Come out and see what we're going to work on this semester, we have 5 great projects in store for you!

iPhone App Development

Games for the iPhone and iPad have been very popular in the last few years, so for those looking into developing a game for an iOS platform, here are some concepts to think about.

-The language used in iOS development is Objective-C with Cocoa. Whether or not you like this language, there are quickly increasing number of tutorials of how it works.

- In order to develop iOS games, you'll need a Mac (sorry PC-users) and Xcode, the IDE for creating iPhone, iPad, and Mac applications. Xcode is a great IDE that comes with an interface builder and one of the best developer documentations around. You can either buy it from the Mac App store (about 5 bucks at time of writing) or you can download it for free if you are a member of the iOS or Mac Developer Program (which is $99 a year and allows you to distribute the game through the store).

- iPhone App and Game Development relies heavily on the Model-View-Controller software architecture, which divides programs into three parts:

-- Models- These are abstractions of data or data structures. For games, some examples of this would include characters, items, enemies, and levels.
--Views- These are the physical representation that the user sees. The art and animations of what was listed above are good examples of views as well as the menus and help screens.
-- Controllers- These link the actions of the user to the program. The models and views can be changed based on what the controllers detect from the users.

The controllers is probably the hardest part to grasp for a new iOS developer. It is a lot more than writing code for when a player presses a button. Everything on the screen inherits from the UIView class, and each of these can have a ViewController. If the player rotates the device, a ViewController is responsible for managing how the screen flips or adjusts. If the player presses on an enemy, the enemy's ViewController reads this and alters the enemy accordingly.

This should be enough for a good start in developing for iOS.

T-Cubed Update

T-Cubed for Xbox Live Indie Games is coming along pretty nicely. So far we've added a number of new minigames, a scoring system, and support for avatars. We've also ported the game to the Xbox 360 (although this video is for the PC). From here we'll continue adding minigames, as well as improve the overall polish and balance.

The Onion Development Model

Everyone who's been in SGD for more than a year has seen or been on a failed project, and most every repeat director has had at least one dud in their history. There are a number of different reasons for this:

• Director is lazy or distracted
• The development environment sucks
• The project idea fails to motivate people to work hard
• The project is reliant on a single feature or person
• Project has too large of a scope

When preparing to compete at the 2011 Rosetta Stone Game Jam, we started thinking about ways to mitigate these problems on a 36 hour scale. Frankly, an SGD project also condenses into about that scale over the course of the semester. We felt we had pretty good methods of dealing with the first four issues. So, we looked for a way to ensure success despite the 5th one.

We say despite, because in our experience there is no such thing as a project with a perfect scope. The onion model accounts for that, and allows the project to succeed regardless. Basically, you start with the smallest possible vision of your game that would still be playable, fun, and still "your game". So if you were making a space shooter, you would say that your onion was flying around, firing and destroying enemies.

With the onion, you don't spend any time on any aspect of the game that does not fall into the core of the onion until those parts are complete. For example, you wouldn't work on enemies shooting back at you, or multiple types of AI, until all those basics were in.

After the core of the onion is complete, you designate a set of features as the next layer and repeat the process. This guarantees two important things. First, if your project is cut off (such as at the End of Semester Expo), you are sure to have a fun and playable game. Secondly, you ensure that the features most important to your game receive the most testing, polish, and attention.

If there's a small problem with your firing code that causes the game to crash 1% of the time, if it's added at the end, you may never see the bug. But if it's added first, you'll be sure it gets the testing it needs.

The Onion model may or may not make sense for larger project, because the engine needs to be ready to accommodate the small features from the beginning. However, we think that for SGD it is a great way to secure a good showing by the end of the semester.