BeeZ

Lights out

Hardboiled (Play Here!)

The Idea

What went right

What went wrong

What I learned

Other games this week:

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.

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.

This week was rough. I had several Ideas about games I wanted to make, but not enough time to make it. Knowing I wasn’t going to have enough time to finish my big idea I readjusted my expectations and decided to make a really simple game that focused on making one statement.

IRB REVIEW, THE GAME (play it here)

The Idea

Amanda suggested I comment on the IRB process and the difficulty in submitting a revision. With that, I made a version of PONG that was unfairly stacked against the player. I chose pong because it was fairply easy to make while at the same time paying homage to one of the most influential games. I got a quick prototype off the ground and then decided to focus on the aesthetic.

I believe it was Ian Bogost who suggested videogames could be used as a form of satire that draws attention to the underlying structure (like a political cartoon). I’m not saying I achieved that, but it did inspire me. I hope the end product looks like a cartoon ala The Far Side, or XKCD.

What Went Right?

I feel like focusing on one takeaway message really helped. I had a lot of temptation to make the game more complicated by adding stuff like: a counter that kept track of the number of times you bounced the revision back, a simple AI that would make the game 100% impossible by moving the already colossal board, and a “choose your field” option that would change “submitting an IRB revision” to something a little more generalizable. In the end, I’m happy I didn’t over complicate things and feel it at least delivers a chuckle.

I was also able to insert a shader to give the ball a 2d look in spite of the fact it was actually a 3d object.

What Went Wrong?

I didn’t get the paddle to influence the angle of the ball very well. Since I was using the out-of-the-box physics engine, the ball just bounces straight up from the players paddle w/o considering the velocity of said paddle. It could very well be that I just didn’t implement it right though.

What I learned

I didn’t try to write the physics of the game myself. Because of that, I had to rely on Unity’s built in systems and learned a lot about cool things like the way that rigidbodies react with one another as well as how to use physics materials. I’m not sure I would have bothered to learn about that system if I had tried to write the OnCollision logic myself.

Other Games from Week Four

Mark is continuing to work on his Space deckbuilding co-op game and it’s looking great. Maybe a physical prototype will surface by AERA? No pressure.

Anastasia drew on her experience preparing “academia’s equivalent of taxes[…] progress-towards-tenure materials”. The result is a text adventure game boxes. I am constantly amazed by Anastasia’s ability to generate mood. The line “You can see a corkboard (on which are some get-well-soon cards)” made my stomach turn. I love text adventure games, but find them really hard to do correctly by myself (I tend to shy away from generating descriptions). Maybe I’ll take on the genre another week.

Melissa made an impressive RPG influenced by Carl Sagen. I love the minimap and totally felt like I was playing a classic dungeon crawler which, except for the Legend of Grimrock, is a breed these days. I’m impressed by the number of structures generated in such a short amount of time. I also like the idea of using starstuff as a weapon.

Greg Koeser is joining us with his first week’s entry bid war. My initial playtest was fun and easy to get going. After a couple of rounds I revisited his write up to read the strategy section (which I had refrained from reading before) and got a better understating of the game as a whole. I look forward to replaying the game with these tips in mind.

Top Tweet (play here)

This week’s reusable game chunk was a twitter API that I would be able to use in my other unity games. I have ideas for using the tweets as random NPC convos, or to generate stuff int he game world programmatically. Having this in my toolbox will be fun.

The idea

I had an idea for a game where you had to choose a popular twitter tweet. The original Idea involved a mechanic where you gained followers by choosing the top tweet and lost followers by choosing the wrong tweet. The game would end once you ran out of followers, or after 10 rounds. In the end the idea morphed into picking a tweet that you think had the most retweets. If you were right, you gained a point. If you were wrong, you lost a point. After 3 lives, you are left with your top score.

What went right

The twitter api worked very well. I was able to collect tweets easily and parse the information quickly. I also made sure to buffer the tweets so that I wasn’t making too many requests. All in all, this took waaaay less time than I anticipated which resulted in a lot more polish than my other games. This week I was able to make a custom UI, add sound effects, background music, a bit of beta testing and I was even able to refactor my code. I almost got it to work on mobile until I wasn’t able to resize the game and ran out of time. I would like to think the process went quickly because I scoped it well, but I had budgeted a lot of time for the twitter module so I think it was mostly luck this time around.

What went wrong

No web version! This game wasn’t letting me make a post request to twitter in the way I usually do and I never got around to figuring out why. Because of this, top tweet had to be compiled as an executable. I think the answer may be to have my server make twitter requests and then poll my server for cached twitter data. Haven’t developed the structure to do that, maybe I’ll try to do that one of these weeks.

