Cool Stuff!, Game Dev Adventures!

Game Projects I: Week 8 — Crunch Time

One week to industry panel! We knew this game was going to be difficult to make, so no one was surprised by the amount of work left to do before the industry panel.

At this point I had had conversations about how to do the ghosts on several occasions with Owen, Binoy, and especailly Shane who was always more than willing to help out with creating meshes and art whenever we asked. I was having another such conversation, drawing up problems and possibilities with Sean, Owen, and Ryan, when my fellow mathematician, Skip Fowler, listened in to our conversation and we started talking about how I was going to calculate the metrics for the ghosts and place them in the scene (neither an easy nor straightforward task). It started like this.

Skip: “How are you going to do that?” Curious.

Me: I explained several of the issues of with having to place an object on the scene when it’s position is determined dynamically by two different sets of inputs but is also reliant on track position.

Skip: “How are you going to do that?” Truly pondering the scale of the problem.

We then talked lengthily about the mathematics behind calculating the metric of distance in R3. Thank goodness for his real analysis background. The solution, long term, is line integrals! Genius! Knowing the answer in myself, but wanting confirmation I asked Skip if I could do it in a week. He laughed and shook his head. “No way.”

All righty then, back to where I was at. I had to come up with a cheat.

The other issue was placing the car on the track. Once I knew the metric I was also having issues placing it in the right position. It was a continual issue.

Shane had designed a new 3D track and Binoy had conquered the flip turns, at least enough for a playable demo. So it was my challenge to get the ghosts in the right positions.

I spent the weekend in the lab. Shane was often there, and at times Binoy, but mostly Shane. Brad joined us as well to make videos and prepare the slidedeck for the presentation.

I got a little frustrated with not being able to get something to work. Shane’s new 3D track allowed me to still cheat the metric easily: z-displacement. But it also introduced a huge problem: Now the rotation of z was also dependant on the relative position of the player to the track. Calculating the rotation of the ghost dynamically had already proved a problem earlier in the process and it wasn’t proving any simpler.

So I decided to add something flashy. I gave both the cars trail renderers and added some particle effects to the car that was in the lead determined by the same metric as the ghosts. The trail renderer added another visual cue to the player about where their opponent had gone if they were behind by only a couple seconds. And if they were “in the lead” the particle effects gave them a visual cue for that as well. The two together added to the ultimate goal of communicating to the player their relative distance from their opponent without using a HUD, and added to the overall head-to-head feeling.

I then returned to the issue of the ghosts and HUZZAH! At the end of the night with some creative ray casting (at least I thought it was creative) and special meshes from my artist I got the ghosts to follow the correct path! WHAT!!! It was so exciting! There were several cheats still in play, but it was working in 3D space.

Advertisements
Game Dev Adventures!

Game Projects I: Week 7 — Art/Script Issues

When I made the ghosts last week I made them with rectangular prisms. Getting them to behave correctly when I got cool transparent art from my artists was a bit of a mess. A lot of the rotations on the cars and track were messed up and it took me several working hours with Shane, my artists, and Binoy, my fellow engineer, before I got it working with Shane’s art and my, now edited scripts. I couldn’t go through and edit any of the player ones because they were far too complicated compared to my ghost ones, so that’s why I chose to edit mine. While I was at it, though it wasn’t essential to gameplay, I also removed player1’s ghost from player1’s view. It really wasn’t essential, but I kept getting comments out so it was important to the player. I also toyed with only showing the ghost when the other player was only so far away. It made it harder to script and sometimes it didn’t feel right. I ended up confusing myself multiple times as well and had to call others over to ensure I was doing it right. I don’t think I explained before, but we made the game a two player game with one player on the split screen on top and the other on bottom. I might have made a little more sense to split the screen vertically, but I probably would have gotten confused anyway. In play tests it was really fun to play and watch others play. The ghosts definitely added the fun. When they weren’t there it wasn’t nearly as fun to play.

Binoy had to tough job of writing the flip turns. He’s great to work with. While we tried to figure out our own issues we sent each other links and talked over ideas. I was always glad I didn’t have to do the flip turns until I remembered I had to do the ghosts.

