Wednesday, 28 December 2011

Second soundtrack

Brian just sent in the second soundtrack for Blue Core. This one will be playing during the gameplay on the medium difficulty. This is an early look at the song as it might recieve a few changes still. Have a listen! For more great works visit Brian's homepage (BonsteelAudio). Otherwise, this week has been a bit slow due to the holidays and everything that comes with them. I did manage to implement a pause. The player can now pause the game and if he does, music starts playig, which Brian is already working on. Happy holidays to everyone (at least what's left of them).

Sunday, 18 December 2011

New gameplay feature and saving system

This week I've tried hard to make a lot of progress since last week was a bit slow, because we had midterms all week at the university. And progress I have made. So let's take a look at what's new. During the week I took some time away from my studies to give Blue Core a new gameplay feature. Some, or most levels will have some special occurrences happening, from time to time, that spice up the gameplay a little bit, and the first such occurrence that I've managed to include is a speed boost. The game basically shoots out a particle of a different colour, indicating that a change is about to take place, as you pick it up, (and you must pick it up or else you lose) the new game mode, whatever it may be, executes. I have made a little video demonstrating how the speed boost works:

That Is not all. During the weekend, I had lots of free time and free food at my disposal, so I was ready to make a big change to the game. So that is why, I decided to implement a game saving system. What this means is, that all the levels are now locked until you have beaten them. When you unlock levels, the information is saved into a file in your game folder, so the next time you run the game it's all still there, just the way you left it. Implementing this whole new system made me change the whole menu mechanics somewhat also. So after giving it a little thought, I realised that the main menu only really needs two options. Play and Quit. Trying to keep it simple here. Pressing the 'play' button will pop you straight into the 'level selection' screen. And for all you brain dead people who can somehow read, pressing the 'quit' button quits the game. And because I had a lot of time on my hands I decided to make a new, prettier main menu:

Ain't she gorgeous? My artistic style has advanced from the early 90's to a bit later into the 90's. Everything else is still the same though, so it looks like the level selection screen and gameplay area are from a completely different game. Doesn't matter though, it's all only temporary. Here is what the level selection screen looks like with 4 levels being unlocked:

The buttons are all bunched up into one corner like that, because after moving to a bigger resolution it made no sense to change the level selection screen layouts. That would be a major waste of time, since it's all going to be replaced sooner or later. But judging by the speed with which the art team is producing new sprites, I'm leaning towards later. The point in this screen shot is functionality. The player can easily see which levels are unlocked, and if he attempts to begin a level that is not unlocked nothing happens. Maybe it would be a good idea to prevent the player from even selecting the greyed out squares. I might implement this later, although it could be quite a challenge.
That is all for now, stay tuned and happy holidays!

Contact me at

Tuesday, 6 December 2011

Different resolutions and fullscreen support

This week I've made the game work in fullscreen mode and adapt to various display resolutions. The game figures the player's display resolution on it's own, so there is no need for setting it in the options by yourself.

Do you know that annoying feeling when you have to alt-tab out of a fullscreened game for some reason and then the computer tries to minimize your game and the whole thing freezes/crashes or just doesn't want to minimize, leaving you with a half displayed task bar and a black screen, which doesn't go away even though you are now frantically clicking everywhere and cursing at your computer? Oh, I bet it gives you nightmares at night. I bet it makes you want to buy a machete and single-handedly murder every single living being in the universe. Or maybe that is just me. But there is a new way we do things now, to make this recurring nightmare less recurring. I've first seen this technique used in an MMORPG named Vindictus. What you do is, instead of a fullscreen setting, you use a window, place it into the upper left corner of the screen, stretch it to the size of the display resolution, and hide it's edges and buttons. What you get is a picture that looks fullscreen but is actually a window. And  if you alt-tab it it doesn't minimize. So let's say you just remembered you need to check your mail but your in the middle of a game. Well just pause that puppy and give it an alt-tab, check that mail and get right back to playing. The computer won't even lag for a second.

The game now looks like this on my 1600x900 screen:

Yes I know, it's not the regular fullscreen everyone would expect. But since the game is done with sprites, resizing it causes some problems, so this is the best I can do for now. The game is always 1024x768 big, but in fullscreen mode it adds a nice blackness to isolate it form the view of your desktop. If this bothers you, there is always the windowed mode.

Saturday, 3 December 2011


Today I've made some pretty big changes to the game. I've changed the way the time between squares being shot is calculated. The time between every particle being shot from the centre used to be 60 milliseconds. But I've realised later that measuring that "pause" using actual time was a bad idea, because, if the game starts lagging the FPS drops, and if the FPS drops the paddle that the player is moving slows down, but time keeps on running. So after a while the paddle speed and the speed of the particles get out of sync and the game is unplayable. Of course this game doesn't lag. It's way too simple. On my (crappy) machine it has a constant 59-60 FPS rate. So I had to create some lag with other programs to be able to test this.
What I did to fix it was, I started measuring frames instead of measuring time. So now instead of shooting a square from the centre every 60 milliseconds the game shoots one every 5 frames.

