And We’re Done…for Now

Well EAE Day was a huge success. With lots of play testing and an incredible amount of feedback, we can move forward with a good direction.

Most of the feedback was about the objective of the game because we simply had people playing in a sandbox. I’ve been saying that our game should be more like Roller Coaster Tycoon, where it’s a sandbox with a mission. Each level has you working to accomplish some goal, whether it’s to make so much money in some time, get your approval rating, get one roller coaster with a high approval rating, etc. It’s still a sandbox, allowing you to do whatever you want with your park, but you have reason to be there.

This is exactly what our game has been needing. People love crashing the cars and watching the destruction of the city, but they were getting bored after a little while. Why? Because they had no purpose to do so, so once they did it, that was all they needed. Each crash was the same for them because even if one was more destructive than the other, they did the same thing to achieve it and it felt random.

Going into the summer, we’re going to keep working on Crash City every couple of weeks. We plan on revamping the game with missions, goals, objectives, etc. We should be pushing for more skill in the game. If there’s no skill, then there’s nothing to push for as a player. That’s what we’re going to try to add to the game.

Well, until next semester!

Preparing for EAE Day

So next Tuesday is EAE Day. That means lots of people walking around looking at all of our games. It’ll be great for getting public feedback, but it means we need to get this game up and running as best we can.

So like always, I’ve been tweaking physics, with a bit of side in some of the UI work to help our UI engineer.

And by tweaking physics, I really mean that I rebuilt our collision system. I was able to get access to some more information about the collision from Unity so I can use that instead of trying to ascertain it. For instance, I can get the point of collision and then apply an extra force on that point (as well as another vertical force and torque). This helps a ton because before, I was trying to determine which way a car would go based on which car hit what from where going how fast, etc. Overall, this is a lot easier and should also be more efficient. Yay! Double whammy with the rework.

I was also able to get our turns to start working more perfectly…I still am afraid to say perfectly. I set some standards. So a car with a height-width ratio of H, a speed V, going around a curve of average radius R, is going to have a specific ratio of those values; we’ll call it X…so X = H * V / R. I want to determine if a car should spin out of control and I determine this using X. If X is larger than some standard value, then the car spins out; if it’s smaller, the car makes the turn. So I simply used one of our cars and determined the point I thought a car would be spinning out. It’s not perfect, but it is definitely better than before.

I also ran into a bug where if a car was increasing or decreasing its speed during a turn, it would throw off our percentage. Since the percentage was based on a currentTime to maxTime ratio, and our maxTime was based on the current speed of the car, if we change our speed, the maxTime changes, which will throw the percent off. So we use a standard to increase our currentTime each frame by some amount based on the speed. This standardizes the increase in our percentage, without affecting how long the percentage takes to go from 0 to 1. Proportions are pretty important things. That fifth grade math helping out the math major in his game design master’s program. Shit’s useful.

Well, that’s about all I did this week to get ready for EAE Day. It’s drastically improved my contribution to the game though, so that’s nice.

Until next time.

And Now for the Main Attraction…


So last week, I talked about the turns and how I accomplish getting cars to make very different kinds of turns, so now, I’m going to talk about how I handle the collision between two cars.

In real life, cars have many different shapes to them. Some are tall, some are short, some are high, some are wide. All of these different shapes can cause lots of interesting crashes, with some cars getting pushed up, while others are simply pushed out. It’s extremely complicated and is in no way being replicated in our game.

So what are we doing for our crashes? Well, simply put, we’re going crazy. Our cars might have different meshes, but all the physics sees are boxes. In terms of physics, our cars are literally just different sized boxes (well, really same sized boxes since we only have one car currently). So when two boxes on the same plane collide, they simply push each other off, rebounding but staying in the plane. That’s great and all; it’s what should be happening…in real life, but in the world of Crash City, that’s just not good enough.

To simulate real life a bit more, I add some vertical velocity when two cars collide and I also apply a torque. I’ve found that fine tuning the vertical velocity and torque components is a lot of work. If they’re too much, then the cars will just fly away from the city and never interact with the buildings. If they’re too little, the crash won’t be exciting…plus, they probably won’t collide with buildings. It makes it even more complicated because I use the impulse of the collision to determine how much velocity and torque to add. This means that little fender benders will stay little and won’t be exciting in the slightest. Granted, I don’t want a car flying away or even getting hit a block away with a small fender bender, but the car should still go far enough to hit a building.

