Rapid Prototyping 3.2 – How to prototype

So our pitch didn’t go over well.  We had some conflicts about whether or not our game was actually a serious game.  As per the definition of having a primary purpose other than entertainment, our game is definitely a serious game.  However, it is not a good serious game and couldn’t accomplish anything.  The problem is that it is just shouting out our opinion.  There is no hard facts to back it up.

So began our long journey of ditching ideas and finding the game we are going to make.  We went back to the design box, and got stuck over, and over, and over again.  We bounced from many different topics from GamerGate to Somali Pirates to Ebola.  We eventually re-settled on a game about poaching that was basically the hunting game from Oregon Trail.  Not for long, however, as we soon re-ditched this idea.

We held another design box session, this time with one of our professors.  After much pitching within our group, we resettled on a game that is tangentially related to GamerGate.  Using an article that stated that the parity of PC gamers is about 50/50 (just barely over 50% for women – http://www.pcgamer.com/researchers-find-that-female-pc-gamers-outnumber-males/), we came up with a platformer game that we could build, still using the code we wrote originally.

Now that we are basically 2 weeks into production (eek), we are going to make the following game.  A swarm platformer where you control a swarm of characters, half male and half female.  Some will die as you progress through the level since you do not have complete control over all of them.  However, you get points based on how close you are to achieving perfect parity between male and female sprites.


Rapid Prototyping 3.1 – Serious Game!

We had a week off due to fall break, but now we’re back!  And we’re back strong.  This is going to be a solid prototype I can already tell, because of our team.  Every member of this team, except one, I had already known, interestingly enough.

Without further ado, here are the constraints for this prototype:  We have to make a serious game.  That means a game who’s primary purpose is not entertainment.  Seems easy right?  We’ll see.  Furthermore we have to use Unity (YAY).  Additionally, we have to use a design box strategy to come up with our idea, which honestly seems like a totally awesome methodology for prototyping.

After the entirety of today of hashing out ideas and going through design box after design box, we’ve eventually settled on an idea.  We are going to tackle the gamergate issue (not the entire issue, just a small part of it – the harassment that women face in games).  The idea is a platformer where there are “trolls” and “white knights” and other NPCs that will get in your way as a girl gamer.  They will have speech bubbles and various other mechanics that will prohibit you from getting through the level.

Let’s get to it!

Rapid Prototyping 2.3 – Not proud of this one

This is the ending post for this prototype of bagman.  The title should give away how I felt about how we did overall, which is definitely not to say this prototype isn’t useful.  I definitely learned a lot.

Here’s our final game:



We iterated a bit on the original game, and reversed the roles.  Instead you are now playing the policeman and you are trying to capture the prisoners to carry them back to jail.  We essentially got rid of a lot of the environmental hazards, and combined the ‘enemies’ and the ‘gold’ bags.

This is the game, as it looks, and honestly, is a little lame.  Especially for 3 weeks worth of work.  The main problem I will attribute to our group as a whole.  None of us were excited about this project.  It was just that to us, an assignment and not a game.  Furthermore, I took the ‘role’ of lead engineer (this wasn’t formally announced, but it sure felt like it), and I don’t feel that I was ready for that role.  I could definitely do a much better job now that I’ve experienced it at least once.

One of our engineers was working on AI (a pathing algorithm) the entire time that I should have told him to dump from 2 weeks in.  We didn’t even end up using the system.  Instead, towards the end of the project we were in “oh shit” mode since we had very little to show, and ended up hacking most of the game together.

Concrete goals to work on for next time: Better communication again (more specifically among the engineers), along with better SVN usage (we had problems with using our repo this time – E.G. one of our engineers never had access to it b/c of tech difficulties.)


Rapid Prototype 2.1 – Second Prototype

A new prototype and that means a new team.  And new restrictions.  Last time we had to make a game based on a toy that we received.  This time, we have to make a game based on an arcade game made before 1983 that had limited controls (only one joystick and a single button at max).  Furthermore, we have to use either Flash or HTML to code this, AND we only have 3 weeks instead of a full four.

We spent all of today figuring out which arcade game we should choose.   We narrowed it down to two choices, either Dig Dug or Joust.  Then we eliminated both and chose Bag Man.  We eliminated Joust because it was too similar to other games that we had worked on earlier, which seems fine.  But we eliminated Dig Dug because someone had done that the year before.  That reasoning doesn’t make sense to me.  We’re not here in Rapid Prototyping to do things that haven’t been done before.  We’re here to learn about how to properly prototype and to essentially learn HOW to make games.  Ah well.

We chose Bag Man, which is a game that no one has ever heard of, and I think it’s ok.  Nothing spectacular, but it does have some things to iterate on.  It is fairly ambitious game for us to prototype, which might take some time to get a basic build of right away.

Here’s the premise of Bag Man:  You are a criminal trying to steal gold bags and deliver them to your carts.  You move slower while carrying gold bags.  You lose if you are caught by the police officers patrolling around and actually chasing you.  You also lose if you fall too far.  Additionally, there are gold carts moving left the right throughout some shafts that will kill you if they hit you.  You can pull yourself up on some bars to avoid the mine shafts, and even ride them this way.  There are mining picks that you can use to stun the police officers, who will run from you while you have picks.  There are also elevators.

As you can see above, there are a huge amount of features to add, and it seems that one of our engineers will attempt to do all the AI for the police.  That seems to be too huge of a task, if you ask me, and I think we should just fake it.  However, he thinks he can get it done, so we will see.

Rapid Prototype 1.4 – First Pitch Week

First pitches were interesting, and not as bad as I thought they might be…  All around all the teams did very well…  This post will mostly be about the final state of our Bat Sim game.




Above is a screenshot of gameplay.  Many things changed from our original idea, but this is what made it into the final game:

Stamina bar (you only have so many “flaps”)

You can’t walk, only fly

Sonar ability that allows you to briefly see surroundings (zooms out camera)

Enemies that will kill you, along with environmental hazards (like the acid on screen)

End goal (which is a banana)


All in all, this was a good first project, that really showed me where I’m at professionally.  Our team lacked good communication, and often weren’t sure what each other were working on, resulting in some tasks not getting done when they should have been done.  This is one of the primary things I will be working on in the future projects.

Rapid Prototype 1.1 – First Prototype

Hello all, and welcome to my first blog post.  My name is Zach Lorenzen and I am an Engineer in the EAE masters program here at the University of Utah.  I will be numbering my posts as “Rapid Prototype X.Y” where X is the prototype number and Y is the week of that prototype (1.1 means week one of my first prototype;  Next week will be 1.2).  This weeks prototype was to be based on a toy that we randomly selected from a bag.  My team pulled a bag of rubber “creepy” critters including spiders, rats, and bats.

Throughout the discussion we attempted to garner the true fun of the toy that we had selected.  The purpose that I could see was to scare others, or to use as decoration.  And from that, we discussed the idea of a “decoration game” where the objective was to scare  the characters in the game.  However, at least to me, that wasn’t really a game.  That could be perhaps an interesting tool, or extension of the toy, but it would remain just that: a toy.  Not a game.

After further discussion, we reversed the thought process a bit.  What if we weren’t playing with the toy in our game, but we were the toy.  We discussed the idea of a spider simulator, a rat simulator, and a bat simulator.  We eventually decided on the bat sim, as that had the most unique element to it: sonar.  And that is what became our USP (Unique Selling Point).  In short, our game is a 2D bat simulator, where you explore the world around you collecting food using your sonar.

So far not an extreme amount of progress has been made on the game itself, partially due to it being Labor Day weekend.  On the engineering side we’ve spent our time setting up a repository, and figuring out how to use the system (MonoGame).  Beyond that, we’ve accomplished drawing sprites to the screen along with basic movements.  I’ve also figured out how to rotate sprites, which will be useful for a clock we plan to have in the game to keep track of time (bats are nocturnal creatures).

For the upcoming week, we have a large laundry list of items to complete.  We need to figure out how collisions (and how we are going to treat them), a time system (which we will use for game states such as beginning and end), moving the screen around, and other ‘NPCs’.  This next week will need to be a busy one to catch up on all the work that we need to get done.


Zach Lorenzen