Project Aurora, post 2 (Blog Assignment 1)

So we have laid down some plans for the game which we based our SCRUM on but we haven't finished the design document yet. This is causing some smaller problems. It's been kind of hard to organize the programming of the game. Who will code what and when does it need to be finsihed and what does it need to have.

Result is that we have been doing some unnecessary things. I had to redo the whole GameObjectManager and the Sprite and FishObject class that Viktor made was removed from the project.

The other day we met with our game design teacher Adam Mayes from our other class of game design we had last autumn. He gave some feedback on what we had and we all realised that our aestethic goal  was not the one we had planned for in our SCRUM. So he guided us in the right direction and I felt the group became more focused on what we needed to do after that meeting. Our main aestethic goal now will be challange and not exploration/discovery that we had planned.

One of the assignement in the course Introduction to game development is to write six blogposts where i need to reflect on one artefact/feature i made during the week. so this week I merge this post together with the game programming course that we have in parallel to game development.

So this week and last week I've been working on the GameObjectManager class. This class will handle all the game objects in game. I chose to write about this one because its been giving me most grief the last two weeks. 

First i designed and wrote the code for this so all different objects are stored in their own container (C++ vector class.)  like this:

PlayerFishObject *m_pxPlayer;
LightObject *m_pxLight;
std::vector<TerrainObject*> m_apxTerrain;
std::vector<EnemyFishObject*>  m_apxEnemy;
std::vector<PowerupObject*>  m_apxPowerup;
std::vector<InfoObject*>  m_apxInfoObject;
std::vector<TrapObject*>  m_apxTrapObject;
std::vector<ParticleObject*> m_apxParticles;

Because I made one container for each type I had to make alot of functions within this class to handle all these objects. How they are stored when loaded into the game. How they update during gameplay and how they are deleted. This wednesday I got feedback from the last game I made. (See earlier blogpost.) In it was explained that i did alot of workarounds and storing in so many different containers was kind of bad. So now I rebuilt it all so all different kinds of game objects are now stored in the same container.
So now i use this instead of the above:

std::vector<GameObject*> m_apxGameObject;

When doing it this way we need to use C++ polymorphism to access child classes that inherit from the parent GameObject class that i also created for this. Within this new class I added a virtual function which means that all classes that inherit from the GameObject class can have the same function.

virtual void Update();

If they have a function with the same name, the child class function will be called and not the parent function of the same name.

This is really smart but since we all are new to programming this is a bit unfamiliar grounds we are stepping on. But thats how you learn right? So the reason we felt like going this way is for learning new ways to program more effectively and for increasing perfomance.....i hope.

We have only tested this with one type of object so far. So we will probably have to improve this class further when we bump into problems. With this in place I also had to add some functions to the spritemanager class that Viktor had built so it fit with our Gameobject class and SFML library we are using.

I based it from the same way of thinking that we learned from our C++ teacher Tommi Lipponen's platformer that was made in C++ using SDL library. But because SFML have a built in sprite class and handle sprites differently some changes had to be made. What these two functions basicly does is loading a texture from a png file and storing it in a C++ map container. Then a new sprite is created and allocated in the heap memory using the stored texture.

So today we could finally draw game objects to the screen that is loaded from a text file in a dynamic way where we reuse the same texture when we load and add the sprites to the background objects.

Here is a screen using placeholder sprites:

Beautiful right? well it will improve in looks as soon as we get some real art to work with.

Today we had a sprint review of this weeks work where i was supposed to do this:

Camera / View
EnemyFish (class)
TerrainObject (class)
PowerupObject (class)
InfoObject NonInteractive's (tutorial)

I finished the PowerupObject class but its not in the game yet. It inherits from the GameObject class that i made (that wasn't in the sprint planning / backlog) The PowerupObject will handle the Power-ups in game and I only did a basic outline of the class so we have something to start with

In it I created an Enum that will keep track of what type of powerup it is.

enum eType

{

ROD,

LIGHT,

SPEED,

ENERGY,

TYPECOUNT

};

I then added the following functions:

eType GetType();

void SetIdleMovement(float p_fMovement);

/*void SetGlowEffect();*/

void Update(float p_fDeltatime);

• GetType returns an enum with what type of power-up it is. 

• SetIdleMovement is the speed the which the power up will move with up and down. We want it to move up and down slowly so it feels like its floating around in the ocean.

• The SetGlowEffect I just put there put its not implemented yet because no one in the group know how to implement lighting/bloom effects. If we learn that we will add it in. There is an example in the SFML-book that I will read through when we come to that. (Special effects will have to wait until basic mechanic is in place)

• And then there is an Update function that updates all the movement made in the current frame.

Since I rebuilt the GameObjectManager and added a GameObject class we could basicly skip making the Terrain and info objects because they are created/integrated in the GameObjects, atleast for now. If we need them to have alot of different functions we will probably break them out in their own class.

I then played around with camera management in SFML and they have built in functions that are quite good so I think we will skip adding a camera class to the game. If we come up with new ways to maipulate the camera we might add it in. I made a small prototype playing around with the camera so I will use what i learned and implement that in our main project. I thought of showing that here but its not that good so I will show some screens when I've implemented it in a better way. I will continue work with the camera during the next week as well.

I think this is all for today. feel free to comment.