PC Games

Orb
Lasagne Monsters
Three Guys Apocalypse
Water Closet
Blob Wars : Attrition
The Legend of Edgar
TBFTSS: The Pandoran War
Three Guys
Blob Wars : Blob and Conquer
Blob Wars : Metal Blob Solid
Project: Starfighter
TANX Squadron

Tutorials

2D shoot 'em up
2D top-down shooter
2D platform game
Sprite atlas tutorial
Working with TTF fonts
2D adventure game
Widget tutorial
2D shoot 'em up sequel
2D run and gun
Roguelike
Medals (Achievements)
2D turn-based strategy game
2D isometric game
2D map editor
2D mission-based shoot 'em up
2D Santa game
2D split screen game
SDL 1 tutorials (outdated)

Latest Updates

SDL2 Versus game tutorial
Wed, 20th March 2024

Download keys for SDL2 tutorials on itch.io
Sat, 16th March 2024

The Legend of Edgar 1.37
Mon, 1st January 2024

SDL2 Santa game tutorial 🎅
Thu, 23rd November 2023

SDL2 Shooter 3 tutorial
Wed, 15th February 2023

All Updates »

Tags

android (3)
battle-for-the-solar-system (10)
blob-wars (10)
brexit (1)
code (6)
edgar (9)
games (43)
lasagne-monsters (1)
making-of (5)
match3 (1)
numberblocksonline (1)
orb (2)
site (1)
tanx (4)
three-guys (3)
three-guys-apocalypse (3)
tutorials (17)
water-closet (4)

Books


The Battle for the Solar System (Complete)

The Pandoran war machine ravaged the galaxy, driving the human race to the brink of destruction. Seven men and women stood in its way. This is their story.

Click here to learn more and read an extract!

Blob Wars : Episode II

The Making Of

Introduction

The page discusses the development of Blob And Conquer: Blob Wars, Episode 2. Here you can read all about what went into putting the game together, issues we faced, and what we did to overcome them. There are also a great number of development screenshots available throughout the article, as well as a large collection at the end (note, throughout this article, the pronoun I is used instead of we. This is only due to the manner in which the article was written).

In the Beginning...

I was a both big fan of UFO: Enemy Unknown (X-COM in North America). So, after finishing Blob Wars : Metal Blob Solid, I wanted to try a different type of game. Having just created a platform game, I wasn't in the mood to do something similar. So, I decided that since I liked UFO so much and that I had such success with TANX Squadron, I would make Blob and Conquer into a turn based strategy game.

The main idea would be that you would deploy a detachment of Blobs to a trouble hotspot and hunt down the enemy Biomech Blobs that were in the area. There might be certain other objectives that you might need to meet during that time, too. After defeating the enemy Blobs you would be able to take items and weapons that they dropped to help with your quest. Eventually you would need to capture some commanders to give you access to one of the four main bases. Once inside you would have to destroy the main powercores to bring the base down. There were to be boss fights too. At this point, it was all sounding very exciting.

Everything started off well enough, there was the ability to create units, name them, move them about. There was line of sight, firing, enemy AI, and all the other essential things a good turned based strategy game needed. I then dedicated some time to playing around with POVRay to get the sprites drawn. Since I already had a number of POV models from Metal Blob Solid, it was merely a case of making a few tweaks and then re-rendering them at different angles, so that they could serve as sprites. By the end of a not very long process, I had a number of Blobs, Biomech Blobs, Eye Droids, Bob and a few other materials that I could use for things like bridges. You can see some of the Blobs that I rendered for the at the top of the page.

After I got my hands on a new laptop, one with hardware accelerated 3D (an ATI Radeon 9700), I decided to move the game over to 3D. I did not see the point in leaving the card to sit there unused and I had always wanted to make a 3D game.

So began the process of moving the game over into OpenGL. Aside from the increase in speed and the ability to change the resolution easier, OpenGL also provided other benefits: I was able to easily change the colour of things, such as the units. It meant that I no longer needed to have dozens of different Pov-Ray sprites, rendered at many different angles, and textured differently for different Blobs. It also meant that things such as sorting were taken care of automatically. I no longer needed a routine to sort all my sprites, objects and other things and draw them in the correct order to give the illusion of depth.

Porting the game wasn't very difficult, since it was merely a case of changing the 2D representation of the battle over to a 3D one instead. But after a couple of months of working on the game, I began to realise that it wasn't really working. Sure, the graphics and the gameplay were all there, but it simply didn't feel like Blob Wars. There was a major component missing: Bob. You could not play as Bob during the game, only on special missions. Otherwise the game would play a lot like UFO and Lasersquad. You would select a number of Blobs and take them into the field. They would eliminate the enemies and level up, gaining better skills and weaponry, increasing hit points, etc. I tried to like what I had made, but I didn't. So in the end I pulled the plug on the turn based strategy version of Blob And Conquer and had a think about where to go next.

