Thursday, November 29, 2012

Implementing basic collision went almost as smooth as I had expected. Had some problems with keeping the objects separated from eachother when there is a collision. I used a radius-based collision system, which basicly means; when the distance between two objects is smaller than the radius of one, there is a collision.
When there is a collision, I keep the two objects from interpenetrating eachother by displacing object A (the player) in the direction away from object B by an amount just great enough to keep them apart. It feels really smooth and convincing to me, so that's the basic collision so far.

When I got that to work, I immediatly started implementing shooting for the Player. When the Player resses "space", the Player ill shoot. The problem with this was; where do I keep a list of the bullets? If I keep the list in the Player  the bullets will move along with the Player and will have difficulty with the collision detection. I needed to find a way to get those bullets to the GameObjectManager in a seperate Bullet list, but without the Player knowing of the existence of that GameObjectManager. What I did was filling up a list of bullets in the Player and after the update of the Player, the GameObjectManager placed all the contents of the bullet-list in the player to a list in the Manager itself. After that, it clears the list in the Player, to clean up the mess.

for(std::vector<Bullet>::iterator k = i->m_bullets.begin(); k != i->m_bullets.end(); ++k )

This is the piece of code that checks in the player("I", since it's looping through a vector of Players) for new bullets and adds it to m_PlayerBullets via the AddPlayerBullet function in the GameObjectManager. I don't really know if this is good practice or a terrible thing to do, but it works for me and the game still performs. I can shoot, the bullets draw and update and they clean up after 5 seconds.

I also made an improvement to the Texture-management. I loaded every Texture apart from eachother and over and over again. I fixed this by creating a TextureManager class with a singleton and a hashmap of textures. I can load textures with TextureManager::getInstance()->m_Textures["name_of_texture_here"]. Makes reusability of textures a lot better.

As usual, I've pushed the code to my GitHub for people to check out what I did exactly. Next up will probably be shooting some enemies or scene-loading. Not sure which one I will do first, since they're both very important, so that's a mystery until the next post appears!
I've been busy lately, not so much with programming, but more with my temporary job before I go back to school. Takes a lot of time, but I get payed for it, so it's not that bad.
For the programming part, I haven't done a lot. I struggled a lot with setting up a derived class from the GameObject-class. I kept trying to call the GameObject constructor from the Player's constructor, but it removed the texture every time I tried, so now I have duplicate code in my player constructor. I will try to fix that if I have enough time left before the deadline.

I've also implemented basic player movement in my game and I will tell you how.

I used my Player class to implement movement by keyboard. The problem with this setup is that when I want to have a big map, I need to implement map scrolling. In the current setup, the player can walk towards the border of the viewport and even walk out of it. What I want is a player stuck in the center of the map and the rest of the objects moving in the opposite direction of the meant player movement. This gives the illusion the player is moving and a camera is fixed on the player.
I solved this by letting the Player move without inverting stuff. After the Player's update function, the Scene calls a function in the GameObjectManager to put the player back to the center of the viewport and move all the other objects with an amount equal to the displacement of the player in comparison to the center.
This is the function doing that:

void GameObjectManager::CenterPlayer(void)
sf::Vector2f center(500,300); //Window is 1000x600
sf::Vector2f translation = center - m_Players[0].getPosition();

for(std::vector<GameObject>::iterator i = m_gameObjects.begin(); i != m_gameObjects.end(); ++i )

for(std::vector<Player>::iterator i = m_Players.begin(); i != m_Players.end(); ++i )

That lead to the following result, a roam-able area:

The next post will be about (inefficient) basic collision. I already have an idea how I will accomplish that, so that shouldn't take too long.

Tuesday, November 20, 2012

Hi there and welcome to my second series of posts about my intake assignment for the NHTV Game Programming study. I've written several posts about the design process and if you haven't read those, here's part 1! Apparently, this assignment isn't mandatory if you are able to come to an interview. I'm doing it anyway, just to showcase what I can and hopefully don't even have to do an interview. I'm not afraid of that interview, but I just want to be that good that they know my capabilities well enough that an interview would be a waste of time. But first, let's get some things done!

In these posts, I will explain what I did to get the game to work. I will set up a basic class scheme and work that out while I am working on the game itself. This will probably be a long serie, since I feature-creeped the crap out of this game. I will not get everything done, but I want to get as much done as possible, using as many techniques/patterns as I can.

By the way, all the progress I make can be followed on my GitHub-page, where I keep track of most of my projects.

I've made a short list of classes to be used in the levels, so that doesn't include the FutureHUD yet. This means I have an idea how classes for the enemies and player should look like. SFML really takes a lot of work of my hands, it manages the drawing of sprites, setting up a loop and a lot more! Here's a diagram of the classes and some functions and variables they have.
This is nowhere near completed and I will make a lot of adjustments and additions to this diagram, but it gives an idea of what I think I need to begin with.

I have some conventions I like to stay with and those are as written below;
Member variables of a class have the m_ prefix
Global variables will have the g_ prefix
For all the primitive types, I prefix the variable name with 'i' for int, 'f' for float, 's' for string, 'b' for bool, 'c' for char, 'sh' for short, 'l' for long and 'x' for byte
I use camelCase, with a starting lowercase letter and a capital letter for each new word.
So, for a class-member variable name like movement-speed that will be a float, it would be m_fMovementSpeed. The first lowercase-letter is the f-prefix, so the word itself will be with starting uppercase.

In the next post, I will make the classes and add some functionality to the player.

Monday, November 19, 2012

As I mentioned in my previous post, this post will be about the goals and how to accomplish those of the "Burstin' Bubbles" game.

Step 8. Defining the goals for the player

There should be an overall goal for our player, a goal that will make the player want to play the game and to make clear why the player has to do missions and perform certain actions. To achieve this goal, the player has to achieve a certain goal for each level. So, we need a main goal and goals per level.

End goal

The end goal of the game will be to prevent the collapse of a bubble. The player is hired by an extremely over-valued multinational in the future to find out why the bubbles of the past collapsed and how they could've prevented the bursts. The player will be mislead, thinking his goals are noble, but it's all about the money. The player will eventually find out that he is helping the wrong side and will use his knowledge of bubbles to burst the bubble while it's impact is still small. That is the final mission. The player will slowly find out he is helping the wrong side and by the time he is at the last level, he will know the terrible truth.

Before I define what the goals of the levels will be, I need a list of what levels I will use. As I wrote in part 1 of the "Brainstorming about Bubbles", I found a link with a short list of bubbles of the past. 


  1. The Tulipmania
  2. The Stock Market Boom
  3. The Dotcom Boom
  4. Back to the Future

1. The Tulipmania

The main goal of this level is to find out how a bubble is formed. The increasing demand on a certain product can influence prices to an extreme level, mostly in case of a monopoly. The actual value of a product isn't important, it's what people are willing to pay for it. If the difference between those are becoming too big, it creates agitation. If an economy is based upon overpaying and overrating for products, it can be called a bubble. 

3. The Stock Market Boom

The goal the employer will give to the player is to investigate how people get confident enough to buy stocks and how to keep that at an all-time high level. This level will be about inflating the bubble.

4. The Dotcom Boom

This level will be about the bursting of a bubble, also know as a boom. The player will investigate how and at what type of moment a bubble bursts. At the end of this mission, the player will know how evil the corporation he works for is.

5. Back to the Future

The goal of the final level is to use the new knowledge to stop the company that hired the player from inflating their bubble and harm the public. I have no idea how the player will accomplish this yet.

Step 9. Achieving those goals

Now that I know what the player's goals are, I can start thinking about how the player will achieve those goals. What weapons, upgrades, possibilities and actual gameplay will the game have?

I am beginning to have doubts about the perspective I chose. I chose a 3rd person perspective, but that will give me a lot of restrictions in movement and the artwork will stack up really fast. If I make the game top-down viewed, I can simply rotate a sprite instead of having an animation for every walking direction with every weapon. Making it top-down will make it a lot easier for me, so from now on the game will be top-down viewed! I can also make it more Shoot 'm Up-ish now.

The actual gameplay

When the player isn't in a level, the player is in the Future HUD and can buy upgrades, (re)play a level, adjust difficulty and quit the game. 
When the player is in a level, he has an objective, seen in-game, and has to fight off everyone who delays you in completing it. The gameplay should have a slightly less intensive feel than Hotline Miami. That game is awesome and I hope I can achieve something that feels like this, only a bit slower and with other goals.

The weapons

The player will get a weapon loadout for every level he enters. There are additional weapons in the level itself. The weapons that can be found in the default loadout are;
  • Bat - the melee weapon for your every day needs.
  • Dual Pistols - why shoot just one way if you can shoot the opposite way as well?
  • Machine gun - spray dem' thugs down!
  • Shotgun - excellent for maintaining your personal space.
I have no idea in what type of art-style these weapons will appear, but it's about the function of the weapons, not the looks (at least for this part of the post). The weapons that can be picked up in the levels are still unknown as I will design that when I am working on the code.

The upgrades

I was thinking about the basic upgrades here; extrra weapon damage, extra fire rate, extra walk speed, maybe an extra skill? 


The base for the design of Burstin' Bubbles is set now. In the next post, I will think of the classes used in the code and how the HUD's will look.

Saturday, November 17, 2012

Continuing on the post I wrote yesterday, Brainstorming about Bubbles (Part 1), I will make some more decisions and brainstorm some more about elements to be used in "Burstin' Bubbles".


OK, this is what I have so far; I will make a game in C++ (with SFML) called "Burstin' Bubbles" involving levels based on historical economic bubbles. I still don't have any idea what the mechanics will be, how long the game should be playable, what the graphics will look like and how the game should feel.

Step 6. What will the player do?

So, what do I want the player to do? I know the game will be made with 2D graphics, but that still leaves much room to what the actual gameplay will be. For example, you can make a game of one of the following genres;

All of these games are made using sprites, even the fairly new games Awesomenauts and FarmVille. I don't want to pin myself down to a genre, but I can use the elements of the genres that I like to make something cool. So, I'll define what genres I would want to incorporate in this particular game. Here's the new list;

  • 3rd Person RPG 
  • Real Time Strategy 
  • Simulation 
  • Shooter/Arena 

But what are the strengths of these genres? Here's another list!

3rd Person RPG

  • Free-roaming
  • Large worlds
  • Many hours of gameplay
  • Character Building
  • Room for storytelling

Real Time Strategy

  • Fast gameplay
  • Short games
  • Many ways to win / Non-linear
  • Easily expandable (Extra units, maps, etc.)
  • Suitable for multiplayer


  • Suitable for real-life-related events
  • Direct transfer of knowledge
  • Useful for predicting results (business cases, economic bubbles, etc.)


  • Quick, immersive gameplay
  • Easily expandable (extra levels, guns, etc.)
  • Multiplayer-suitable
What do I want the player to do in this game? I can pick some from above and form an idea. For example;

If I pick Character Building, Shooting/Explosions, and a 3rd person point of view in a simulated world I would have a Shoot 'M Up with upgrades in a setting relatable to an economic bubble of the past (for example the Tulipmania). I decided to work with the concept of levels before.
So, imagine a "Legend of Zelda: A Link to the Past"-viewpoint, with the violence and speed of "Awesomenauts", in a 17th century setting, causing or preparing for the burst of the bubble.

Step 7. Justifying decisions

An idea got into my head just now, meant for the story line. (Yes, I am chaotic.) The player will be someone from the future, time-travelling to the economic bubbles of the past to find ways to prevent or limit the effects of an upcoming bubble in his own period. This way, I can justify the jumping from one period in time to another, using a fancy interface to select a level.


What do I have so far? Here's a list!
  • Game will be made in C++ (with SFML)
  • It will be called "Burstin' Bubbles"
  • Game will have multiple levels
  • Perspective will be 3rd person, like LoZ: A Link to the Past
  • Player is a time-traveller, analyzing bubbles of the past.
  • In the fancy interface, the player can select the level to visit.
  • The player can get upgrades. (Character Building)
  • The NHTV-deadline is 7th of January. I want to have at least a tech-demo done by then.
  • I have no idea how I will accomplish the Art-side yet! Will use home-made placeholders for now. 
The next post will be about thinking of what weapons the player can use, what the goals will be and maybe a first sketch of the interface as well. 

Wednesday, November 14, 2012

I've already begun brainstorming for the NHTV intake-assignment with the theme "Bubbles". I will explain the very short brainstorm-process I had, with colorful images and explanations of said process.

Step 1. Write stuff down!

Write down stuff about bubbles. Basically making a word-web, only more colorful and more messy. It works though.
As you can see (and if you can read it), I wrote down words involving Bubbles, but also some things relevant for games like "bubbleshields", "Bubble Shooter", and some less relevant stuff like "Facebook", of which is sometimes speculated it is (involved in) an economic bubble.

Step 2. Connect some dots!

Connecting dots. I now have a list of words involving "Bubbles". If I put some words together, I might be able to get a cool name for a game which I can then design. I wrote some titles down, some terrible, some quite catchy. I made two very small word-webs for two of those titles as seen below.
These are combinations of words I wrote down earlier. I like "Burstin' Bubbles" the most. It has that "Breaking Bad"-smoothness. "Absence of Substance" is more cryptical, but I think it can be interesting. The title sucks though.

Step 3.  Choose something!

Choices, choices. It's quite imminent that I'll pick "Burstin' Bubbles" as title for my game. I can make these fast choices, because my focus is the code, not the game design.
Now, for the next choice; what will be the actual subject? Bubbles can be a broad subject. You can think of an economic bubble, a liquid bubble, a soap bubble, an antibubble and even a term used in Poker (if someone gets "eliminated on the bubble" in a tournament, that person is the last person to drop out without payout).
I like economical and political topics, like the dot-com boom and events like Black Tuesday. Speculation about whether Facebook is or isn't (part of) a bubble interest me.
Then again, the physical working of a liquid bubble interests me as well. 
That I have interest in a particular subject doesn't mean that I have a good understanding of said subject.
Because I want to expand my knowledge in the subject of economic bubbles, I will use that as a subject for my game.

Step 4. Google some stuff!

So, what am I going to make? I haven't got a clue (yet)! From this step on, I am designing/making decisions while I write this post. First, let's google some stuff related to economic bubbles!

When I googled "Is Facebook a bubble?", I quickly stumbled upon a site called "Economic Times", part of the "Indian Times". The post is about whether Facebook IPO [First time a company sells stock to public] is a sign of a new tech bubble. That's not the biggest value of this post for me, the real value for me is the short list of great bubbles in the past (like the Tulipmania and the Dot-com Boom).
When I saw this list, I immediately thought of them as levels for the game or at least inspiration for levels. This is mostly my mind making hasty decisions, but I actually like the idea of a multi-level game with different crashes. This way, I can teach myself and the players some stuff about the economic bubbles of the past!

Step 5. Sleep

So, what do I have so far? I will make a game in C++ (with SFML) called "Burstin' Bubbles" involving levels based on historical economic bubbles. I still don't have any idea what the mechanics will be, how long the game should be playable, what the graphics will look like and how the game should feel. Defining and designing these aspects will be done in Part 2. But first, it's time to sleep for me, because I slept like shit last night and I have to get up early. 

Nighty-night, me readers. Think big now.

Tuesday, November 13, 2012

Last Saturday I went to the view day of the NHTV to look at the IGAD-programmes. After a three hour travel I arrived in Breda, accompanied by Luc. We walked through the school to check out some student work and hear presentations about the Programming-courses and the 3D Visual Art-courses. I was mindblown by the quality of work delivered there and the Programming-courses fit and completed my dreams and ideas of what a capable Game Programmer should be able to do.
Not only are there courses to teach Mathematics, C++ Programming, but also stuff like CG, HLSL, Assembly, Code Optimizing, Data Structures & Algorithms. Mostly stuff you will find in any Computer Science-programme, but I didn't really expect it that low-level. I want to do it though, I am extremely excited to follow all of those courses.

But first, I will have to get accepted to the Game Programming-programme. To achieve this, I will have to make a game with the theme "Bubbles" and fill in some stuff at a site of which the link will be mailed to me within a week. The deadline for this is the 7th of January, 2013.
I've already set up the project and made the initial commit and push to GitHub. I will design the game first, but I've made some choices on the technical site already. I will use C++ with SFML. I'm not using SDL because I am having problems getting it to work and there appear to be issues running SDL on an i7. Apart from that, I've made something with SFML before (a raw techdemo of an Asteroids-game)

Now for the design-work...
I have no idea yet what I'm going to come up with, but I will keep this blog up to date with the design-choices and the technical choices as well.
Subscribe to RSS Feed Follow me on Twitter!