Wednesday, December 19, 2012

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!

Friday, December 7, 2012

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:

Monday, December 3, 2012

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.

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 )
{
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!
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.

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. 

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.

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".

Status

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

Simulation

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

Shooter/Arena

  • Quick, immersive gameplay
  • Easily expandable (extra levels, guns, etc.)
  • EXPLOSIONS!
  • 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.

Status 

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.

Tuesday, October 23, 2012

Here is another update on the level editor I'm making. I had some struggles with the WinForms and XNA combination, because I couldn't use the Content Pipeline the way I was used to.

When you ran the program, it build all the assets with MSBuild in a temporary directory and removed those when you closed the program. This did allow me to use the assets, but the loading time became higher and higher if I added more assets. 

Changing the build directory

I figured, if I changed the build directory of the ContentBuilder-class (the one that handles the MSBuild-stuff), which I used from the WinForms example, it would build the files to a directory that wouldn't be deleted and was easy to find back. This gave me a folder of .XNB's which I could load directly using Content.Load<>(). Much faster!

But it was still rebuilding the files over and over. After some thorough investigation I noticed that the .XNB's get removed from the build-directory as part of the MSBuild-process. There wasn't a way to stop MSBuild from removing the files that already exist. So I still had long loading times. 

Moving the files

After some fiddling and thinking I came up with the idea to move the .XNB's to another folder just after the buildprocess. It worked! And it was one of the first times I've used recursion for something useful! (looping through the directories and finding the files that need to be moved.)

Keeping it up to date

The next problem was keeping the files up to date. If I change a file, I want it to be built to an .XNB for immediate use. I made a Console-app which updates every three seconds to see if files are changed. It uses an XML-file that saves the assets with information such as the path to the file, the type of the file (model, texture, shader), the last update time and the last build time. If the build time is earlier than the last update time, the file needs to be rebuilt and it will do just that.


The Clockwork Asset Builder is a Console-app that runs in the background with a little log that shows errors and which files get rebuilt. The "removing build-folder" is the removal of the temporary folder which gets cleared by MSBuild anyway. 

This program will be used in the background during the use of the level editor. I will build in functionality to make it automatically reimport adjusted assets, so you can see the changes immediatly!
You can check the code on GitHub if you're curious how it works. If you have any suggestions, let me know!

Monday, October 22, 2012

Instead of making an entire site to show some videos about projects I've done so far, I will post it here. Much more user-friendly and compact!

Most of my work was made at the USAT, during my two years of enrollment. That's where I picked up programming (so that means I've started programming two years ago!), by making a Flash game. Which I unfortunately lost due to a human error on my FTP server. If anyone reads this: MAKE BACKUPS and not on the same server as the site itself. Pressing delete from your root folder is almost never a great idea.

Anyway, back to the projects. I will show you the top 5 of the games I made that I like the most.
I've done the most of the programming of these projects. In some situations there was another programmer 

1. Fins of Liberty

Deadline: December 21st, 2011
I like this game the most humor-wise, but not code-wise. I had a lot of trouble to get the movement of the fish to work properly and the collision was a pain as well. When you were swimming, you could swim into a corner and break the collision. Which happened very often.
The audio consisted of three layers. The volume per layer depended on a factor in-game. For instance the drum-layer depended on the distance between the waiter and the fish. 
The game was made in Unity by the way.
The movement of the waiter was done by another programmer, which started as an ambitious path-finding project but became a waypoint-to-waypoint system. 

2. Garuda (Global Game Jam 2012 entry)

Deadline: January 27th, 2012
Garuda was a GGJ-entry of which the theme was Ouroboros. After a brainstorm that took way too much time we decided to make a game where the goal is to die and reincarnate as many times as possible. You can do that by flying in the trail the other player leaves behind when hunting for your trail. This game was made in Unity and the idea was to make it a LAN-game, but due to a lack of knowledge and time at that moment, we decided to make it 2-player splitscreen. We had problems with the movement at first, because we included the Z-axis rotation, which became incredibly confusing and annoying. We looked at Diddy Kong Racing and used the flying movement that they had.
I didn't do all of the coding in this project, but I've worked on the movement, the collision trail, the GUI. Basicly everything that's left to do when using Unity.

3. Tiny Knights

Deadline: May 11th, 2012
Tiny Knights was my first game made in XNA. This was also my introduction to shaders. I made a little directional light-system, made a GUI-system and made some basic gameplay. The game is based on plants vs. zombies, only simpler. The goal of this version of the game is to repel the enemy attackers until you have enough cash to be practically invincible. This is because I didn't have enough time to make a better AI and a destructible castle for the enemy.
This is one of my cleaner coded projects, because XNA forces you to work in a more Object Oriented way and Unity just lets you drop scripts on objects. I still have the code and the executable for this project, to be found here; http://www.2shared.com/file/Cz6_tHAu/Tiny_Knights.html

4. C-Pew-Pew (Asteroids clone)