What I learned

Enums are freaking awesome as game states. In this game I had a main UI controller that rendered everything on the screen. I defined some enums to represent game states and made my functions switch the current state after they made their computations. The result was a really manageable UI controller so I definitely think I’ll be using this method in the future.

Other games this week

Anastasia’s game never fails to make a statement. Her game a week sub, Balance, hits quite close to home. I won’t lie, I felt anxious while playing Balance. I love the statement it makes. Play It here, and read about the process here.

Melissa’s game, Muintir, has a really cool mechanic where you attempt to repair your shield before a barrage of attacks. How do you repair it? By weaving. Check it out, and read about the progress here.

Mark continues his quest to flesh out his co-op space game. Read about his progress here.

This Week’s GameAWeek entry is a time travel adventure game called “Time Enough To Travel” (a slight reference to the twilight zone episode Time enough at last)

Game #2 Time Enough to Travel.

Idea

Following the idea that I had to make reusable parts for my games, this week’s GameAWeek was centered around an Event Queue. Lots of simulation games use event queues or can be replicated with them (Oregon Trail, Game Dev story, Spent, etc). The idea is you have a list of objects with each object representing an event. When the game decides it’s the next time step (say the next hour, the next day, etc) the system checks the list for the next event that is scheduled to occur at that time and executes it. This system gives me a lot of flexibility because once I design a few events I can arrange them in several ways to make unique gaming experience. For example, if I make the events “Player catches Dysentery”, “Broken Axel Wheel”, “Lost Oxen”, “Snake Bite” I can create several unique playthroughs:

Day 1 – “Game Start”
Day 2 – “Player catches Dysentery”
Day 3 – “Broken Axel Wheel”
Day 4 – “Game End”

and

Day 1 – “Game Start”
Day 2 – “Lost Oxen”
Day 3 – “Player catches Dysentery”
Day 4 – “Broken Axel Wheel”
Day 5 – “Snake bite”
Day 6 – “Game End”

I got a simple version of it working and then started thinking: “Hey, I can also go back and forth through time with this.” So, I ditched the Oregon Trail idea and decided to do a Time Travel based game.

What went right

I finished, but ran about two hours over time. The event queue worked well and I think I’ll be able to reuse this system a lot. Thanks to Mark’s suggestion from last week I also picked up PyxelEdit which proved to be tremendously helpful when creating my art assets. I also ended up with a lot of simple triggers that I might be able to reuse in other games such as the speech balloons that pop up if you’re close to an NPC.

What went wrong

In the end, I wasn’t able to animate the Success or Failure events. I relied heavily on text because I simply didn’t have the time to insert new objects and have them move/animate in a way that conveys what’s going on in the scene. This is too bad cause most of the art was already done:

if I had more time, I would probably render a static Success or Failure screen for every level so at least players can see what happened to them.

I added a Pause option to be triggered when I showed a message (so that time wouldn’t keep marching forward when you’re reading a prompt). In the end, it worked for most events, but for some weird reason didn’t work for Success screens. This is weird and something I would like to get to the bottom of, but for now just included another variable bool successScreen that paused the game. Ugly, yes, but sometimes you just need it to work. I rationalized my hacky code towards the end of the project by thinking that the Event Queue code was reusable so it didn’t matter if the other parts can’t be.

LAYERS! I didn’t have enough time to get layering done. As a result, sometimes the main character just kinda floats through things. If I had had more time, I would have translated z coordinates as a function of y (The lower you go on screen, the further you pop out). Instead, I had an NPC draw attention to it as a byproduct of time travel.

No music this week either. Sad.

What I learned

It’s not easy to change direction halfway through the challenge. If I would have stuck with the Oregon Trail Idea I probably would have finished earlier and would have cause my self less grief. Then again, I didn’t really think of an interesting “trail” idea and the time travel idea was cooler giving me more incentive to push through.

Also, art takes suuuuuper long. In the future I should probably abstract as much of my components as possible (maybe using cubes like Thomas is alone) or check out open game art.

Other Games from Week Two

Anastasia created a very atmospheric game called My Town which instantly brought to mind movies like Memento where you piece the narrative together along with the protagonist. This is a story told through the eyes of a woman with Dementia and left me feeling very vulnerable.

Melissa made a crafting/puzzle game called Solution which shows a lot of promise as a way to teach chemical reactions while being fun and engaging.

Mark uploaded a photo of a card game he’s working on. Can’t wait to hear more about it.