Thursday, April 30, 2009

Skies of Fury: Post-mortem

Skies of Fury was the first project I've worked on with Student Game Developers. While I can't speak for our director, John Will, I figure it'd be good to chronicle what I thought went well and what didn't with the project so that other could learn from our successes and failures.

WHAT IS SKIES OF FURY?

Skies of Fury (herein: "Skies" or "SoF") is a two-dimensional, top-down shooter that harkens back to the days of sprite animation and simple yet intense and addictive gameplay. The player assumes control of an advanced military fighter jet, taking on wave after wave of enemies, preparing for a challenging boss encounter at the end of each level. The goal simply is to make it through alive.


WHAT WENT WELL?

  • We finished the game.  While very brief in length (more on that later), every feature we wanted to implement into the SoF game engine was implemented.  We consistently hit our targets every week with few exceptions, and as such we were able to stay on or in rare cases ahead of schedule throughout the development process.  We did have a bit of a crunch near the end of our dev cycle to get final tweaking and game balancing done, but this was expected.
  • Our team performed incredibly well.  The most vital component to the completion and success of this project was the ability of the team to work together to get stuff done and meet weekly targets.  Our team was comparatively large compared to other teams at the outset of the project, but effectively half the team dropped from the project over the course of the semester.  The guys who did stay on (Matt Beattie, Charles Gibson, Steven Mond, Nick Wasilewski, Matthew Yu, and myself) in my opinion did an incredible job of communicating with John and each other about changes made to the game, upcoming targets, bug-squashing, and everything else that came about related to the game.  Along the same lines, each person at some point took some initiative to implement some critical feature into the game.  Such features that were originally added by the efforts and initiative of but a single person (and tweaked by the team from there) were: the backbone of the entire game engine, the entire first level, music and sound implementation, the boss fights, offscreen tracking arrows, and particle effects.
  • The game is fun!  Thanks in part to being able to implement all of our features, the game turned out as good, if not better than we hoped for.  Everyone who played it at the Expo yesterday gave us positive feedback with regard to the fun factor of the game (alongside some constructive criticism and/or whining about dying too often -:) ).

WHAT COULD HAVE BEEN BETTER?

  • Testing.  Throughout the design process, we struggled to get extensive feedback on our various builds of the game.  Our team at the outset had three testers, but by the end of the development cycle the only one who had ever contributed any feedback whatsoever was Matt Beattie (who contributed much useful feedback himself, but one tester can only be expected to do and find so much).  Many bugs in features were discovered weeks after the fact by our designers, who had to take up roles of testers as well to make up for the lack of feedback from two of our three listed testers.
  • The game isn't quite as long as we wanted.  Our original plan was to have at least three levels in the game, each with five unique enemies and a boss.  Time constraints due to engine development bugs, lack of testing, and the rigors of being full-time students on top of participating in this project quickly cut into our ability to meet this goal, however.  The final game does have two levels with five shared basic enemies and two unique bosses.  Adding more content would have made this game significantly better, in my opinion; that said, we knowingly traded off content amount for having a stable and good game engine underneath all the content, and I firmly believe that SoF benefitted from this trade-off.
  • Sloppy code and inconsistent documentation.  This is more of a personal gripe of mine that no one else may notice (and probably everyone on the team is guilty of, myself included), but throughout the game, memory is constantly being allocated and deallocated during gametime.  Given the fact that our game is a 2D shooter, this isn't a huge issue as any current hardware should handle our game no problem so long as we didn't try to do anything ridculous (like draw 500,000 particles at once), but this is still very poor practice; anything that we needed for a level should have been initialized in a single Initialize() call rather than in the main loop of the game.  Another gripe of mine is inconsistently commented code, which sometimes made it difficult to tweak the game or squash bugs.
  • The game is sometimes too hard.  My personal thanks to Nick (our lead level and boss designer), you are evil :)


OVERALL IMPRESSION

