So I had some free time today (read: I had 3 papers to read for my MBA 290 class). Cruising around reddit, I found this thread. People basically tried to take an informal poll. Seeing an interesting coding challenge, I spent a few hours writing scripts to extract the data and spitting it out as a pie chart. These only take into consideration the top level comments, but I have all the data for deeper levels – I’m just not sure how to display the data. For the technically oriented, I used python, reddit’s secret .json API, and the google charts API.

Additionally, I realized that I still have the drive for coding – I just need an interesting problem for me to solve.

Here’s the final video that I made a few months afterwards, showing most of the cool stuff from my project. There’s so much more that could’ve been done to make this better, but I lost interest after my summer internship started…

Yay, yet another productive day of development I love this feeling. I wonder how long I’ll have this energy to do all-day development before I burn out…

Boxes and Collisions

First, I added boxes to the scene as obstacles. I figured it would be a good idea to create a unit cube (1 x 1 x 1) and scale it in the X, Y, and Z directions as needed. I would also need to create a bounding box to do the actual collision detection, since XNA doesn’t provide a bounding box by default. The code to check for bounding box collisions with spheres wasn’t too difficult (I used a game physics books I picked up at the library), but for some reason the balls were sinking into the box before bouncing out. Weird. I decided to draw the corners of the bounding box using green spheres as markers, and this is what I discovered:

strange scaling issues, wtf?

What’s going on here? Apparently the unit cube I exported from 3ds max wasn’t really a unit cube. I went back and double checked my cube but it seems perfectly normal. After racking my head a bit, I couldn’t come up with any valid explanation. I ended up using Maya to recreate a unit cube, and I imported it into my program without incident. I’ll have to investigate this further since it could cause more problems down the line. So now, I have balls that collide with boxes, which can be overlayed on top of one another to create some interesting designs.

box with collisions

stacked boxes

While implementing collisions with boxes, I decided to switch to a more formal approach to collisions. Before, it was a bunch of ad-hoc vectors and names all over the place. I implemented a ContactInfo struct, which contains a contactNormal and a penetrationDepth. These two variables allow me to do collision response separately from collision detection, and it makes things much, much cleaner (removes a lot of duplicate code). I also discovered that XNA has a handle Vector3.Reflect(direction, normal) method, which allows me to easily reflect a ball off of a collision contactNormal. Penetration depth is used to separate two objects that are in collision. Most of the time, you just move the object by (contactNormal * penetrationDepth) to get to a stable state.

Multiplayer

The second part that I finished today was multiplayer. Games are so much more fun when you can shoot at your friends This involved setting up the correct viewports for each player, in addition to setting player colors, and only rendering the path tracer for the current player (we don’t want player 2 to see player 1′s firing arc, otherwise it’s too easy to dodge and it clutters up the view space). Right now, all the health bars and status messages are still rendered at exactly the same size no matter how many players are on the screen. I’ll consider shrinking it, but for now, it seems to be okay.

multiplayer

Special Effects

Next was explosions and sound effects, which I stole from previous projects. Explosions are based off of the XNA particle system sample, with some minor tweaks. Since I’m using XNA, I used the XACT Audio Framework for doing my sounds. One of the cool things about this is that I can play a sound, but have it be a random sound from several different files – all done at the sound effects project level. So as a programmer, I don’t have to care how many files are behind a specific “sound”, I just play that sound and watch the magic happen.

explosions

Camera

Last, I implemented a free camera that can view the scene from any direction. If you press ‘Y’ while in a game, it’ll switch from the tank-following camera to a free-floating camera. This allows me to view models and effects from angles I wouldn’t normally be able to see.

free camera

That’s all for today. It’s finally starting to evolve into a playable game (luckily, since there’s only 3 days left until it’s due). Coming up next – shadows.

Finally, I get a day to work undisturbed, and I’m glad to say that it really brought back some good memories of my previous years of game programming/modeling (in addition to being insanely productive). Three parts to today’s update – gameplay, the tank model, and terrain.

Gameplay

After thinking about it for a bit, it seems a bit weird to have the balls only do damage on a direct hit since the chances of a direct collision are pretty slim in a 3D world. I was brainstorming about different possibilities – magnetic/gravitational force towards the enemy, have the ball explode when the enemy comes close to it – but none of those really felt like nice solutions. In addition, I wanted to keep the bouncing factor, since that’s one of the cooler parts of my program compared to other projects. In the end, I came up with a hybrid solution, which says that a direct hit will result in an explosion, but otherwise it will continue bouncing until it is at a rest position. Hitting the left trigger will remotely detonate any balls of yours that are left on the field and cause damage to any enemies that happen to be in the area.

Secondly, the days of infinite ammo are gone, and you must now pick up ammo from the ground – any white sphere at the moment. This will prevent people from just sitting in one place and firing off balls at their enemy without moving – it makes for a boring game. Lastly, I picked up a health bar that we created from a previous project which we spent quite of bit of time on. Yay for code reuse!