However, I don’t like calling them ghosts. It bothered me from the beginning to call them that. I suggested “ripples” which I didn’t like, but it better explained what hey represented. When you tell a racing gamer you have ghosts in your game they have a very particular idea of what that is. I began petitioning for a name change. Owen was really sold on Ghosts already so I decided to continue just dropping hints of changing it since I hadn’t really come up with a good name anyway.

Cool Stuff!, Game Dev Adventures!

Game Projects I: Week 6 — GHOSTS!

Being sick over the weekend I was seriously panicking. I had no idea how I was going to write the ghosts.

The problem with the ghosts is that there position is dynamic: depending on input from the player for different parts of their positioning, and then they have to find the track.

For instance: let’s do the ghost for player one.

So player one is at

  • p1=(x,y,z) and rotation r1= (x,y,z).

Player two is at

  • p2=(x,y,z) and rotation r2= (x,y,z).

For ghost one (the ghost for player one), we need determine AT RUN TIME the following:

  • g_p1 = (x, y, z), and g_r2 = (x,y,z)

Problem Rotation: we wanted the ghost to mimic the rotational movements of the player. So if they were moving left, right, or had flipped over, we wanted to show that on the track.

Solution Rotation: So rotation, in 2D space, should be g_r2 = r1 for x and y. We don’t have to worry about z rotation because the road is flat (we’re not in 3 space). Only you do want to show when a player crashes, so z rotation of player1 does matter. Aye, aye, aye. I just assigned g_r2 = r1 in 2D space for now, but this became a major issue in 3D space.

Problem Position: The position of the ghost should somehow measure the distance that player1 has traveled on the path player2 is on if he’d taken the same path as player2.

Problem Metric: How do you measure the metric and what should the metric be?

I had several long conversations about what the metric would be with many different people many different times. In fact, in two different talks with the professors we talked ourselves around to the others ideas, which left me back at square one. What is the metric. Here were all the ideas I thought of and considered. The ones I thought would work the best were from start to current, or relative closest behind.

  • The ideas ranged from
  • Measuring the distance traveled from the beginning to the current position (easy)
  • Measuring a relative distance to the other player by measuring backwards to the closest fork and finding the best path
  • Measuring the best, worst, or average distance to the end.
  • Use some type of displacement

Solution z-position: For this I called in help from a friend. Ben Driggs came over late and we discussed the issue. Since the race I was making happens mostly in 2-space he suggested making the metric the displacement in z. Not a true measure of distance, but a place to start!

Problem Position x,y: While this gave a resolution to the z problem, it didn’t solve x and y. I didn’t have a lot of time to figure something complicated out, and since player2 is the one that needs to see the ghost I slapped on the ghost’s x,y as determined by player2. This meant that effectively player1’s ghost “floated” in space (the backdrop of the race was in the air!), but it gave an excellent place to start for play testing to see if the ghosts were fun at all.

So to sum up:

  • g_r1 = r1
  • g_p1 = (r2.x, r2.y, r1.z)

We also had the art added in with arrows, landmarks, and a finish post. It made the race super fun. We found that having the ghosts on the path with us did provide that head-to-head feeling of having other racers with you and still allowed for you to choose the path you wanted to go on. So the demo was a success.

Helping Hand

Getting Started Using Git: A Very Brief Overview of Installation and Set Up for Reference

This is a very brief overview of installation and set up of git for reference. This isn’t for teaching you git. I’ve found that as I’ve taught people git these are the things I constantly had to look up or have them look up just for getting started. So I thought I’d make a brief overview of the steps to make everyone’s lives easier.

For information about git resources, including a book that can teach you all you want to know about git, I have a post about that here.

Important note: some of these steps are specific to the gitlab git server repository. If you are using a different repository check their documentation.

Git Installation Overview:

Basically all you need to do, for Windows, is download git from git-scm.com. Install git bash (which will be your command line interface), and git gui.

Git Set Up:

Set your user name and email. These “tag” your commits. In git bash:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

At this point you can start using git locally. If you don’t have a git repository there is nothing further you need to do for set up. The rest of the article is for connecting to (in this case a gitlab repository) git repository to push (like SVN commit) and pull (like SVN update), and lots more for easy collaboration among your fellows.

Connecting to a Remote Repository

Create your SSH Keys (You can add multiple):

(Should match your email from above)

ssh-keygen -t rsa -C "your_email@example.com"
  • The default place to save is correct (unless you’ve changed your settings) so just hit enter.
  • If you want a passphrase enter it followed by an enter twice. Otherwise hit enter twice.