Well, the idea was obvious: I had a 3D card, I already had models of the Blobs and a few other bits and pieces. I decided that the best thing to do would be to create a 3rd person action game.

Change of Direction

With the decision made, I changed the code so that I had direct control over a single Blob (in this case, Bob). At the time the camera was fixed at an angle and I could move Bob all around. I then gave him the ability to fire and finally started on making the enemies chase after me. I then added in an objective system, with the main objective being to escort the Scout (who would later go on to become Teeka), to safety. At the time the Scout was unable to defend themselves, and couldn't fight back against the enemy Blobs; they would just run dumbly after Bob. This obviously changed later.

However, I then came across another problem - It was all very nice that I could run around this world and shoot at the enemies, but it felt very flat and there was no collision detection against the world. I could jump, but I had a hard coded Z co-ordinate in the system, indicating the floor. It was around this time that Richard was enjoying one of those quiet periods at work, where nothing was happening, and so had decided to play around with BSP loading to give him something to do. After proving that he could load BSPs and texture them, I took his code and used it within Blob And Conquer. It worked very well and suddenly I had a massive world that I could walk around in.

A great advantage of using BSPs for the world was that there was already a fantastic tool available for creating the levels: GTKRadiant. To begin with I used a few Quake 3 maps downloaded off the web. I hardcoded in the interpretation of the entities and the textures to make things work, and played around in a few levels. After I was satisfied that the BSP loading engine was working correctly I moved on to tweaking the Radiant scripts themselves so that I could start Blob And Conquer as its own project, as well as add all the game's various entities and textures.

Things began to pick up rather quickly after that and, after putting in some world-entity and entity-entity collision detection, I had successfully put together the first level of the game.

It looked very plain though. It was bright due to lack of light maps and that made the entire game lack any sort of depth. After implementing the light maps, the difference was stunning; it was like night and day. The levels really started to leap out. Learning how to light the levels was a bit of a learning experience though. Without any lights in GTKRadiant, the entire place was pitch black; too many and it looked rather garish and overly bright. However, after a few tweaks things works out okay.

One thing that I would have loved to have done was to have dynamic lighting effects. This would have meant that plasma bolts could have illuminated the surfaces they passed by, and there would even be scope for levels with little to no enemies, in which the player would be required to find a torch to light the area around them. Sadly I was unable to work out how to do such a thing. It also meant, rather annoyingly, that objects in the game (such as Blobs, cherries, etc.) would all be bright within dark areas, where, really, they should be dark or de-saturated.

Gameplay

I then moved onto various aspects of the gameplay. In the pre-BSP demo level that I had put together, the player was required to manually aim at the enemy; there was no auto-tracking like in the final version. I had a button that allowed the player to strafe, so you could run around whilst maintaining firing in the same direction. Whilst this worked fairly well in the flat version, when the game moved to the BSP levels, it became next to impossible to attack the enemies. Taking a pointer from the Ratchet and Clank games, I decided that the player should be able to auto-lock the enemies and run around whilst firing. This brought a much more arcade-like feel to the game, and simplified things a great deal.

Another major change from the original Metal Blob Solid was that Bob could now carry multiple weapons. In the first episode, Bob was only able to hold one weapon at a time. That weapon, however, was unlimited and each were useful in particular circumstances (something that various patches submitted to the game failed to take into consideration). In Blob And Conquer, I decided that Bob would be able to hold four weapons. The first weapon, however, would always be the pistol and would not be changeable. Since the Blobs do not have any kind of melee attack, it was important that Bob could defend himself when he ran out of ammunition, so the pistol was always there as a fall back weapon. It was also, again, the only weapon that could be fired under water. A few weapons did not make the grade, such as the laser cannon and a charge up gun. They became rather redundant in the face of weapons such as the plasma rifle.

Things were progressing well, but I couldn't help thinking that the world in which Bob was adventuring was a rather lonely one. It would be more fun if there was someone else there with him to fight alongside and help out. Now, I'm not one who has ever been able to get my head around network code. There are many who have never tried it either, but still believe implementing such a thing is like flicking a switch; but it is honestly not that easy. Looking at where I was now I decided that I would go for AI team mates. Blob And Conquer was already the most complex game I had created to date and the thought of adding network code on top of OpenGL, BSP modeling, entity modeling, and MD2 creation would likely be the straw that broke the camel's back.

I decided that once Bob rescued Teeka, the little Blob would join Bob on his mission. Teeka could be useful for various things, but mostly for helping Bob to solve problems. In some parts of the game, the player would need to activate two switches at the same time. Teeka could be ordered to activate one of these whilst the player did the other. In other parts of the game Teeka could also stand on pressure plates, keeping a door open or enabling a lift. And, of course, Teeka could also fight. Initially he started off with just a pistol, but it was possible for the player to find powerups for him along the way, granting him the ability to use various different weapons. All of Teeka's ammunition was unlimited, so he became a useful little ally during intense fire fights too.

