TankXP VR: Drive a tank to fight aliens

8_got_em_sm

This weekend I spent 48 hours making a VR game for Ludum Dare #36 called TankXP VR. The theme for this competition was “ancient technology.”

“Oh no! An alien invasion! Time to strap on your Vive and show them who’s boss using your awesome tank. Unfortunately, your tank’s operating system seems to be a little out of date….”

Download TankXP VR for Windows & HTC Vive
*Requires at least the smallest Play Area size (Standing VR not supported)

Continue reading

Implementing Racing Games: An intro to different approaches and their game design trade-offs

mario-kart

If you search online for “how to make a racing game,” you get a bunch of tutorials teaching you one very specific (and very hardcore) way of implementing vehicle/driving mechanics. These tutorials are great if you’re making a realistic driving simulator or racing sim, but chances are they won’t even get you started in the right direction for implementing something that actually fits the constraints of your particular game project.

This article will introduce you to different approaches for implementing racing mechanics, while discussing how these implementation strategies may either complement or clash with your game’s core design. Continue reading

#LDJAM Game: Interstate 34

ld34-5
Hey guys, I made a game for Ludum Dare #34 this weekend, and it won the 2nd place prize for single-person entries at the Seattle Indies LD34 event! Here’s the link to the submission, and below is a brief description of the game. The rest of this post has some fun facts on how this game got made.

Beat up cars smaller than you to get points!
Don’t get hit by bigger cars or you lose your combo!

Download & play “Interstate 34” (PC, Mac, Linux)
Download the source code (Unity Engine)

Continue reading

How to Get Better at Teaching Yourself New Skills

To be honest, I always cringe a little when I hear someone say that they “taught themselves” how to do something. While the phrase has become a shorthand for saying “I learned this outside of the traditional classroom setting,” I can’t but help be bothered by the sense of arrogance that comes with the fact that it also seems like a shorthand for “I learned this without a teacher.”

There is always a teacher involved. Whether you learned that skill by reading books, following online tutorials, watching instructional videos, or reading articles online, someone had to create that content for you to consume.

One of the most amazing things about working in tech is that people tend to spend a lot of time either learning from others or helping others understand complicated skills. Anyone can become a “teacher” just by writing a single article or by giving a talk at a conference, and this promotes a really cool continuous-learning culture within the community.

But it worries me just how little attention we sometimes give to the teachers who create the content that we have become so dependent on for our professional development. Software engineers tend to take the availability and quality of this educational content for granted. Many people in this field describe themselves as “self-taught” rather than attributing their expertise to the individuals who they learned from.

This is a problem, not necessarily because it’s rude or self-centered behavior, but because we’re creating misleading expectations among students and upcoming engineers. We often trivialize how easy it is to learn new technologies by saying “oh yeah just do a Google search!” We act as if just any Google result is good enough to learn from, as if the quality of the educational content has no effect on one’s ability to master the material. We give off the impression that mastery is entirely dependent on our own intelligence, and so when students struggle, rather than questioning the quality of the content that they’re trying to learn from, they instead question their own intelligence and start contemplating whether they should just give up.

Continue reading

Magnet Ball Mega-Postmortem: How Learning on-the-fly Saved an Ambitious Student Project

basic gameplay

The following is my honors thesis, which is a research paper that I had to write in order to graduate with Honors from the University of Arizona. I had published the first two parts of this paper on my previous blog, but I have never published the full work until now. While I did try to adapt the tone of the paper to be more fitting for online reading, the paper is mostly unmodified, aside from a few major additions made to part four.

I’m going to warn you now; this paper is LONG. One of the goals when I was writing this was to show enough detail so that students who wish to try running a project like this could learn from our process and our mistakes. This project was a ton of fun, and I hope you’ll have fun reading about it.

Table of Contents

  1. Intro
    1. Abstract
    2. The Team
    3. Introduction
  2. PART ONE: Recruiting and Managing People
    1. Starting the Project
    2. Designing the Team Experience
    3. The Recruitment Process
    4. Unfortunately, Our Team was Too Big
    5. Availability and Communication Problems
  3. PART TWO: The Senses Project
    1. A Broken Pre-Production Phase
    2. The First Prototype
    3. The Second Prototype
    4. Turning the Project Around
  4. PART THREE: Pre-Production Done Right
    1. Fixing our Creative Process
    2. Rapid Prototyping and the Creative Process
    3. The Fruits of Pre-Production
    4. Prototype 1: Fighting Blind
    5. Prototype 2: Detonator
    6. Prototype 3: Particle Racer
    7. Prototype 4: Runner
    8. Prototype 5: Magnet Man
    9. Prototype 5, v2: Magnet Ball
  5. PART FOUR: Prototyping until the Bitter End
    1. Our Creative Process during Production
    2. Our Development Process during Production
    3. Thoughts on the Prototype-Centered Process
    4. Things I Would Do Differently
    5. In Conclusion

Continue reading