Category Archives: Rapid Prototyping

Work done in my first semester for a rapid prototyping class.

Yes. Best Game Yet.

I love our last game, Sumomentum. It’s my favorite game of the semester. Watch this trailer I made:

It was a huge hit in our final pitches and at the EAE Night open house. For our final pitch, we showed off the game by having the “1st Ever Sumomentum World Championships” between two of our best play testers. It was a big hit with the audience.

At EAE Night, our game was constantly being played and often had a crowd watching as well. I made a “List of Champions” and had it sitting out next to our game so people could record their names after five wins. I also set up a document that explained the controls and my team made it a desktop background on the computers the game was being shown on so that if our team wasn’t there to explain people could still enjoy the game. One kid sat and played it for a half-hour straight and almost refused to leave. It was literally the last game shut down at the event as the challenges just kept coming and people kept watching the matches unfold. Our professors, Bob and Roger, even got in on the action at the end, with huge crowd watching and cheering on the game.

This game makes me very excited for what we can accomplish with our thesis games starting next semester. I can’t wait to work on a bigger project and eventually publish. I feel like this semester has been great preparation and I know what needs to be done to make a fun, good game with a team. I’m very confident for my future at this point.

Here’s the Sumomentum team, Asia Punch Games. We were a good bunch.

teampicsmall

 

Best Game Yet?

We’re closing in on the end of the semester and the end of our final prototypes and I really, really like our game. It’s just fun, and I’ll be really happy to show it off at EAE Night on Friday and watch people have fun with it.

It’s encouraging to have the last game be the best. I feel like I’ve improved over the course of the semester and I’m more confident organizing and leading a development team toward a shared goal.

I’ll definitely have more to show you tomorrow with our game.

Faith in Engineering

Last night, we didn’t have a functioning game. We pitched this morning. Four weeks ago, I would’ve been sick all night wondering what in the world I was going to pitch from my team in the morning and how I could show that we’ve been working hard and a game is actually going to appear out of our mess. But last night? Nope. I have become a believer in engineering. I knew my engineers (Leo especially) could figure out the issues and have it ready. This morning I came in early confident that there would be something I could make a video and build a pitch around.

And it was true! My faith paid off! Leo had figured out our new dash mechanic we had discussed in design meetings and it’s every bit as fun as we thought it would be and more. And so now we can confidently put the art in and have a great little games on our hands.

AND THEN we start going crazy with level design and adding features.

It’s going to be a fun final week of the semester.

Baby Steps and Bounds

Once upon a time, a team got together and came up with a pretty decent game concept together. They were all excited to make.

Then, for two weeks, they basically worked on one single problem: multiplayer collisions. No matter what the promising team did, they simply could not get two dudes to punch each other on a screen and make the screen care enough to do something to the punched dudes. It almost looked like the entire concept was lost because those stupid dudes wouldn’t freaking punch each other. Then, one inspiring post-game design class meeting, the team decided to just throw away what they had and try again.

It took ten minutes to solve the problem.

Greg, who sits next to me in the lab, asked me today if I though my game was “coming along little by little.” I told him it wasn’t. It’s coming along baby steps by bounds. That’s kind of how game development has been for me so far. You get to the point where you think all is lost and there’s no way to fix the problem, then suddenly it’s solved in ten minutes and you jump two weeks ahead in your dev cycle.

It’s a pretty crazy world out here.

One Last Ride…For Now

Our final prototypes have begun! We got to pick our own teams this time and make whatever game we wanted as long as it’s in Unreal Engine.

I’m on a team with a good mix of people I’ve worked with before and people I haven’t worked with. There’s 8 of us this time instead of the usual 6 that we’ve had in the past, so I’m excited about what we’ll be able to accomplish.

The idea we’ve come up with is (working title) Practice Makes Deadly, a fighting game where you fighting style determines your characters stats. Basically, both players start as the same weak character and then start mashing buttons–but every button press results in experience gained in that action — running, jumping, punching, whatever–and the character starts to alter based on those actions. After a certain period of time, the two players are allowed to start attacking each other. Whoever uses their time more wisely and lands the best moves will come out conqueror.

We’re heavily inspired by other brawler-type games out there, especially Samurai Gunn, which other members of my team really, really love and I had never heard of it before today.

There’s a lot of passion and excitement from the team for this project, and already we’ve established roles and talked about process much more than my other teams, so production should be very smooth as well. As long as we don’t fall too in love with our own ideas, iterate, and communicate, I’m confident we’ll come out with a great game.

Rockstar Factory