Modeling a Tank

So the fun part of today – I spent about 3 hours modeling and texturing the tank. I’m currently using 3ds max for my work, but I’ve used Maya in the past. First, I had a friend draw out perspective drawings of the left and front sides of the tank (top view is also useful).

left side of bunny tank

front of bunny tank

Then, I placed those images into 3ds max as textured planes as guidelines to help me model. It’s very useful to have something to go off of when you’re trying to visualize a 3D object.

Next, I unwrapped the UV coordinates of the model, a step which takes a hell of a long time, but it is a necessary step. Here’s the completed UVW map and the associated texture file that I created really quickly (I was eager to see my tank in action).

UVW map of my tank

quick ugly texture using the uvw map I just created

So much work for one model, and it’s not even close to done – still have a lot of detail to do with texturing and there are definitely spots I could improve with modeling. No wonder art departments for games consist of tens of people. Lastly, I drop in the model in my game world, and now it’s starting to look a bit closer to a game as opposed to a tech demo. I still need to offset the tank off the terrain so I can see the bottom of it, but that’s a quick fix that I’ll do at a later time.

Terrain

Adit implemented terrain over the past few days, and the balls are correctly using the heights on the heightmap, but the normals still need some work. Here’s a quick terrain full of “grass”. Some things we’re going to work on are mip-mapping and terrain splatting.

Comments from anyone are always greatly appreciated, both from a graphics standpoint and from a gameplay persepctive :] Less than a week to go!

This is the first in a series of updates for my CS184 project, now codenamed Cirrus. I constructed the ground plane as a giant quad (in reality, it extends out into infinity). The large sphere is the ‘player’ at the moment, and the small spheres are balls that you fire.

Additionally, I implemented a quick path calculator to see where the ball would land. I had a choice of using several controls – adjusting firing angle, firing speed, or the target location – to try and determine how the ball would fly out and interact with the environment. Changing firing angles would be fairly easy to implement, but I would need to settle on a constant speed. Some consequences of this are that the ball will travel very fast even for a close target and that there is a maximum distance that the ball can travel towards. Changing firing speed is also easy to implement, and consequences include the fact that nearby targets will be hit with less speed (less realistic for a cannon) and that there is a fixed firing angle. Finally, setting a target location involves a two-dimensional control (angle and speed were both one-dimensional), but would allow for the most accurate targeting

However, setting target locations suffers from a major problem in that there are infinitely many solutions for a firing angle and speed. It is still possible to use this (you would need to use a 3rd dimension to set the firing speed or angle), but I determined that it was too much for my current project. In the end, I decided to implement a firing speed changer with a fixed angle. This part of the code shouldn’t be terribly difficult to modify, and there isn’t really a reason I picked this method over the other.

In addition, I used the initial velocity and position of the ball to create a highlighted path for the ball, assuming no collisions with anything other than the ground plane. The following images show what it looks like when you’re trying to figure out a firing solution, and the ball as it travels along that path.

And now we come to collisions, the coolest part of the project so far. I implemented inelastic collisions with a coefficient of restitution of 0.9 for the time being. Inelastic collisions are collisions in which the two balls travel in the correct direction but with slightly less energy post-collision (in my case, exactly 90% of the incoming energy). It’s pretty fun to see the balls bouncing around all over the screen colliding with one another. It’s a shame that my plane is infinite right now – a box would be much for fun to play with.

There was one problem that I encountered along the way, which was the fact that a ball could ‘stick’ to the top of another one. An example would be when two balls are stacked on top of one another with zero velocity. The ball on top does not roll off smoothly – in fact, it tends to stick for several seconds before finally bouncing away. The reason is that if both balls have very little energy, they will not go anywhere very fast. There is another class of physics that I do not attempt to model right now, and that is contact forces. The symptom of that is two balls on top of one another will experience a series of mini-collisions and eventually fall off, but it does not look realistic at all. For now, I will not attempt to fix this problem since I do not anticipate much stacking in my final game. There are much more interesting things to focus on for the time being.

Balls colliding (notice no intersecting balls)

Finally, I managed to test it out on my Xbox360 successfully. Getting it set up was entirely painless, and I’m impressed by the XNA team that they managed to get remote debugging working so well. One issue that might be a problem is that I currently don’t have a wired controller, so I can’t actually test a controller with my laptop when I’m not at home. It’s sad that they no longer sell the Xbox360 wireless receiver as a standalone product; it’s bundled together with a wireless controller and you’re required to buy both for some reason (go marketing). I’m really excited to actually be able to demo on an Xbox on demo day :]

Pretty slow for a week’s worth of work (distracted by TBP mostly), so I plan to use this coming week to go all out and make this a reality rather than a concept on paper. Stay tuned for updates – shadows will be next.

