From GameAWeek

Game a Week #6

Routine (Play Here!)

The Idea

The Idea for this week’s game came from talks with faculty. A common trend I noticed was that a faculty member’s time is eaten up very quickly by advising, teaching, writing, and meetings. Keeping up with the deluge of TODOs seemed like an interesting idea to explore. I thought about other games that use order and increased complexity and decided to use Simon’s sequence memorization gameplay as the core.

What went right

This week I wanted to make sure that I was able to display things on the UI for instructional purposes. A game of Simon requires a moment when the correct sequence is flashed on the screen and the game receives no player input. Since I haven’t done anything close to cut-scenes in my games I felt like this would be a good step towards creating a cut-scene system. The system worked well and I suspect I’ll be using it again in the future.

What went wrong

The game does an OK job of letting the player know what to do, but when playtesting the game there were a couple of times where the playback of the pattern interfered with the player. Usually the confusion was cleared up quickly, but I’ll try to make it more clear when players can and cannot input commands.

What I learned

The biggest takeaway this week was finding out how much time should be spent flash the instructions/pattern on the screen. Too much and people get bored, or confused. Too little, and players can’t remember the pattern very well. Just goes to show how important it is to usertest.

Game a Week #5

A-Maze-Ing (play here)

The Idea

For this week’s game a week I wanted to focus on making randomly generated mazes. I feel Like I can use this system to develop other procedural games like the binding of Issac etc. I’ve implemented similar systems before (for python and javascript), so I had a good handle on the algorithm before I dove in.

Since I had a limited amount of time I tried to keep the actual game mechanics simple. I was inspired to make a game about finding a conference room in a convention center you’re unfamiliar with, this resulted in a procedural game where you have to collect an item and then make it to the exit in a set amount of time. If you pass the level, you’re moved on to the next maze which has 5 more rooms.

What went right

The algorithm worked very well. Now I’m able to create a maze of any size at about O(N) run time which I’m really happy about. I already have a lot of ideas about how to use this algorithm. Keeping the mechanics simple helped to make the game easy to access, and the fact that it’s randomly generated makes the game infinitely repayable.

When I was debugging I made it so that all tiles in a room would render. After making sure player weren’t falling off the map or walking through walls I made it so that only rooms that you have visited would be rendered (fitting with my theme of exploration). I found that I wanted to at least know where the lightbulb and exit were, so I made sure those rendered regardless. This improved the game so I decided to tweak it once more by introducing a “fog of war” in order to increase the challenge.

What went wrong

This game a week was a bit derailed by conference presentations an travel so it’s really ugly. It has a stock blue background and the pieces rendered onto the screen are mostly basic shapes. The drawing algorithm I used is also too bloated making multiple renders on a single tile (in order to show the doors you can go through up to 4 pngs are stacked on top of each other). I already know of a way that I can fix this (only iterate over the last five tiles you have seen), but alas I have no more time.

What I learned

Although this was my third time implementing a randomly generated maze, I still found it a bit challenging. The simple description of the algorithm I used is as follows: First, you have to start with your seed (or starting room) and make sure it goes into at least one other room, and less than 4 other rooms. After connecting the new rooms to the starting room, you’ll have to see where the rooms you just generated go. Continue this process until you have used up all of your rooms. Of course, before generating a room you’ll also have to check to make sure a preexisting room isn’t in the same position.

Other games this week:

Anastasia’s game Bubble conveys the message that negativity can take quite a toll. In the game, you attempt to dodge hurtful words by clicking on them. If a word hits your avatar your bubble(self esteem?) decreases. Once you’ve taken enough damage, you explode. Excellent metaphor. Read about her process here

Melissa has released her rules for the weather game. In the game players attempt to protect your city from weather related disasters by building atmospheric systems. I really like how the weather is represented (hit points, movement, etc) which gives them a sense of presence and threat. Read more about the process here

Mark’s anticipated card game made it’s full release this week. The game and it’s components (including the process behind creating this beta) can be found here. I really like the co-op nature of the game and really applaud the design goal of 30 min. I’ve been burned by games that last waaaaaay longer than the box estimates (munchkin?).

Greg talks about his process in making a dungeon crawling card game. The premise sounds fun and the mechanics mentioned (gears and shifting the board) brought to mind games like Labyrinth.

Nick showed off a prototype map of a world divided by different disciplines. The ultimate goal will be to unite these kingdoms. Can’t wait to hear more about it.