Atrifact 1, gom

GameObjectManager! Not the prettiest! But I think it’s simple to understand.

Yeah.. Almost an hour left to the deadline for this blog entry. I almost forgot about it. Today I’ve been drawing concept art, made a pretty sprite, and now I’ve been on skype with my friend for a while working on an album. Oh I’ve been programming lots as well (that’s what this blog entry is supposed to be about).

I have done like… A game object hierarchy and a manager for that, all the game objects that are in it (player, enemies, bullets and some stuf unique to our game), and made the gamestate almost complete. I made the game object manager earlier but I really didn’t say much about it. However it eventually got accepted by the QA.

Our group’s game is now a survival game where enemies approach from all directions trying to take you base in the middle out. You have to shoot those enemies down. Soon we’ll add a score system.

The controls of this game are a little bit special. It’s made so that if you press D you’ll rotate clockwise around the base and so that if you press A you’ll rotate anti-clockwise. W makes you move away from the base and S makes you move towards it. People think these controls are strange and so do I. The movement out from (and in to) the base kind of fucks up your brain when you have to aim with your mouse at the same time. We might change the controls tomorrow.

The artifact that I will write about right now is the game object manager(which was actually something I made last week but I didn’t write any post about it). I was given some kind of a template containing just a single vector of objects, that would use ”GetType()”-functions. I understand the concept of that and I can see why it works and why it is good (I think mostly because the game object manager’s update function will look alot better), but when I tried it fast I realized that so many more functions had to be made to like… Use one game object inside another. So I instead split that vector into several ones containing different types of game objects. One vector for enemies, one for enemy bullets, one for player bullets… And so on. Then I could easely make a method for say.. The player, that took a vector of enemy bullets as a parameter.

I think this makes the code much more flexible for change, it might be because I understand it better like this, or because it’s just a very simple way. Or I’m just strange, which also is good.

Now when I’ve been working on this code for a while, I start to think about things that I could make better. Faster ways I could’ve done stuff, or perhaps even better ways. But then I think ”I might have time for that later, Now I’ll just do my best to get something nice and playable”. So that’s what I do. I stick to the funky way I started out with, and perhaps if time is given and our game is as awesome as we want it to be, I’ll optimize the code. Or I’ll make music for our game, we’ll see which of it…

Next time I might write about our non-existing collider that works well or something… It’s a smart collider (I think)