Even Simpler!!!

I was just thinking about the hashing function when I realized...I can make my life even SIMPLER! Scrap the hashing altogether. At the beginning of the game, I check the dynamic objects positions against all the tunnel segments, I get the index of that segment and store it. THAT is the main index I need to check against, every frame I only ever check against the one that the dynamic object is at, the one before and the one after. After that I check to see which of those three I am nearest to and use that one as the main segment. This way, I only ever check against 3 segments and I adjust which is the main one accordingly moving up and down the list of segments as needed!!

This is what I was hoping to achieve when I first started thinking about how to deal with the collision detection, now finally after a round about through octrees and hash tables, I've got the best/simplest method I can think of that is the least demanding. With a few clever tweaks I can even spread the collision checks to have it check only the tunnel segment I am most likely to be colliding with, reducing the checks to 1-2 max per frame per dynamic object!

Out with Octrees, in with Hash Tables!

So as I was reading up on Octrees and beginning to implement them and I realized that although they would be great for a world that is more or less square-ish in shape (or you could even use a number of them for longer worlds), for my purposes it's not ideal. The levels I will be building are by nature going to be more elongated, which doesn't seem to be well suited to be used with octrees. So I have decided an easier way to get things done; first of all, all the level segments are contained in a list, what I plan to do is store the indices of the tunnel segments in a hash table using their unique locations in some hashing function (haven't figured it out yet). That way, I could hash everything once before the game starts, and then using the player's location with the hashing function, find out which tunnel segment the player is nearest. From there I have the player's location relative to the list of tunnel segments and can easily check the immediate segment and the one before and after (to take care of the boundary case of collision detection).

It may not be the most space efficient (to ensure I don't get too many clusters, I may need to increase the size of the hash table if I can't figure out a better hashing function) but that is why I limited the hash table to hold only the indices, therefore only integer values. I could even use a smaller data type since I won't have nearly as many segments as an integer could represent. All the computations for the tunnel segments are done offline and only any objects that are dynamic will recalculate their hashing values online.

Overall I'm feeling pretty good about this method, the implementation is very simple, it should work great, all I need to do is spend the time to figure out a quality hashing function.

Moving Along...

While I was thinking over how to organize the collision detection last night, I remembered the spatial hash grid I had been using for my school projects and then remembered Octrees! I've never done them before so first I will read up on them in a book I have (the octree section being one I haven't reached yet), and then implement it and see how it runs.

At the same time I've been following tutorials on making a Hack 'n Slash using Unity:(http://www.youtube.com/watch?v=YYqzz1dy3Ak&feature=BFa&list=PLE5C2870574BF4B06).
So far some basics about game components have been done, a decent amount of scripting and GUI design and now integration of a 3D model with animations has come up. I've decided to take a small break from the tutorials and learn how to make a simple model and animations using Blender. I don't want to make anything super fancy because I want to get back to the tutorials A.S.A.P., so I will make a simple humanoid character with a basic walk, idle and attack animation. If I struggle too much with that I will simply make some kind of vehicle that will hover around and shoot (bare minimum in terms of animation).

Tunnel Flyer Progress

So the collision detection seems to be working, it gets the vertices from the models near the player, constructs the triangles, then uses the collision detection algorithm to determine if there is a collision. I implemented two levels, one where the player is warned that they are near the wall, another when they hit the wall. Unfortunately the latter does not work all that great. I could do something simple and effective if the tunnels were uniformly shaped, but my goal is to have jagged walls and protrusions to make it look like its underground or something. Going to need a decent amount of time to work on it.

I need to improve my algorithm so that it tracks which walls the player is near rather than cycling through every single model. I also tried a simple collision resolution, that didn't go so well either. While I was mulling over how to solve those issues, I tweaked the controls so they feel nicer, also made some simple aesthetic additions, and a simple culling feature so that when I create much larger levels, the game won't be bogged down with drawing the things that aren't in view.

When I feel I need to take a break from this project, I am trying to make myself work on learning Unity rather than resorting to playing games. Kinda working, but I'll be getting more and more focused on work as time goes on.

3D Mesh Collision!

I've come back to Tunnel Flyer now that the controls work. I added randomly generated tunnels using small segments (simple ones for now). Currently I am working on the collision detection between the player's ship and the tunnel walls. I can't see a nice way of using primitives to detect the collisions so I figure this is a good time to learn how to use the model geometry for collision detection.

What I have so far is: when a player is close enough a segment, it checks how far the player is from each triangle in the model. Given that the models are rather simple I was hoping it wouldn't be too intense. I didn't want to attempt optimizing too early on but right off the bat I'm at what looks like ~10 frames per second! I'll need to make improvements to when I do the checking and maybe spread it across a few frames.

The collision detection itself is an algorithm I got from a book I'm still reading; "Real-Time Collision Detection" by Christer Ericson. Before I even consider improving that (which I'm sure they little to nothing I could do) I'm going to fix the code around it first. Hopefully by the end of the week I'll have the collision detection working correctly and I can see to what limit I can push it.