Yay, I received approval from my instructor to write my final project for CS184 – Computer Graphics in XNA! Up until now, we’ve been using OpenGL with C++. It’s been a nice foray into an alternative graphics stack, but I just can’t stay away from XNA and C#. I’m going to document my progress here in hopes that it’ll be useful to others in the future, and also just to show off my work as it evolves. The other work I’ve done in the class is accessible here: http://www.williamhli.com/cs184/. The requirements for our final project are pretty loose, so it shouldn’t be terribly difficult to satisfy the minimum requirements for an A. I’ll be working with a partner, Adit Dalvi, who I’ve done the past 3 assignments with. With that said, our sense of pride will not let us be content with just the bare minimums. As a result, the goal for our final project (due May 20th – 3 weeks away) is to have a working game running on my Xbox 360.

We’ve designed our project to be pretty flexible in terms of the final deliverable, but we’re always up for more if time allows. We have a few milestones that we plan to hit as fast as possible to allow for time to polish the final game before the demo on May 20th.

Phase 1 – Bouncing Balls with Collisions and Shadow

We will be implementing a 3rd person tank “shooter” game. You will fire off objects that bounce back up for several bounces/collisions [+60 collisions]. Hitting other objects will make both objects react to the collision elastically, unless it is bolted to the ground (rocks, etc). Real-time shadows will be added as an additional warning to move out of the way of falling objects [+40 shadows]. Finally, the balls will deform the ground when it hits (in addition to bouncing off), possibly sending other objects flying [+30 displacement mapping].

Phase 2 – Rotatable Cube with Gravity

This is the interesting part of the project. Instead of playing on just one flat ground, it would be played in a cube, and gravity will switch either at a specified time or when a power-up is activated. All flying objects and players will be immediately influenced by a different gravity, and the camera will also rotate [+20 camera]. The different sides of the cube will be different properties:

• trampoline (default)
• desert (dust kicks up and obscures vision)
• water (reflections/refractions?)
• hardwood (no deformations)
• gravel (no secondary bounces)

Phase 3 – Polish and More Powerups

This phase will be the final few days of our project. We will be polishing our game and fixing bugs here and there. We will also make sure the game runs fine on my Xbox 360. Some areas we will cover are switchable modes of lighting [+10], texture and bump mapping [+15], transparency [+5], sounds, and a “display” mode for our game which runs through all the features we’ve implemented without requiring user input. An additional possibility is multiplyer mode so you can play against a friend. Adding everything up gives a score of 180-190. Also, some powerups that we could potentially add to our game:

• no overhead lights – the flying objects become point lights (this is the coolest idea that I definitely want to see)
• Splits: on a bounce, the ball splits into two
• permanent deformation: normally, the ground springs back to normal
• point defense missiles that target incoming balls
• mini-blackhole spline in the center of the cube

More ideas from friends:

• mines that explode many balls outwards from the center of explosion

Hopefully this project will force me to spend time to learn a lot about game programming and graphics in general that I otherwise would’ve been too lazy to pursue. I’m so excited to start this journey – stay tuned for the first screenshots

Edit: We’ve completely overhauled our idea.

I want an excuse to blast my speakers at 60% volume or more. It seems like it’d be an interesting experiment.

Some things hit me much harder than I expect, and I have no idea how to deal with it. I don’t want to go to sleep because I know I’ll just end up thinking about it for hours on end and never actually get to sleep, so the only thing I can do is distract myself with work. Although I do have a propensity for getting lots of stuff done when I actually shut off my main distractions (aim and email). Let’s see what I can accomplish by tomorrow…

this cold weather is so sad – I’ve been staying in bed hours after I should be up and working just because i don’t want to face the cold. at least it’ll all be over in a few more days. also, my attention span is < 1 hour so it’s impossible for me to study anthing -.-

light at the end of the tunnel – looking forward to TBPsouthbay and/or TBPnorth

I’m kind of curious who actually reads these blurbs. Most of my old friends have drifted away and almost all of my new friends don’t know about this.

1. geometry wars is extremely addicting
2. i want another monitor with component input -.-
3. karaoke is really fun
4. my schedule for next semester is so screwed
5. i have too many personal projects to be able to focus on one for any meaningful length of time
6. someone said that i was not a typical eecs major (he wouldn’t have guessed I was an eecs major had he not known beforehand) – awww, i try so hard to give off the eecs vibe too just kidding, it’s nice to know i’m somewhat normal.
7. i want a couch in my room so i can play video games and watch movies on my monitor without having to sit in my chair
8. i haven’t sat back and stared at clouds for a long time
9. i wish i was an expert in a specific domain of computing – i’m kind of dabbling in everything and i’m a decent all-around person, but it’s kind of depressing knowing there isn’t an area that i really understand and can innovate/research new tangents
10. crushcrushcrush :]