I personally would call Skies a successful project.  Not only did we finish the game, but we made a fun enjoyable one.  It's not without flaws, but for my first full-fledged game project with SGD, I personally am very happy with how the game turned out.  The success of this project has me looking forward to working on a new project with the club (perhaps even some of the guys on this same team, should the chips fall that way) next semester.

Daily Progress covers SGD End-of-Semester Expo

A representative of the Charlottesville Daily Progress was on-hand for our End-of-Semester Expo yesterday and wrote a recap article for that publication. You can view that article by clicking here.

Thursday, April 23, 2009

Expo Trailer

Well I figured it should be posted here at some point, so here is our expo trailer in all of its glory.

Thursday, April 16, 2009

Robot Thesis Lives!

Hey everyone! I'd like to call your attention to a project that hasn't been mentioned on here yet: Robot Thesis! Our game is a 2D beat-em up in the style of Streets of Rage and Final Fight. We've spent most of the time building the engine for our game, but it's mostly complete now. We'll be focusing on content and minor tweaks from now on. One of the things we accomplished recently was the addition of a title menu.

Screenshots after the jump.



The title menu.

Gameplay screenshot. On the right is the temporary guy we're using for the player. He probably won't be the main character at the end, though.

Tuesday, April 14, 2009

Skies of Fury: Progress Video Update


More after the jump.

There are a few new elements in this video. Most readily apparent are:
-yellow offscreen tracking arrows that notify the player of the presence of an enemy just outside the play area
-the player's alternate weapon; player charges up weapon by holding left trigger / tab, and when this is released orange projectiles are launched in a spreading pattern. The number of projectiles launched is dependent on how long the player charged the weapon. Also note the the player can apply 'english' to the launched orange projectiles by using the RightThumbstick left and right / A and D.
-several new enemy attacking patterns displayed in this video
-on Easy and Medium difficulties, the player possesses a shield to designate that he can take a hit without dying. When the player gets hit once while the shield is active, the shield disappears and the player enters the "Danger state".

Not shown in this video is the level transition screen, which calculates player score bonuses at level completion based on what percentage of the level's enemies he killed and his accuracy, and the SoF Formation Editor, an in-house development tool which more easily allows for the creation of enemy attacking formations.

Monday, April 6, 2009

Introducing Shark Attack: World Tour

Shark Attack: World Tour is a game that introduces a different kind of gameplay to this years SGD line-up. While RGB is a lightning-fast reflexes puzzle game, and SoF is a lightning-fast reflexes flight shooter game, and [insert tower defense game name here] is a strategic lightning-fast cognitive ability game, and Robot Thesis is a lightning-fast reflexes beat 'em up, and the Imperium Project is a not lightning-fast (seeing a pattern?) turn based fighting tactics / strategy / interactive novel of goodness, SAWT takes a slower more casual approach to gaming.

In Shark Attack you have no enemies. At least, none that can kill you. You are an almighty shark, and your drive is to kill and destroy and get bigger so you can kill and destroy more! That's why in Shark Attack your only nemesis is time - can you beat the clock and get as big as a submarine in less than two minutes? Well that depends on what you eat and destroy.

As a shark, you view everything in the world as one of two things - either an edible or a destructible. Edible's, like fish, dolphins, seals and people are things that you can attack with your bite, and eat. Destructibles, like rocks, coral, shark cages and submarines are things you can destroy by smashing. Many destructibles will have a bunch of edibles hiding in them, too.

As you advance through the game you unlock different levels. The first level is, of course, Miami, the place everyone associates with sharks. Then, by getting a high enough score in the given time limit, you can unlock the next level, and so on, until the very end.

The SAWT team is currently working on a few polish things and adding in support for a world map and a second level.

Sunday, April 5, 2009

RGB DS Mechanics 1 - The 4 colors

This is the first of a few posts in which I will outline the different mechanics found in RGB DS. In this post I'll outline the basic mechanic behind the game - the 4 colors of objects and how they interact with the two different worlds.
RGB takes advantage of the 2 screens on the DS, placing the blue world on the top screen and the red world on the bottom screen. Objects in the blue world fall downward, following gravity as you would expect in any other platformer. On the other hand, objects in the red world have gravity pull them upwards, causing them to "fall upwards."