Taking a short break from Tunnel Flyer

Until Tuesday, I won't be working on Tunnel Flyer. This is because I signed up for a design3 webinar showing how to use the Unity Shuriken Particle Engine! Problem is I don't know how to use Unity! So that is what I will be doing until the webinar is complete. I've got plenty of resources to learn from so it should go pretty quickly.

Second Developer Movement Game Certified!

Just got the email today that my second developer movement game for Windows Phone 7, "Keep Running!", has passed certification! :) I may need to make it easier though given the initial reactions when my friends played it for the first time. Either way, its certified and will be published shortly! :)

Tunnel Flyer 3D Flight Controls Complete!

I just completed the 3D flight controls for Tunnel Flyer. The ship is controlled using the accelerometer. Riemers XNA Tutorial on quaternion rotations and flight kinematics were extremely useful for quickly wrapping my head around a nice easy way to rotate vectors. When using the accelerometer data for inputs, the movements were very choppy. I looked into using a filter of some kind, I quickly came across a low-pass filter but that wasn't what I was looking for. So I resorted to making my own smoothing algorithm that uses two previous input values to smooth out the current value. Overall the controls need a bit of tweaking but for now I'm quite happy with the result as now the ship moves around mostly fluidly. :-)

Slime Jumper Certified!

I just got the email informing me that my first Windows Phone 7 game "Slime Jumper" has passed certification and will be automatically published after 24 hours!!! No better motivation to continue developing video games!!

Tunnel Flyer Revisited

Yesterday I went back to my old Tunnel Flyer game that I had been having problems with. I've decided that I will change the game so that I may proceed along with development rather then be stuck surfing the internet trying to figure out how to properly export .fbx models that have holes in them.

So the way the game is going to play NOW is basically you control a flying vessel and you have to navigate your way through tunnels of various types. Control of the ship is done using the accelerometer and there will be a brake and a boost button on either side of the screen. The tunnels will be complex enough having twists and turns, going up and down and likely to have obstacles floating around in them. I've chosen this idea because I can learn more technical skills rather than how to properly use a 3D modelling program. Those techniques I will need to learn are proper 3D flight controls, some kind of mesh collision and I'm hoping to have a choice of level designs. The levels either being from a preset list with varying ranges of difficulty, or a tunnel that is generated on the fly, making it different each time its played. The latter being the more difficult one.

Second Developer Movement Game Completed!

I just finished submitting my second developer movement game on the Windows Phone 7 MarketPlace!! This one is called "Keep Running!" The game is basically a side scrolling platformer where the player's position is fixed and the world comes at her/him. The player must avoid obstacles that come in from the right side of the screen, while trying to grab coins and purses to maximize their score. The levels are generated using predetermined "segments" that get loaded in piece by piece.

Now that both of my submissions are completed, I can start working on perfecting them to what I have in mind. Slime Jumper will have more items, special power-ups and maybe a few other things. Keep Running will have a more dynamic collision response system where the player can trip over obstacles (slowing them down but not dying), a more dynamic level creation procedure so that each player is different from the last, and maybe some power-ups as well.

So that's all for today! Both games are submitted! Yay!! Oh and I can't forget to complete my 3D Tunnel Flyer game that has caused me a few headaches. Haha.