With the success of Teeka I thought it might also be entertaining to involve some other Blobs in the missions. After all, the Blobs had been winning the war up until the start of Blob and Conquer, and there was no reason why I should not utilise their other skills. Three other Blob types were added: An Engineer Blob, a Hacker Blob, and a Demolition Blob. These guys were named loosely after their skill types: The engineer was named Spark Plug; the Hacker, Anderson (a reference to The Matrix); and the two Demolition Blobs were named Arnold and Sylvester (a reference Arnold Schwarzenegger and Sylvester Stallone for the destructive nature of many of their action films).

These new Blobs would be needed to perform mission critical tasks, such as laying bombs and opening doors that the player would otherwise be unable to. It also granted the ability to put a few mini-games into the game, which were activated when the player ordered Anderson to break into the computer systems. However, unlike Teeka, these Blobs would need protecting. Whilst they had an incredible amount of health compared to the player (3 times as much!), they would not teleport out of the area like Teeka did before their impending death.

The Story

The game needed a main plot, which was sort of made up as the game went along (a little similar to Metal Blob Solid). Since the original idea was to infiltrate the enemy bases, I decided to keep it like that, but with Bob having been lured away from his home base I decided that the Biomech would be attacking his own home base during his absence. That was all very well and good, but I like my games to have a bit of a more intricate plot.

Half way through I decided to throw a curve ball into the plot: there was to be a fifth Ancient Tomb. In Metal Blob Solid, Bob had known only of the existence of 4 tombs and 4 crystals, so this was to be a major worry for him. The new crystal in question was a Life Crystal (the previous four being, Fire, Time, Space, and Reality). Of course, having started down this route, there could really only be one person behind this: Galdov. I originally did not plan to show that Galdov was still alive until the very end of the game, but once Bob and Teeka had ventured into the Ancient Tomb, he was the obvious choice for the boss.

Another addition to the game was the appearance of a new type of Blob. Aside from the standard Pistol, Machine Gun, and Plasma Blobs, I introduced the Dark Blobs. These guys were black with glowing red eyes and were basically Galdov's personal army. They were a lot stronger than normal Biomech Blobs, carry multiple different weapon (which they could switch between), and would not drown when they fell into water. In such a case they would teleport to safety and re-appear near where Bob was once standing. Nasty buggers they were. I had to tweak their skills and hit points numerous times when they proved far too difficult to take down. There were also Dark Eyedroids, who Galdov could summon during the player's encounters with him. These enemies would prove crucial in the defeat of the Galdov.

At the end of the game, I revealed a stark revelation about Bob: he was over 1000 years old. The Blobs had not originated on the planet that they now lived on, but had fled there after Galdov had attacked their original homeworld many hundreds of years earlier. Galdov was a fallen god and had attacked the Blobs' planet to get his hands on the four Crystals. Using their power he would be able to return to his godly status and bring chaos and ruin to all living things. The Blobs were defenders of the crystals, Bob having been elected by a group of Elder Blobs to defend their race should Galdov threaten them again. For this purpose, the Elders had bestowed on Bob a very long life indeed. But after all the many years had passed, Bob's memory had faded and he had forgotten his charge. It was only when Galdov and the Biomechs had attacked the Blobs year earlier had Bob's skills forced themselves up from where they had been buried, thus explaining why he was so unstoppable in Metal Blob Solid.

Well, I liked the idea anyway!

This plot was set to continue in a third, final instalment where Bob would travel, alone, to face Galdov and destroy the evil Blob once and for all.

Problems

As one might expect from a game of this size and scope, there were a number of problems. The main problem that I faced during the development of this game was that it was entirely in 3D. Traditionally I had only been a 2D programmer. 2D is easier from almost every single angle - Your graphics are 2D tiles and sprites, and, in most cases, do not need to be drawn from loads of different angles. With 3D, you obviously need to model your objects and then texture them. The results are generally worth the effort, but it is certainly not a very quick job at all.

Another problem is that of collision detection - there is a lot going on. BSP trees need to be constructed and used. In a 2D platform game, you already have the world segmented up, via the tiles. For something like that it is just a case of checking to see if the player has attempted to enter into a tile that they might not be able to (such as a wall), and clipping or handling the response appropriately. BSP trees on the other hand have a number of checks against leafs and brushes which can be expensive when recursion takes place.

