Blog Post 8 – End of Semester

Hooray for the end of the semester! I think everyone is in need of the winter break — some time to relax and rejuvenate before the push to publish the game in the spring.

EAE Day has come and gone. Honestly, given that the showcase was planned basically two weeks in advance and that it was set for 2:00 – 5:00 pm on a weekday, I kind of expected a sparse attendance. But I was wrong! There were literally hundreds of people there, including friends, family, alums, and even a few big names from the industry working in studios here in Salt Lake.

Overall, I would say the showcase went pretty well. We put in a lot of work to get some of our new textures into the game and to get the levels we wanted to show polished to the point that they would be impressive. The game looked great, and lots of people seemed to enjoy playing it. There were a couple interesting takeaways:

-Kids really loved playing the game. This was somewhat unexpected as we thought that the difficulty might be a little too high, managing the placement of track along with driving, but they did great.

-We definitely had lots of people watching the game and cheering others as they played. This is promising for generating some attention on YouTube or other social outlets in the future.

-Many people wanted to see the pace of the game increased to promote constant driving. Right now, it feels a little bit like you ought to plot your course and then drive it, rather than the other way around. There are definitely some design elements that could be incorporated to make those changes, but I won’t go into too much detail here.

-People wanted more variety in terms of the tracks. This comment and the last may be at odds … in order to make the game feel fast-pace, the building side may need to be simple, and more pieces makes building complex.

-Turn up gravity! This was a great suggestion. Our car had a tendency to feel a little “floaty” which didn’t help on the jumps. We had fiddled with many details of the car, but we hadn’t changed the environment.

Anyway, we met on Saturday to look at some of the feedback before going into break, and the game looks to be in a good spot for next semester!

Blog Post 7 – More Pivoting

This was much needed, but we’ve changed our art theme. Obviously this means that we’re tossing a lot of our art assets, but that’s fine. They weren’t very good. We had been working with a candy theme, something that was [too] close to what is observed in Wreck-It-Ralph.

The impetus for this change was Mate’s presentation about how the candy theme was at odds with the fact that our game is a driving and building game. Candy themes tend to favor female and child demographics, whereas driving and building (along with our target platform of Steam) tend to be male dominated. We decided that it made more sense to change our art than to change our theme, and it turns out that most of the team was not really married to the candy theme anyway. Great!

The new theme, which was devised by building consensus rather than arbitrarily picking something (which is what happened with the candy theme). We decided to take a combination of two ideas that we liked: Southern Utah and Avatar … think canyons in the sky, driving through floating red rocks. It should look pretty great!

Blog Post 6 – IGF Done!

Super short post here. Just wanted to say that IGF is done! We ground out the work all the way during fall break, and we finished everything late on Saturday night. It feels amazing to be done with it, and the thing that we submitted feels pretty good. We’re going to be taking it easy as a team this following week to make up for the time we dedicated to project, and I think the time is well-deserved. Too bad our other classes continue to meet … =P

Blog Post 5 – Art Team AIDS

I haven’t really discussed this in previous posts, but our art team has been struggling for much of the semester. A lot of this revolves around interpersonal issues between Lawrence and Reilly, but to a lesser extent Lawrence and Adi. These three are probably the most engaged people on the art team — Pinakin simply hasn’t been coming to class on a regular basis for much of the beginning of the semester, and Earl has too much on his plate all the time between his family, other job, and various life events — and so the result is that their beefing makes the art team as a whole a mess.

The issue is that Lawrence is probably the most *productive* of the artists while Reilly is probably the most *artistically talented* of the artists, but also somewhat lazy.

We recently re-worked the art team to change the pipeline, granting each of the artists their own specialized task. That happened, however, at the beginning of the month. The recent snafu is that Lawrence finished a bunch of assets that were supposed to go through Reilly and Adi, and they’re upset that Lawrence took ownership from them. On the flip side … they didn’t get it done. We’re coming up on the IGF deadline, and we expect to be working all break (yay!). We need assets done, and I don’t want to hear bullshit from people over their “ownership” when they’re not putting in the work. I give priority to the person who actually gets the job done.

Blog Post 4 – Major Pivot


Recently, a big decision was made to change the direction of our game. The game is now a two-player co-op game in which one player builds the track while the other player drives it, tied together in real time. The basis for this decision was that it felt somewhat disconnected to have the player slowly build a track, as in a puzzle, and then drive the track after that.

Maybe this makes sense, but I’m not sure. This decision was made during a Saturday meeting when I was out of town, meaning that I was cut out of the decision-making process. As a result, a lot of the work that I put into the track builder design is going to be tossed out. Having a complex track builder doesn’t work whatsoever if you’re building in real time and in a hectic environment. Again, I don’t know if this is a good or bad decision to change to this feel, but we haven’t properly explored the idea that we set out to explore, and that’s frustrating.

The design for the builder side is going to be much more simplistic than it would have otherwise been now.  We’ll have to see what we can do with this new feel to make the user interface useful and engaging.

Blog Post 3 – Track Design