Deadline: June 14th, 2012
In a mission to learn C++, I made a game in SFML (SDL, only easier to use in my opinion). It's an easy game made in a short amount of time. You simple shoot asteroids, they disappear, new asteroids spawn and you shoot those as well. I didn't have enough time to implement the splitting of asteroids, but that's perhaps something for the next game.
Download of the code (you will need SFML and VS2012 to run it, but the .cpp's are readable);
http://www.2shared.com/file/MxuLI7d4/SFMLTest.html

5. Clockwork Age

Deadline: None, just started this two weeks ago.
Clockwork Age is a steam-punk RPG that I am making with a friend of mine, Luc van de Mortel. I will make a level editor (as seen in this picture and on many posts on this blog) and a third-person-like gameplay. I can't give any details, because there aren't any yet. This project is made to expand our portfolio and make something awesome. We will make as much as possible before we start our study in September 2013. 
I use Git and GitHub to keep track of my code and to show people the code I make.

And the rest?

The rest of my work includes lost projects(like my first Flash-game), barely working experimental games involving an installation, mostly made to create an experience more than a game. I also make websites, but I don't really find that relevant enough for a Game Programmer portfolio. I also want this to be a short overview of things that I want to show. If I finish other projects, I will make a new portfolio-post with a link to this one as well.

Saturday, October 20, 2012


I finally got the camera controls to work properly. The orbiting, panning, zooming, scrolling and keyboard-movement now work the way I planned. All the movement is done in the CameraMan-class, a member of the Camera-class.

The problem was that I couldn't get orbiting around an object to work without messing up rotations. After a lot of googling I found a useful way to accomplish this. The idea of setting the position to a transformed Vector3.Backward and scaling it by the distance of the actual position and the target works like a charm.

I begin the orbiting by determining the amount the camera should rotate. I use the relative mouse position and divide that by 500. I add those numbers to a Rotation-vector3 saved in the Camera-class. When that is done, I use Matrix.CreateFromYawPitchRoll with my Rotation-vector3 to get my Rotation-matrix, which is also saved in the Camera class.

After that I create a float called 'dist' which is the distance from the actual camera position to the target.
Then I transform the position with Vector3.Transform(Vector3.Backward, Camera.rotationMatrix);
I am using Backward to easily reposition my Camera. After the transform, I scale the position by the 'dist' and voila. I have a rotated camera. It only assumes the cameraTarget is 0,0,0 at the moment. So just add the cameraTarget-vector to the camera's position.

The rotation matrix will be updated whenever the camera is rotated, so you will always have a good rotation matrix for transforming the up-vector and the right-vector. This makes panning the camera very easy. It's nothing more than Camera.Up = Vector3.Transform( Vector3.Up, Camera.rotationMatrix );

Now that this is settled, I will work on the caching/storing of the assets built by the XNA pipeline and Picking/Selecting objects.

The answer on this question helped me to fix this situation; http://gamedev.stackexchange.com/questions/25448/orbiting-a-specific-point-orbiting-camera

Friday, October 19, 2012

Clockwork Age is a project I am doing with a friend of mine, as preparation for the study we want to do at the NHTV in the Netherlands. I am aiming for the Game Programming-direction and Luc is aiming for the 3D visual art. We both stopped our study at the Utrecht School of Arts & Technology, because we both disliked the way the school treats its students, we both wanted to specialize something. We chose to do this after completing two full years at the USAT.

Clockwork Age

Clockwork Age is going to be a third person RPG-like game in an era called the Clockwork Age. This era is  a Steampunk-inspired environment in a post-medieval setting. The world will include at least one small village, a big city, lots of terrain and the room to add more. 
We do not aim to complete this project, we only aim to get as far as we can and learning as much as possible during this project.
I will work on the tools we will use to do so, including a level editor (with a terrain editor), an asset-builder, for combining assets like models, textures and effects into a usable asset in the editor and the game.
I will also focus on building the game itself. The character movement, the physics, the particles, the shaders and everything necessary to make something awesome. I am currently using XNA to achieve this.

This is what I have so far:

It is a Windows Forms-application running an XNA View. Clicking the assets on the left will currently import  it to position 0,0,0.
You can save the scene and you can load other scenes. The scene-files are simple text-files with a reference to an asset in the asset list, a position, rotation and scale. The rotation and scale are currently not implemented, but will be in the near future. 

Upon starting the Editor, the Asset List will build. It will gather all resources from a .assets-file and add them to the content pipeline. This is quite inefficient, due to rebuilding every asset at every run and I am going to fix that. The problem is that I do not have access to the Content Pipeline as easily as in an XNA Game-application. It will not save references and all .xnb files are saved in a temporary location until the application closes.

I will try to fix this, right after I fix the camera-controls. 
I am having problems with them, because I can't decide whether I want to use a direction  relative to the -position as a camera-target or an actual target.
Using an actual target makes it easy to orbit around, but makes movement a bit harder. Using a direction makes it hard to orbit around, because the direction should be normalized and orbiting around a Vector that is 1 unit away from you isn't really useful.

More will follow soon!
Yay, my first post on my very first devblog!

First of all, let me introduce myself. I am Eric Polman, a student of at the moment of writing 19 years old. I live in the Netherlands in a small town called Eemnes. My interests lie in computers, games, game design, game programming, web development, web design, 3D art, listening to music and partying. That's practically everything I do, apart from my basic needs.

I will use this blog to keep readers up to date about my current projects including Clockwork Age (a project I'm doing with a friend of mine to prepare for our study next year), Web Development (I make sites.), Coursera classes (free education!) and more.
I will also posts things I find interesting, lovely, helpful and also things I dislike.

Enjoy!
Subscribe to RSS Feed Follow me on Twitter!