There was also the matter of allowing the player to save. Because, unlike Metal Blob Solid, the player could encounter save points on levels, it meant that all the current activity on the level needed to be persisted - Blobs, enemies, bullets, items, weapons, teleporters, states, etc. It would be no good if, upon reloading, the enemies, bullets and items were all back in the same place as when the player had entered the level. I managed to get around this one fairly well - By allocating an unique id to important things in the game would, I could re-assign ownership or bullets and items when the game was reloaded.

The Blob allies also proved slightly problematic. When not fighting, they would try to run directly towards the player, jumping gaps as need be. Whilst this was okay for a few situations, it meant that if the player were to walk around a corner, the Blobs would get lost and not be able to find their way to Bob. This led to a certain amount of backtracking to rescue them. I tried a number of solutions to this, but eventually hit upon quick an obvious one: Bob dropped breadcrumbs as he walked, and these crumbs would age as more and more of them were added. When a Blob was unable to see Bob, they would look around for crumbs close to them instead. Once they had found one, they would pick the youngest of the group and start running towards it. They would then follow the trail until they [hopefully] found Bob once more. It didn't always work, the Blobs could still get lost if they fell off a ledge into an area that Bob had never walked. Also, if Bob had performed a rather strange route to get to his present location, the Blobs could get stuck again. Overall though, the solution was a fairly good one.

Teeka went through various shifts during the game's lengthy development too. At first Teeka would disappear when his energy hit zero. He would then re-materialise after about 10 seconds. This was fun, but for some reason I decided that it made the game too easy. I then changed it so that Teeka had an insane amount of energy, but could still die. His death would immediately fail the mission. After a few versions of this, I realised it was a very bad idea, and switched him back to disappearing. To keep him in a state where he could die turned him into a burden and something that the player would come to loathe. His constant teleporting in and out of the action also served to form part of the game's ending sequence where he teleports onto the roof of the Biomech Tower and saves Bob's life at the very last second. The other Blobs, such as Arnold and Spark Plug, could still die; their survival being vital to the successful completion of objectives.

But by far the biggest problem of all was the camera. It was something that had completely escaped me when I started making the game, and I should know, given the amount of problems I had experienced with some 3rd person action games in the past. When I first started making B&C I saw, to my dismay, that it was possible for the camera to wander outside of the game world. I therefore had a choice as to how I wanted to tackle this problem: The first would be to have the camera at a fixed angle, somewhat like how the original turn based game was set. This would mean, however, that one could never fully explore the levels and it might make the game a bit flat (an absurd notion, given how much I enjoyed 2D games). The other idea was simply to constrain the camera via the BSP. This worked, but led to a lot of "popping". As Bob moved around, the camera would be forced into tight areas, meaning that it was sometimes very close to the player. This, however, was something that I left alone for the majority of the game, and kind of got used to over a few years. It still had to be tackled though. In commercial games, there is often meta data built into a level to tell the camera where to go or how to handle certain situations.

I plumped for the latter. The thought of going through all of the levels and trying to see where the best place to put the camera was far from appealing. To start with I looked at how the camera was reacting to Bob's movements throughout the level and where it liked to end up. One of the most unappealing parts was the way in which the camera was placed when the player was on a lift. It was right next to them. After some coding, the camera detected the the player being on a lift and placed itself above the action, allowing the player to see what was happening around them. Other situations were handled in a similar manner. Still, the camera is far from ideal.

Conclusion

Though it may have sounded like most of Blob And Conquer was quite plain sailing, it was not. At one stage I stopped development on the game for around 6 - 9 months. I can't remember exactly how long it was, but at the time I just needed a break from the game. I then came back to it and wondered if the decision to take Blob Wars into the realms of 3D was such a good idea. After contemplating this for a while I started to recode the game as a 2D platformer once more. It basically played as a combination between Metal Blob Solid and Blob And Conquer.

After working on that for about a month (the progress was very quick - I had the first and second levels done already, and things were ramping up), I went back to Blob and Conquer to see how I might approach the boss fights. And that's when I decided that I had to finish what I had started with the 3D version. The boss fights I had implemented in the 3D version would suffer tremendously if they were put into 2D format. The Biomech Tank boss fight would basically be a rehash of the one from the first game, and things like the Galdov fight in the Ancient Tomb would not be nearly as dramatic.

So, in the end, whilst Blob And Conquer was not the game it could have been, and many fans lamented the move from 2D to 3D, I do think that Blob And Conquer worked out quite well. And, as my last game, it was worth the effort.

Screenshots

Blob Wars : Blob And Conquer - Version 1

Blob Wars : Blob And Conquer - Version 2

Statistics

Total development time    : Approx. 2+ Years
Lines of code             : ~57,000
Number of source files    : 299
Size of source code       : 1.3MB
Number of music tracks    : 20
Number of sound effects   : 128
Number of images          : 346
Size of compressed data   : ~40MBs
Size of uncompressed data : > 110MBs
Estimated gameplay time   : More than 10 hours

Mobile site