Well, we did it. Rockstar Factory has been pitched and passed inspection and now we all move on to new teams. It turned out a lot better than I ever thought it could, especially last week when it looked like we had so little. I’m really proud of my team for all the work they put in this week to make it all come together today.

Have a look for yourself at how things looked by final pitch:

Pretty cool how it all came together–and they even managed to make it code in real time, thus different solutions can solve the same problem as long as the end result is right.

Afterward, we did our traditional postmortem, listing all the good and bad things that happened throughout the process of development on our game. Here’s the image of the white board we worked on:

PostmortemSmall

We summed things up into six main takeaways: 1. More solid design (meaning more detailed design in the beginning to get working faster and better). 2. Scope!!! (Keep it in scope). 3. Better visualizations of the design to guide everybody’s work. 4. Team programming. 5. Communication. 6. Don’t do everything yourself (goes with the previous one).

This was a great experience for me. I can’t wait to go into one last prototype and see what my next team and I can cook up.

 

 

Debugging Debugging

Work on our debugging game has come a long, long way and we’re making the final sprint for the final pitches on Thursday. We had a dry run of the pitches today and it went pretty well for us, but there’s a lot of work we need to put into this before Thursday to really get it ready.

I’ve been really proud of our team. Over the past week, we’ve really come together and found our groove to start cranking things out.

Specner had the awesome idea to make the rockstars in our game just be our professors. Have a look at them below!

bob corrine roger

There’s still a lot of work to be done, but I’m confident we’ll have a good showing on Thursday.

Going With the Flow

For the past couple weeks, I’ve been making a lot of flow charts. Like, a LOT of flow charts. Here’s four:

FinishFlow1 MakeBodyFlow1 MakeNeckFlow1 MakeSidesFlow4

Our game, Rockstar Factory, is coming on rather slowly, admittedly, but we’ve made some progress. These flow charts represent the different “functions” the player will edit in the game. They’re the “code” that will be broken and the player will need to fix in order to produce proper guitars. We have a playable first level, but we need to make these flow charts playable. Hopefully, everything comes together. It’s been tough because our artist’s wife just had a baby and one of our engineers isn’t here today, but I’m still confident in our team to pull things together by the time we have to pitch next week.

Rock on!

Design in the Box

Today we got a new team and a new assignment. This time, we’re supposed to make a serious game using Unity. Like last time, I am the only producer with three engineers and two artists (one of whom is a technical artist).

The idea we came up with that we all seem pretty excited about and dedicated to is a game that teaches non-programmer high school students the concepts of debugging a program. To do that, players will help a band who’s instruments are coming from the factory totally messed up. Players will look at the instructions the factory is using for the instruments, find where it’s not working, and fix it so that the factory starts making awesome instruments for the awesome band.

This is actually the strongest concept coming out of the gate yet for me, I think. I feel like everyone is behind this one even more than my first two prototypes and as long as we stay flexible and work hard we should have a pretty solid prototype come four weeks.

One reason for this success is definitely the design box session we had. Roger taught us today how the design box works, writing the technology, audience, aesthetics, and problem/mechanic then pitching only ideas that satisfy all those restraints. It went really well in our team for it being our first time trying it out. Here’s the results:

DesignBoxSmall

It definitely helped us to understand we were targeting high school students and we knew we wanted to appeal equally to boys and girls, especially since coding is still so male-dominant and we don’t want to reinforce that. It also helped us a lot to figure out how we wanted the user to feel–challenged, but empowered and smart when they succeed, included, accepted, and smart. I think if we can just keep this work we did on the design box in mind (part of my job as the producer, for sure), it’ll guide us to a much better game than we would have had otherwise.

Another One Gone

Well, Entropy is done! For now! We did our final pitch today. Here’s a for-some-reason-terrible-quality video of gameplay from the final (for now) product:

And here’s a look at the beautiful team that made it:

TeamTronSmall

After our pitch, we did a postmortem where we talked about everything that went well and everything we could’ve done better. Here’s our timeline of events (in practically unreadable handwriting–mine):

EntropyPostMortemSmall

The main points we came out with to improve our next prototypes were the following:

-Stay on task in meetings–don’t just turn every meeting into a brainstorming design session.
-Don’t be afraid to give feedback and ask for changes–even if they don’t all get done, they’ll help improve the game as everyone communicates more.
-Constant communication between all departments is key.
-Make sure you play to your team’s strengths, and make sure everyone always has something to do that they know how to do.

Overall, I really enjoyed this project and this team was really easy to work with. I think we made a great game together. The reason I kept saying it was done “for now” was because I hope to keep working with some of the team to change a few things and put it up for people to play somewhere. I’d love to share this game around to my family. We’ll see what we can do.