If you're looking for my most recent XBox Live Indie Games, they are the large icons above. Below are games I've made in my spare time as a student.
These are games I have developed, either for fun, courses, or contests. They were usually created during my normal school years. They are mostly experimental and for fun, so I wouldn't call them the most polished games out there. I've tried to provide an outline of the games and my own opinions of what I liked/disliked about them in short postmortems. Feel free to contact me if you've got comments to make about them as well.
Tower of Alchemy
This game was a project for a fourth year project course called the Capstone Design Course at the University of Toronto. Our goal in this course was to create a game for a female audience based on a movie franchise within our fall term. We had decided to create a short adventure game loosely based on the Harry Potter world. Team:
Daniel Steger Platform:
This postmortem is a bit lengthy, since I did a presentation on the post mortem of this game for the first Toronto Game Camp after finishing the game. Pros:
Iterative gameplay/Contingency plans - Our game was chunked into manageable pieces, so that we were able to easily scale forwards/backwards depending on our schedule and how we were hitting our timelines.
Utilizing out strength - our team had two reasonable artists (myself and Ante), and thus we were able to create more appealing artistic assets for our game than other teams
Gameplay created early - we were able to see our progress for our game very early on, again because of our iterative plans for puzzle design.
Diverse puzzle types - we introduced concepts such as clicking puzzles, item-based puzzles, movement puzzles, and NPC interaction in our short demo. A good variety for the length of our game.
Created a game WE felt we would enjoy - Our team had quite a few adventure game fans, and a big motivator for a team is working on something you feel you would enjoy Cons:
Writing - This was a bad place to put focus on in our game. Instead of focusing fully on our strengths in art and programming, we tried to make a game with an engaging story. Unfortunately, none of our team members were real writers, yet we wanted to appeal to our audience through an engaging story which we didn't have the means to pull off.
Engine choice - The gamestudio engine, although decent for implementing quick, simple prototype puzzles, it fell short on reuse and stability between systems. There were some major downfalls in the engine which I feel would make it impractical for a game of any reasonable size.
Addressing the wrong audience - In creating "games for girls", instead of approaching the casual game space, which has recently gained a lot of attention in female demographics, we looked towards the well defined, but niche group of adventure games. Although adventure games can appeal to female audiences, at the moment there is a more limited interest in the genre by both males and females. So, our genre was both an advantage and disadvantage, because it was something we loved to create, but was not quite able to get the most impact from our intended audience.
Controls - One of the biggest definers of the playability of a game is the controls. We had a quickly-defined control mechanism that had 3 modes for clicking, looking and moving. These modes needed a lot of control over the mouse and keyboard. The controls took enough time to learn, or were obtrusive enough that they interfered with the core gameplay and acted as a deterrent to players.
Scab was created for the UofT game programming club's Game Making Deathmatch in 2006. The theme for this game was "The stress of a red blood cell during the preparation for an incoming viral attack". My personal goal for this game was to make a game people found funny. Team:
Daniel Steger (Solo game) Platform:
C++ using SDL
Post Mortem: Pros:
Humor - I hit my goal of making a game that made people laugh. Scenes such as a player walking up to a bear waiting for them were a big hit.
Quick, appealing art - I felt I was successful in using an art style that was very quick for me to create, but still appealing to the players. I felt the art fit the mood of the game quite well. Cons:
Changed mechanic - My goals for the game mechanic was to have players "throwing" the blood around to get tasks done, but once the physics and interaction were implemented, I realized dragging the pieces to their goal was a lot more effective in terms of achieving goals, which made me change my plans on achieving solid gameplay.
Difficulty level - For the most part, people found the game too easy. Even with infectious viruses, players didn't have much difficulty passing later levels after realizing what infectious viruses entail. I wish I had included more levels, instead of relying on restarting the whole game to prolong gameplay times.
This game was created for the UofT game programming club's Game Making Deathmatch in 2005. The theme for this game was "dimensional disturbances". This game was created with my older brother. We were inspired to create this game by games like Soldat to create an above-person networked shooter. Team:
Daniel Steger Platform:
C++ using OpenGL
Post Mortem: Pros:
Technical achievement - The game supports networked play and makes good use of 3d
Completed game - The game available is a full game, supporting the main vs gameplay we wanted in it
Visually Strong - There is a good variety of levels in the game which look decent and give different experiences. Cons:
Weapon types - I would have enjoyed making more weapon types. Although we have some unique weapons such as time-bombs and black-hole bombs, we found these devices a bit unbalancing (and in the case of time-bombs, down right frustrating).