Video and more after the jump.

A green object will perform just as you would expect - it will fall down in the blue world, and fall upwards in the red world. However, a blue object will continue to fall down even when in the red world, and a red object will continue to fall upwards even in the blue world. There are also yellow objects, which are "neutral," meaning that they are not affected by gravity, no matter where the object is.


This video gives a brief demo of how the player, a green object, can make use of traveling through the two worlds to reach the goal of the level, a shiny star. In particular, notice how speed is conserved when traveling through the two worlds, allowing you to reach higher locations by not touching the floor.
Stay tuned for the next update when I'll talk about blocks, buttons, and doors.

Skies Of Fury: Progress Report and Feature Breakdown



Breakdown of all new features displayed in the video since last website update about the game after the jump.

This video comprises about half of Level 1 on the default difficulty setting. Level design is credited to Nick Wasilewski and Steven Mond.

0:04 - though not very readable due to the low quality of the video upload, the player now has a heads-up display in the lower-left and lower-right corners of the screen. This HUD displays lives remaining and score on the left (in green), and the amount of available Overdrive on the lower right (in yellow-orange; Overdrive will be elaborated upon below).

0:05 - any time the player starts or respawns after death, he is given a brief grace period of invincibility. This lasts for a little over three seconds and is indicated to the player by the background fluctuating to a turquoise color.

0:06 - explosions added into the game. The game chooses at random between sixteen different explosion spritesheets.

0:10 - a new enemy type, the Scout. Low health, but has a rapid-fire laser cannon as its weapon rather than the standard purple blob. A bit of an aside, one of the things we're currently working on is adding more variety to the in-game projectiles.

0:11 - by holding down Left Shift (or A on the XBOX360 controller), the player enters "Overdrive" mode. While in Overdrive, the player moves twice as fast and his primary weapon fires twice as many shots. In addition, the background color fluctuates to orange to give the player a visual cue that he is in Overdrive mode. The player begins the game with no Overdrive, but earns Overdrive by killing enemies.

0:17 - when the player is hit by an incoming projectile, he becomes vulnerable to being killed. This vulnerability is made evident by the loud warning horn, flashing "DANGER" text at the bottom of the screen, and the fluctuation of the screen color to red.

0:18 - the player's primary weapon receives upgrades as the player scores more points. Currently the points threshold is squished for debugging purposes. Here we see the player fires four forward shots simultaneously.

0:25 - another upgrade, this time sideways-firing shots.