I also needed to make sure that when a collision happens, the car’s engine turns off in a sense. I don’t want the car to still be driving if it’s been in an accident. And if a car gets knocked into the air and then falls onto another car that’s already collided, they should act more like a normal collision; they should NOT go flying again because then they’ll never stop. I also had noticed that cars would fall and that was the end of the collision; it was boring to say the least. So I added a bit of bounciness to the roads so that cars will bounce along and have a longer “death” time. Way more exciting that way.

So that’s how I handle collisions. I’m sure there are better ways to do what I want to do, and I’m going to keep looking into. Hopefully the entire system won’t change, but if it makes the game better, so be it.

Until next time.

Physics + Physics + Physics + Math = Lots of tweaking = 3Physics + Math

So I’ve already said how I’m constantly tweaking the physics. I thought I would share with you exactly what I do.

When I say that I work on Physics, I mean that I code anything involved with a car’s movement. That includes its acceleration and deceleration, its turning, and what happens when a car crashes with another car or a building. Some of it is super simple (acceleration), while some of it is slightly harder.

The turning has definitely been a thorn in my side. Anytime I think I have turns working, something else comes up, and it no longer works for that case. That’s just programming. With turning, I have a public function that the AI can call that would initiate a turn. The AI passes in a distance vector as well as a rotation in degrees. So if is at (1, 1, 1) with a rotation of 90 degrees and wants to end up at (2, 1, 3) with a rotation 180 degrees, the AI only has to pass in (1, 0, 2) and a rotation of 90. Pretty simple and easy to use on their part.

I use that information to build a curve from the starting location to the ending location that also takes into account the rotation. I calculate the length of the curve and determine how long it should take to make the turn based on the speed of the car. From there, I start a timer and calculate how far along the curve I should be based on the time as a percentage. I can then pass that percentage into custom interpolation functions I made for the sin and cos functions. Because a simple curve can easily be built using sin and cos functions, it made sense to use them as the basis for new interpolation functions. See where the math comes in? From there, it’s really easy to have the car move along that curve.

Things are still a little janky, but that’s ok for now. I’m going to keep working on it to make sure the speeds are consistent; plus, I’m going to need to make it so a car to spin out of the turn if they are going to fast.

Until next time.

I’m quitting

April Fools!

So since last time, we held a type of game jam on Saturday. It went well, although it wasn’t very game jammy. Our intention was to split into 3 groups that would prototype the game in different ways. One team would work on the current game; another would paper prototype it, and the last would build the game anew, with a new direction to see how things would go. Well, we mostly just did a small paper prototype and then fixed bugs and prototyped new signs. It was productive…just not what we intended.

The physics of these car crashes keeps getting better and better though at least. What I’m attempting with the physics is a more enhanced version of our universe. Bigger crashes, more velocity, more torque, etc. I’m accomplishing this by using Unity’s physics engine and collision detection. When a collision happens between the two cars, I basically just add to their velocity and apply a torque so they go farther, faster, and spin. It’s way more entertaining.

I also work on the turning of the cars as well. I see the AI as the driver and the car’s physics as the engine. So I’ve been working on a system where the AI will tell the car to turn, passing in how far away they want to go (as a Vector3) and how much they want to turn (as a float in degrees). The car physics will then create a curve that it will follow.

Overall, it works ok. Needs to be tweaked and worked on more, but it’s sufficient for now. Eventually, I’m going to need to make it so the car will spin out of control if it’s making a turn too fast.

Well, until next time.

Back to Work

Well after a week of GDC, a week of work, and a week of Spring Break, it’s back to the normal flow of things.

In our week between GDC and Spring Break, the team discussed the game, the feedback and impressions we got from GDC, and where we want to take the game.

Like always, I’m tweaking the physics of the game. Will it never end? Lol. Oh well. I enjoy it, even if it is frustrating sometimes. We are also planning on doing a game jam on Saturday to get a lot of quick iteration into the game. Overall, I think it’s a good plan. We need to iterate a bit more because right now, we have an idea of a game, but no game.

Well, I’m going to keep working on physics, but hopefully after this I’ll get to do some procedural generation or AI.

Until next time.


And it’s over.

I am now done with GDC (does C stand for crazy?).

