Burstin' Bubbles v1.0 (downloadable)

After a while without posting ( I was busy coding and playing Far Cry 3 ( best game ever! ) ), I am happy to tell you that version 1.0 of Burstin' Bubbles is done! It's a playable game, downloadable here (~5MB via Dropbox).
It works on Windows 7, not sure about other Windows versions, but should work as well.
It features a simple Shoot 'm Up in which the player has a machine gun and Medipacks laying around the city (currently filled in with parks). Here are some screenshots of the ingame-situation, menu and instructions:

The main menu

 Now loading...

 In-game chaos, guns, medipacks, etc.

 Game over. Pretty low score there.

How to play the game

The game improved so much since the last post, not only code-wise, but graphically as well. Since the last update I've made major improvements to the code and added the following things:

• Generated roads (using 4 images; an intersection, horizontal road, vertical road and grass).
• Level edges (when you're at the boundaries of the level, the player moves freely and the camera stays still)
• Survival mode (kill as many enemies as possible), replaced the "xx Enemies left"
• Enemy spawn timers with increasing speeds for higher difficulty.
• Portability (the game works on other locations and other computers than the development computer!)
• Completely functioning menu with buttons, button states (hover, down, normal)
• Pause-function. Quite useful if you need to check the controls or anything.
• End game score display (used to be instant replay)
• Clear instructions and a "story"

I will think of things to add to this game, because I still have some days left. The deadline is the 7th of January, so that gives me some room for more stuff! Suggestions are welcome!

Download (~5MB via Dropbox)

Read More

Coding the Bubble (Part 5 - Major additions!)

It's been 4 days since I've posted anything, but I've done loads of work in the meantime. I've added sounds, HUD, replaying of level, loading screen, graphical update of the character, spawning enemies that will follow you, feedback on the enemies indicating health, added Medipacks(which heal 50%), a brand new environment with some graphics, added a MathHelper class with functions as Random(), Normalize(), etc., 2 types of collision (rectangular(somewhat buggy) & circular(works like a charm.))

As you can see, that's quite some stuff. Because I am making the art myself, I am having difficulty keeping myself to my art style, because making a loading screen gives you much more freedom than a 50x50 sprite of a player. I made a loading screen with a $100 bill, with the "Economic bubble" theme in my mind. This is the result:

I'm still figuring out how I'm going to incorporate the mandatory "Bubbles" theme more obvious in the game, since it's essentially nothing more than a shoot 'm up right now. I might incorporate a mission for the player
to "exterminate the bankers, because they are responsible for the bubbles and their burstings".

For the technical part, I want to add randomized levels. The level I'm using right now is over 10mb at the moment, so I want to make some parts of a level (parks, buildings/houses, water) to make big levels varying quickly. I also want to add a menu to choose the scene/mode and to return to after finishing the level. If I have time left by then, I also want to add blood.

Here's a screenshot of how the game looks at the moment:

Read More

Coding the Bubble (Part 4 - Shooting the enemies)

I've made some major improvements to the functionality (and the graphics!). I've implemented mouse-aiming,  shooting of enemies (they die after 10 shots), enemies looking at the player, bullets with an owner, major improvements to the organization of code.

I got the polymorphism to work and now I update all objects with one Vector. I also implemented a GetType() function in the GameObject (and deriving classes) to easily check what types are colliding. Also fixed some bugs which made all the objects update twice and give Acces Violation errors.

I noticed that I needed to load every sprite from file every time I made an object, so I made a TextureManager which loads textures/sprites into a hashmap for easy access. "player" will give me the fancy new blue person sprite as seen below. Also using dynamic memory allocation in various situations now.

Next up will be enemies that will shoot back! Perhaps even a life-bar for the player and a fancier environment.

Read More

Coding the Bubble (Part 3 - Basic Collision & Shooting)

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 )
{
AddPlayerBullet(&(*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!

Read More

Coding the Bubble (Part 2)

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 )
{
i->move(translation);
}

for(std::vector<Player>::iterator i = m_Players.begin(); i != m_Players.end(); ++i )
{
i->setPosition(center);
}
}

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.

Read More

Coding the Bubble (Part 1)

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.

Read More

Brainstorming about Bubbles (Part 3)

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. 

Levels

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? 

Status

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.

Read More