The ssh key will now be saved in your user folder under “.ssh”. By default in Windows this will be in your user’s directory. Open the idrsa.pub file and copy the whole thing.

Save the key in your repository.

In Gitlab go to:
My profile -> Add public key
paste the entire key in the “key” box. Title will auto fill.
Select “Add key”

You should now have ssh access to the git repository and will be able to push, pull, clone, etc.

Make/Update your server repository

If you have a blank project: Clone/create a new repository:

Navigate/create the directory where you want the cloned project to go. (For SVNers, this is like checking out a project.)

In general, to clone from a repository via ssh the command is:

git clone git@:/.git

For example project it’s this:

git clone git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git

Once that is done, you need to create a local repository and then tell local git where your origin is. Git won’t make an empty repository unless you tell it to. So make a dummy file and add it to the repository and push to origin and tell git to track the upline:

cd project_folder
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

If you have an existing project (but not a git repo)

cd existing_project_folder
git init
git remote add origin git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git
git add .
git commit -m "Initial commit"
git push -u origin master

If you have an existing Git repository

cd existing_repo
git remote add origin git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git
git push -u origin --all
git push -u origin --tags

The “-u” in the “git push” tells git to track the branch on the remote branch. In future pushes then you don’t have to tell git which branch on the origin to push to. Just do a “git push origin $branch_name”.

Update your remote url

Sometimes your remote url will change. (curse the techs right?! 😉 )

To check your remote url run

$ git remote -v

This will list any short name remotes along with their urls.

To update run:

$git remote set-url  

If you need more details the

$ git remote set-url --help

is in fact very helpful.

Good luck! 🙂

Let me know if you find anything that is incorrect or other important startup commands to get going. I’m happy to refine. 🙂

Game Dev Adventures!

Game Projects I: Week 5 — 1st Playable

Not much to discuss this week really. We got up a working raceable game in multiple 2D paths. (I pitched the idea last week to keep it 2D to make the ghost NPC simpler to write in the next sprint.)

Through play tests we quickly realized why racing games have start and finish lines, land marks, and arrows on the road. Without them you’re only point of reference is the car beside you. Because everything else looks the same, regardless of the speed you’re going it feels like you aren’t moving, if you get turned around you don’t know which way is what, and you quickly get bored because you just don’t know. In the next sprint we knew we had to add these points of reference.

I got sick again Thursday through Saturday. I’ve been having some stomach problems, so I spent most of the rest of the week in bed.

Game Dev Adventures!

Game Projects I: Week 4 — Prototypes Begin!

This week we began work on the prototype. The game I am working on is Ragwheel, a racing game. Our thesis question is, “How can you maintain a head to head racing feeling with multiple paths?”

It was interesting because we had the basis of racing games that we could pull from that we needed to set up, but there are very interesting art, engineering, and design challenges that will probably take us through the entire prototype to really nail down:

  1. Track design: this is a multiple paths question. Do we have multiple endings, do we add in obstacles, should parts of the track be random, how do we do randomness well?
  2. Ghosts: these represent the relative position of your opponents if they had chosen the same path as you. The issues here are: what kind of interactions do the ghosts have with the players, how does the jumping (if you lock onto a player’s ghost for so long and then they or you take a shorter or longer path, both cars get jumped) work, are ghosts fun, what paths do we put them on, how do we calculate where they should go, etc.
  3. Flip turns: these literally, or figuratively?, flip you to the underside of the track. Their purpose is an interesting way to create multiple paths. The challenges here are how to design the track with flip turns, how to manage gravity (especially during the flip), what to do about car’s momentum and speed during and after a flip (and other physics considerations), how a flip is triggered, what about cars that don’t want to flip, what kind of flips are there, do we animate the flip turns or do it real time?

It took us practically the entire day on Tuesday to get far enough along for me to feel like I knew where we should start. As flip turns don’t answer the question of the thesis but are just an extension of how we can create multiple paths, and where we weren’t even sure if the ghosts would be fun, I pitched making a really simple 2D track with no flip turns (because of all the aforementioned issues with those), to test whether or not the ghosts were feasible and fun. The team agreed and we started on that. Flip turns then took a third priority to ghosts, and just getting a basic racing game down with a 2D multiple paths track became our first sprint and what we worked on for the week.