GDC was absolutely incredible to say the least. First off, San Francisco is a great city. The weather was awesome. We had tons of fun. I got to hang out with a lot of my friends and got to know them better even. Team building, right???

But now onto the important things: GDC…

So I had the Summit, Tutorials, and Bootcamps pass, so I was busy on Monday and Tuesday running around, trying to get as much as I could. Monday, I went to many different talks given by various people in the industry. I tried to go to whatever I found interesting, so that included math talks, AI talks, and even some writing talks. Overall, great talks. I woulds highly recommend looking at the Funky 1-D Transformations lecture on the GDC vault if you’re into math, really great talk. The few AI talks I went to were also really interesting. One of them definitely introduced a new way of looking at AI. The writing talks were great. The Comedy Games talk given by Zoe Quinn was incredible. It was really neat for me because I’ve learned a ton about comedy from my sister since she’s a comedian.

Tuesday was a very different day. While Monday was entirely about learning (it was hard for me to meet people on Monday), Tuesday was more focused on socializing and networking. I decided to go to the Game Design bootcamp. In the bootcamp, we split into teams and were tasked with paper prototyping a key concept of a game of our choice. I worked with a team on Katamari. First off, tons of fun to paper prototype because let’s face it, Katamari is awesome. The team I worked with was also great. It helped that we all chose to do Katamari so we were on the same page a lot of the time. I met a lot of great people thanks to this bootcamp. I would definitely recommend doing bootcamps to anyone who wants to network. It helps.

Wednesday, Thursday, and Friday were all about the show floor and networking. I went around to every booth and talked to hundreds if not thousands of people. I would pitch them Crash City, give them my card, get their card, listen to them about their game or technology…it was tiring to say the least.

Then there were the parties. It’s a good idea to go to these, but you have to be social. You’ll meet people, and talk to them and tell them about you and learn about them and discuss whatever. It’s good to do. Just a word of advice…if you manage to get into an invite-only party that you’re not invited to…don’t tell someone that you’re not invited. You won’t get kicked out, but chances are, some people won’t really appreciate that since they were invited.


Anyway, till next time.


So I realize that last time I spoke to you, I completely forgot to mention what thesis project I ended up working with. Even though I didn’t care TOO much for the game, I absolutely loved the group. It’s my friends; we can speak directly to one another; and we’re just going to have fun. So I decided to work on the traffic game, Crash City.

Elevator Pitch: Crash City is Burnout set in a reverse-Sim City environment, where you place and remove traffic signs to cause the most insane crashes imaginable.

Since I have a background in math and physics, I’m going to be focusing on our crashes. My title is the Crash Designer; I even have a business card that says so. We played around with it, created some awesome little tech demos but we don’t have much of a game yet. We’ve been really busy preparing for GDC next week.

We decided to go all out as a team. We have group business cards that have the game, our game website, etc, as well as our name, contact info, and title. We’re all ready to give our elevator pitch to anyone and everyone. Overall, I can’t wait. It’s going to be awesome.

So 4D didn’t make it. I’m…extremely disappointed. I was hoping that even though the industry panel didn’t get it, that it wouldn’t matter. After all, they’re in the industry and care about marketability. We went into this game not giving a shit about marketability. We wanted to be experimental and do things that haven’t really been done before. Sure, if there’s a market for it, awesome, but if not, oh well.

The industry panel didn’t think like that.

It’s also annoying because Bob’s journey through our game perfectly exemplifies what we wanted. At first, Bob did not understand our game. With our practice pitch, when he saw more, he understood it more but still didn’t quite get it. For the industry pitch, Bob fully understood it. He reached that “ah hah” moment that’s so amazing to get when you’re playing a puzzle game. If you go into a puzzle game with the “ah hah” moment already having happened, if you go in knowing everything, then it’s no longer a puzzle game; it’s a “Here do something” game and it becomes quite boring. When you don’t fully understand everything but are trying to, it becomes fun. And when you reach that “ah hah” moment, there’s nothing quite like it in games.

So even though the industry panel didn’t get it, I don’t care. That’s fine. That’s part of the process and part of the fun of the game.

I’m going to keep exploring this game on my own. I’ve got ideas for how to improve it and make it better. 4D as a game is an idea that deserves to keep being explored because if you’re not exploring, you’re not moving forward. And without progress…well, I just don’t give a shit about standing still.