Update on the game design time!

We’re continuing to work at improving our track design system. I’ve been working with Lawrence on standardizing track pieces. As we work to expand the potential library of track pieces, it is important to map out the way in which those pieces can interact with one another. To that end, we’ve set a system of standardization along the way that track pieces fit with one another by tying them to a grid. Tracks are broken down into a cubic grid that accounts for standard units of width, length, and height.


The above diagram shows some of the standardization of the sizes as well as the proposed system in the user interface by which those pieces can be accessed. It breaks down the particular sequence of buttons that may be pressed to access each position. It is maybe useful to think of each of these points as a sequence in a tree. The point of this spreadsheet is to give our engineers something to use to build their own trees in linking image

The above diagram demonstrates the limitations by which pieces can be placed. Given the placement of one piece, what can by placed thereafter. Many of these restrictions are based on banking and by vertical change. Again, the aim here is to help the engineers when the time comes to implement this system.

All of this ties together with the user interface, which is part of why I am working on this problem. Right now we are envisioning a series of buttons on the left side of the screen that function as pop-ups giving access to all of these tools that lead to different track pieces. We’ll see how it turns out!


Blog Post 2 – Start of Semester

The game has gone through some pretty dramatic transformations over the course of the summer. So, as you may or may not know, the game was essentially focused on cars and destruction at the end of last semester. The player dropped signs along a preset roadway within the city, affecting the flow of traffic with the aim of creating spectacular car crashes. So … that’s kinda dead.

Over the summer, the team that was here in Salt Lake City decided to shift the focus of the game away from sign placement and into something with more direct control. At our play-test at the end of the semester, that was the crux of the feedback that we received. To that end, the decision was made to give the player the opportunity to control the driving aspect more directly. We currently have implemented a simple track building system in tandem with the ability to drive the car.

We are thinking now that the player will have the ability to lay down track pieces to create a sequence that leads the car through a number of checkpoints and resulting in some wild destruction. For instance, the player might drive his/her car through the supports of a building and knock down the the building with the ultimate crash. Thus, there is a mix of puzzle solving, driving, and crashing. Yay!

Right now, the user interface is a bit of a mess. The current system uses a radial selection tool that is very confusing for accessing the various track pieces. This is something that I want to put some time into solving.

Blog Post 1 – Austin

Before I get into the discussion of work for the project this year, I wanted to talk about my internship in Austin, TX. This summer, I was working for a start-up called CloudyShark, a company that makes social casino games for mobile devices. The founders of the company have a strong background in that field, having created Bingo Blitz and Zynga Slots (which were originally founded under the companies Buffalo Studios and Diluted Studios). They are making a foray into a previously uncharted market, creating a scratch card game for mobile devices. This is interesting in that it takes advantage of the obvious unique aspect of touch screen devices.

This being a free-to-play game had a clear need for someone to take over their work with analytics, seeing what players were doing within the game and why/how players fell off. Working for the company taught me an enormous amount about working in the F2P environment. I learned to use a number of analytics platforms, including Facebook Analytics, Unity Analytics, and Game Analytics. Each of these services has its own quirks and oddities … each service provides useful tools for investigating certain things and has gaps in other respects. For instance, Game Analytics and Facebook Analytics display retention data differently from one another. Facebook considers retention as an average of people starting from a certain date, whereas GA displays data taking the analyzed date as the basis. Let me explain by example. Let’s say you’re looking at D7 retention data on August 20 (today) for the date range of Aug 1-7. In FB Analytics, you would need to look at the date range Aug 1-14 to include all of the data points that were at least 7 days after the targeted time frame. Game Analytics automatically displays all the data relevant to the time-frame selected. Obviously, GA is better for this.

Anyway, I learned a lot about marketing, user analysis, and production pipeline in a small company (of about 15 people), working very closely with the leads. It was a great experience!

Semester 2 Post 16

EAE Day is done, and I think it was a huge success. We got a lot of useful feedback on the game and mostly positive reception. Certainly it gave us some insight into what we need to work on going forward, during the summer, but also it was just nice to have an opportunity to come together and showcase our work.

Check out the latest build: — oh actually, because of a recent update to Chrome, the Unity plug-in is broken. So please choose another b

Semester 2 Post 15

I helped conduct another playtest today, this one sponsored by an indie game promotional group here at the U of U. This was nice because the people who came were, I would say, more prone to gaming generally, and they have a different eye than those who just occasionally play a game and happened to be walking through the student union at the time we were there.

We also made some good contacts. Rachel is the girl who runs the Indie Game Promotions thing for the U, and we also met an undergraduate, Lanie, in the psychology department who is specifically interested in user research and how to conduct playtests. We will be tapping into those resources going forward.

It’s important to note that we’re taking user feedback with a grain of salt. Oftentimes, they can help you identify a problem, but their comments on the solution may or may not be so useful. It’s also very valuable to simply watch what players do with the game. If they are struggling, it’s important to identify how and why based on their behavior rather than what they exactly say.

We also now have to prep for EAE Day. The end is nigh!