I've also optimised the code quite a bit today. From having 1196 lines of code It came down to only 976. That is 220 lines of code less. Pretty damn sweet if I do say so myself.

Thursday, 1 December 2011

Useless useful details.

The game will come out for PC at first but I am planing to develop an Android and iPhone version after that, because I believe that smart phones is where Blue Core can reach it's full potential. The release date is far from being known. All I know now is that it's (obviously) not anytime soon. I'm putting this baby together in my free time which I don't have a lot of, because I am a student who needs to finish his studies and get a job someday. That's why I'm going to set up a donations account and drop out of school. Yes... that was a joke.
More about the game itself you say? Well It's going to be a skill game most of all. Finishing a level will unlock the next one, progress the storyline, and increase the difficulty, bringing you a new challenge to beat (30 levels of computer monitor bashing fun). The game takes place in space and in the future. It is the space exploration age. The gameplay area is a reactor core that runs a spaceship on which you, the player, are stationed. The storyline is already finished but I don't want to give the rest of it away just yet. Stick around to find out more.

If you're wondering about any details that I haven't mentioned yet, feel free to ask in an email or in the comments.

Wednesday, 30 November 2011

First video!

Here's a first look at the game in motion. I guess you can get the basic idea about the gameplay mechanics from this video. Enjoy!

Tuesday, 29 November 2011

First soundtrack!

Blue Core got it's first action packed soundtrack that will be present in the final (hardest and fastest) levels of the game. Check it out! This briliant piece of music was created by Brian Bonsteel. Check out his work at BonsteelAudio.
Send your feedback to

Sunday, 27 November 2011

Collision detection

The collision detection was really hard on me. It was the toughest part of programing yet. First I had to make an alternative to the dark GDK integrated function because it was quite inaccurate. So what I did was, I had a loop return the X and Y coordinates of all the particles that were shot out from the center, and then if any of those coordinates were located in the 'ring' where the pad is moving AND have the same rotation as the pad, the particle would get deleted.
This is the ring area that I am talking about (marked in purple):

I achieved this by using the good old circle equation: 
x2 + y2 = radius2

I simply inserted the X and Y coordinates of the particles into the function, switched the '=' with a > and for the radius I used the inner edge of the ring.
what you get is this. The next step was to limit the area from the outside, so I added the same equation, enlarged the size of the radius(by the width of the pad) and switch the '>' with a '<'. and I got me a lovely ring. The third condition requires the particle sprite to have the same angle as the pad and the whole thing works!

Well... it almost works. The real problem arises here. Spinning the pad and the particles around reqires the use of the dbWrapValue(Value) (a Dark GDK function), wich wraps the value of the angle (it doesn't let a value go out of the bounds of 0°-359° for example 359°+10°=9° instead of 369°). This caused a problem at the top of the game area (where the angle is 0°) If the pad was on the left side of the 0° mark and the particle was on the right like this:

The pad value was something like 355° and the particle value was for example 3°. Those values are far apart, so I had to make an exeption and make a separate collision function for values that revolved around the 0° mark where the values get wraped. It works perfectly now.

Saturday, 26 November 2011

Progress so far + screenshots

For now the main gameplay mechanics work. This is usually the fastest, easiest and the most fun part in game development. It took me three weekends to complete and it was quite a challenge, because it took quite some maths and logic to figure some stuff out. For instance how fast must the pad be moving to go at the same speed as the particles hit the edge. The part that gave me the biggest headache was collision detection. Dark GDK has an integrated function, that lets you return a value if a sprite is hitting another sprite, but it did not work very smoothly, so I had to make my own (more on that in an upcoming post).
Now I'm just trying to separate different game sections, like the main menu, the menu where you choose levels that you want to replay, the game itself, the game over screen, the section that restarts the game, etc. I'm trying to get the basic architecture of the game planned out basically. For this I am using some temporary sprites just so I can test if the mechanics work.

Thus far I've made a temporary main menu:

And a temporary "choose level" menu:

For an artist of my caliber the 3D buttons look pretty neat (if these were the early 90's). The bloody stain is also a temporary asset with which you choose which level you want to play and press space to engage it.

Friday, 25 November 2011

Project details

Time to talk about the details of the project. The programming is being done by me in C++. I am using the Microsoft Visual Studio 2008 Express edition. It's free. For easier development I am using the Dark GDK (game development kit) engine, which is also free and it has a great community that includes some very helpful individuals.
First agreements about the game art were also made today. The art will be developed in Photoshop CS5.
Screenshots will follow as soon as anything new comes along.

Thursday, 24 November 2011


Here are some screenshots of the gameplay. Note that this game is still awaiting the creation of more artistic sprites so I'm currently using some minimalistic substitutes that I (a man with no artistic talent) have made just so  I can see what's happening on the screen.

It is best that I explain how the game mechaics work below this screenshot. Basically the player controlls the red pad. The game only has two controlls: left and right(don't need to explain what they do right?). The game then continues to shoot a series of green squares from the center of the screen. The goal of the game is to catch all the squares without any of them escaping. Simple and hopefully fun.

If you have any questions about anything contact me at


Thank you for visiting this game development blog. There will be content as soon as there's something to post about. Stick around!