Buildable

No big post here, just a picture.

Nothing new in the game itself shown, but I started making test builds and packaging them to make sure they run in the real world. In this case I added it to my steam list to see if it would work with the overlay and it all looks good.

Ka-Boom!

And another small but important update. There are two things in this clip,

First I tried to show off the three firing modes of the main gun, right now the rainbow of bullets is strictly so I can easily identify them. Nothing really to speak of here, rapid fire when held down, stronger when tapped, even stronger if left to charge, each one doing about double the damage as we go up, with a bonus to the big shot.

Secondly we have a simple standin model for an explosion, which is important for two reasons. Because explosions, no matter how blocky are cool, and because in my game explosions will provide a more efficient means to taking out groups of emenies.

Now before you say no shit, bombs make more things die, let me say I plan to clog this screen up with fast moving targets. And the only way to kill everything and get a good score will be balancing firepower and player movement (more on this later when I have something visible for point keeping, and the secondary weapon implemented).

Collisions and Reactions take 2ish

Ok Blogspot being dumb with formatting, lets try this again.

Alright here we have a simple video showing collision, an enemy ship flashing as it takes damage, and if you spot it a green bullet mixed in with the rest it's not an anomaly it's one of the different firing styles I talked about earlier (hold fire for rapid, tap for stronger, let it charge for a big shot). Though in this case it is a bug, as the different shots are caused by taking the timing between the last shot and amount of time since the last frame. So if the framerate is inconsistent (say when I start recording a video) timing goes out the window. One of the coming things for me to do will be to make sure that the different firing systems have both a built in delay, and take in to account key presses.

I added a simple system to clear un-used actors as they die (in this case to make sure bullets and effects don't linger in the world population), so far it has not caused any problems, but I will need something more efficient. This will probably come in a means of recycling node names for new objects of the same type. Right now if a bullet is destroyed (removed from the population list actually) the next bullet is created with a new node with a new name. The old nodes are not referenced but they weren't deleted so this leads to a lot of new nodes being created when for simple objects like bullets it doesn't really matter if the next object didn't have sequential numbering.

Coming up is a level progress system to keep track of where the player is, and what should be happening at a given moment, and adding simple effects and enemy destruction.

Collision and Reaction

Figure It's about time to show what little I have so far.

I'll update later to say what new stuff is going on behind the scenes.

Ow that hurts

Small update, well not much going on from a screenshot standpoint but a lot going on behind it.

So, first off I implemented a key repeater and the ability to map actions to keys. This lets me have a rapid fire weapon, that can also fire differently if charged up or tapped instead of held. There is an enemy on screen now, though it is properly spawned, he can't die, and just serves as a punching bag, or shooting bag as it may be. He is not orange naturally, he is actually flashing as he gets hits by the player's bullets. Which is of course the part of this that I'm happiest about.

The collision detection is very basic (simple bounding sphere overlaps), and the effects of objects colliding is hard coded (flashing happens to show it visually, but there is no logic that follows). I guess next I will be adding collisions to a list and then sort through it to perform the appropriate actions. Also if needed adding more complexity to the collision check to account for predicting collisions that don't take place on actual frames.

Back with something new

I cleared all the broken links on here, and figured I should at least make use of this space while a proper website still confounds me.

A while back I started working on my own game, it's super simple, just a top down shooter, that is written in Python and takes advantage of the open source render engine Ogre 3d using PythonOgre. Everything is still stand in art, and there is a lot of work to do but at this point it at least resembles a video game.

As of now I have a player ship and bullets derived from a general actor. The player ship can move (well slide around a 2d plane) and shoot, and will stop on collision of the screen edge.

Next up I will hopefully be smoothing out the movement (right now it translates directly from the keyboard instead of normalizing the vector before moving, so for example if you are moving up and to the left the ship ends up moving faster than it could in a single direction), and adding in game states to allow pausing and menus. And once that comes, hopefully a video.