Project Theramus Go!

Reviving this old blog to post development progress :)

I've code-named it Theramus. No, the name doesn't mean anything.

Anyway, today:
- Updated Visual Studio and Unity
- Set up BitBucket repository, made first commit
- Did gold spike - running project with sound, art, and a basic game mechanics

And that's it! Was pretty lazy today :(

Sweep Collisions

Wow! It's been a while since I've posted. I've been busy with job apps and trying to find a job, and school work is taking precedence. Sometimes I come home and, after working on games and programming for 8 hours, working more isn't that enticing. Still, this project has been poking me from the back of my head so I figured I'd work more on it today.

Lately I've been dealing a lot with collision systems, both with how to make them more efficient and the systems more intelligent, and also just with the mathematics involved. At school we came across the problem of objects moving so quickly they fly past each other before colliding, so I wrote a sphere-sphere-sweep collision behavior into our game and that fixed the issue. Got the math from here: http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php?page=2

I have my own minor additions to the article:
- It's time based. It's not made super clear, but what the math gives you is the "time" of collision, meaning if you wanted a collision position you'd have to add velocity * time to the position of your objects. So if your collision time is .5, your objects collide when they have moved half of their velocity in a single frame. If you wanted the exact point of collision you'd have to find out the position of your objects upon collision and find the direction from one object to the other and multiply it by whatever the radius ratio is between the objects.
- It can be made more efficient (depending on your desired behavior). The algorithm they provides for the case where your spheres are already colliding and are exiting each other. I've found that for my case - and most cases, I would believe - is you'd want to avoid the situation where they are already colliding. Rather, if you're doing the test every frame you would have detected a collision before they intersected and act upon it. You can make the algorithm more efficient if you cut out the bit for collision exit by always taking the value produced by -b - sqrt(4ac), which will give you the earliest point of collision or the collision "enter". If you have something that you need a collision exit for though (like particle effects when you exit an area), you'd be looking for when -b - sqrt(4ac) is negative and -b + sqrt(4ac) is positive.

The sweep algorithm works great though, and I'll be attempting to do square-square-sweep collisions in my own game, based on a page in the same article! http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php?page=3

I'm still working on it, but hopefully I'll have some real gameplay in my game soon rather than some collision demos.

Picture later today since I haven't made significant progress just yet.

AI Target Seeking

Today I spent some time developing more of the backbone of my game. I made it so the "random level generator" made some walls that make a bit more sense rather than a mess of points, and I also worked out all the bugs so it's now impossible to pass through the walls no matter how you push against them or how fast you're going.

Once I completed this I used the same system to apply it to all objects like bullets and AI units. I found I could use the same math to do a line-of-sight check for AI as well, which indirectly led me to making my first AI class - a simple AI that chases you down.

So here's how to make sense of this image:
- The green square is the AI unit
- Red square is the player
- Yellow empty square is the last position the AI saw the player at
- Lines are walls
- Red cross is the mouse reticle

Basically the AI will continuously move towards the player until the player moves out of sight. When the player is out of sight the AI will continue to the last location it saw the player at and continue looking for the player from there. If the AI doesn't see the player again and reaches the last location it saw the player, it just idles until it sees the player again. There's definitely room for a lot more features for this guy and I'm pretty excited thinking about what I could put in.

The circles you see behind the player are "sound circles". It's a visualization of how much noise the player is making while moving or firing, and in the future I plan to let AI units "hear" things and guess a location to search. I also plan to put in fog of war so when the player can't see things, they can "hear" them.



So. The next features I plan to put in, in no particular order:
- Voronoi or another sort of tessellation for efficient collision checking
- Making the level generator make "zones" instead of just random points so the walls make more sense
- AI "Hearing" and response
- Projectile-Character collisions (and underlying systems allowing that. Basically hitboxes.)

Terrain Collisions

So I already tried two posts explaining my methods while creating my game - one for why I'm writing in Java, another for how I'm doing terrain collisions, but it just didn't really hold my attention. I figure because I half feel like I'm preaching to an empty room. haha.

In that case I feel like I'll just keep my posts short and say something about what I'm making (like terrain collision systems!) and put a screenshot or two. If you're interested in learning my techniques let me know and I'll make a tutorial or something.

Without further ado!

So what you're seeing here is a basic "random level generator" (just a bunch of connected points) that gives me a whole lot of walls. Basically this means I shouldn't be able to enter the center of that mass, but I haven't really worked out all the quirks yet. I'm detecting collisions against the walls and sliding the player (that red box) along the wall when he hits it according to how his velocity was before collision.

Right now there's a bug where he can squeeze into space he shouldn't be in by pushing against corners.

Anyway, that's how my progress is so far! I also wrote a backbone engine to render everything and sort objects, but I suppose that's less obvious.

I know there's probably math or game libraries I could use to make this but part of the point of this game is to practice creating an engine. I decided on 2D because I wanted to actually complete the game without spending years on it. More updates later!

Introduction

Here's the first post of the blog!

I decided to create this since it seemed a good idea to record what I'm doing on my projects. I suppose it should give me some motivation and a way to clear my thoughts. I'm also looking for a job and I heard companies like to see things like this.

So here we go!