0:29 - two more upgrades are visible (remember I said the points scale for upgrades was squished; I wasn't kidding, heh); the player fires shots backwards from the reverse of the ship, and a single orbiter circles around the player's ship. The orbiter fires shots at a slow rate, but the orbiter's shots will home in on the closest enemy.

0:32 - another new enemy, the Heavy ship, makes an appearance. Its behavior, however, is not yet final.

0:36 - the player now has two orbiters as the result of another upgrade. The second orbiter behaves the same as the first orbiter.

0:43 - a third new enemy, the Doom Rocket, appears. The Doom Rocket flies in a single predetermined direction, dropping bombs off as it flies through the scene. The bombs explode and generate a massive number of projectiles in all directions.

1:00 - a fourth new enemy (if you can catch a glimpse of it, it moves incredibly fast), the Net. The Net enters the screen based on the player's current x-position and flies at a rapid rate towards the player. The Net can harm the player with either the electric beam that exists between the two subship pieces it is comprised of, or simply ramming the player. The Net has no projectile weapons, however.

1:01 - when the player dies, the background color fluctuates to black until the player is revived.

1:28 - just before the video fades out, we see the fifth new enemy at the top of the screen on both sides, the Cloud Cannon. This is a stationary enemy which constantly fires projectiles in a single direction.

With this update, most of the key gameplay features of SoF are implemented, the notable exceptions being the player's alternate weapon and a finalized boss enemy (or enemies, if times allows). Once these is implemented, level design, game balancing, and bug-squashing will become the primary areas of focus.

SoF remains on track for completion by the SGD End-of-Semester Expo.

Spring Election Results

Below are the belated results of the Spring election, which was held after the SGD Mid-Semester Expo on March 11, 2009:

President: Chris Dodge
Vice-President: Dan Magnussen
Treasurer: Dan Epstein

Note that Dan Epstein has assumed his duties effective immediately, given that his position is new for the upcoming academic year. The other newly-elected officers will assume their positions at the beginning of the Fall 2009 semester.

Also of note, Chris Hooe was effectively appointed to the position of webmaster.

Wednesday, April 1, 2009

How-To: Pitch a Project to SGD

Have a good idea for a game that you'd like to develop with a team of SGD members backing you? Below are some guidelines for turning an idea in your crazy head into a full-out project for the group to develop (and get you rich and famous and deliver unto you everlasting fame and glory and all that good stuff).

The first requirement, one of which is obvious, is that you must be a member of SGD to pitch a project to pursue using SGD members and resources. Immediately following that, SGD policy dictates that you must have experience with at least one prior SGD project before you are eligible to pitch any of your project ideas to the to the club. This rule ensures that anyone pitching a project will have some sort of experience on a prior project team and has an idea of what is expected of him or her as a project director (note that if your pitch is successful, you assume the role of director of that project, meaning you are ultimately responsible for its completion).

If you meet this requirement, you're eligible to make a formal pitch to the club. To do this, the foremost thing to do will be to fill out a design document. The design document is a formal outline of what your game is, what features it will entail, specific gameplay mechanics, list of resources need, etc. etc. With regard to resources needed, you (and/or someone in a high-ranking position on your team as laid out in your design document) should be familiar with the resource(s), API(s), etc. that you wish to use to implement the project; for example, if you want to make your game in XNA, you and/or someone else on your team should already be familiar with XNA. The design document should also include a week-by-week timetable listing project goals for each week of development en rout to its completion. The SGD design document template can be found here (click).

Upon completion of the design document, you should promptly submit it to the SGD officers for review. The SGD officers will go over the document with you and help you nail down your game concept, provide constructive criticism to improve the concept, and firm up your proposed development timeline to follow for the completion of the project. Don't be surprised if you end up going to the officers several times before your project is approved; in particular, given the fact that anyone working on an SGD project is a student at The University first and foremost, time constraints will be a constant factor in any project you propose; you may be ask to cut some features from a broader concept, or spread the project out over multiple semesters. Ultimately, your design document must be approved before the conclusion of the club's pitch meetings, which occur during the first few weeks of the semester.

Once your project is approved by the officers, you are expected to pitch your project to SGD as a whole at the aforementioned pitch meetings. You'll meet with officers to set up a pitch presentation date, upon which you will present your project to the entirety of the club. The pitch itself typically involves explaining your game concept, elaborating on some of the key particulars and play mechanics of your game, and relaying other pertinent information from your design document to club members. This presentation is typically backed by a Powerpoint and lasts about fifteen minutes; more ambitious presentations might show off a functioning game engine, or in general have some sort of base to show off to give the club a better idea of what exactly you're going for with your game. Upon completion of the pitch, you'll pass out sign-up sheets for your project and offer positions to SGD members who do sign up.

Ultimately, successfully pitching a project to the club isn't overly difficult, but it requires a fair amount of dedication and work to complete and receive approval. The same amount of dedication will be required to complete your project over the course of the semester, however, so getting through the pitch process successfully is a necessary step in proving that your idea is worth developing and that you are in fact capable of leading the project to its completion, the rewards of which are eternal and everlasting. :)

Again, click here to download the SGD Design Document.

Although this organization has members who are University of Virginia students and may have University employees associated or engaged in its activities and affairs, the organization is not a part of or an agency of the University. It is a separate and independent organization which is responsible for and manages its own activities and affairs. The University does not direct, supervise or control the organization and is not responsible for the organization’s contracts, acts or omissions.