Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Building Block Heroes - Secret Rocket Base

Sign in to follow this  


Building Block Heroes - Secret Rocket Base

After making their way through the depths of the Oceantide Channel, the Building Block Heroes find themselves at the Secret Rocket Base!


Map SecretBase

The Secret Rocket Base is a well-hidden military installation that houses a space-faring rocket that the Building Block Heroes will need to commandeer in order to attack Rupert's Moon Base directly.


The Secret Base is probably the most difficult area in the game if time limits are enabled due to the barriers the players encounter. The barriers in this case are literal, as the new type of block encountered in this area are called Barrier Blocks.


Barrier blocks are more durable than regular blocks, requiring three blocks or breakers of the same colour to be detonated next to them before being destroyed.


The enemies in this area are relatively benign and just patrol back and forth like enemies in earlier areas. However, the enemies in the Secret Base are much bigger than other enemies, which forms a problem in and of itself.


The boss of the Secret Base is Rupert himself! Or, rather, Rupert taking potshots at the heroes from a gun turret.


Rupert will follow the heroes around with a targeting reticle, taking aim until firing a shot that obliterates all the blocks around him or her. It does help to have a friend for this battle, as Rupert can only target one hero at a time. However, he does fire more frequently when there are multiple targets for him to take aim at.



The Secret Base was a huge pain to design. The colour scheme for this area wasn't immediately obvious, and it was difficult to think of one that would be unique. Specifically, I was having trouble figuring out how to make the mechanical parts stand out among the rocks. The breakthrough came when I decided to turn the rocks into a brown/tan colour, which immediately solved the problem of making the area look unique.

Rock 1

This itself lead to the design of the rocket because it opened up the possibility of a more cartoony and colourful rocket rather than the plain, grey mechanical one I envisioned at first. I'm a big fan of Tintin comics, and while I was designing the rocket I was reminded of the one that Tintin took to go to the moon (which itself was inspired by the appearance of the infamous V2 rocket designed by the Germans in WW2). I figured I could use a similar checkerboard pattern for my rocket.


I knew I wanted a gun-based boss to fit with the military theme of the area. Originally, the boss was a regular Mechafolk boss, like in the other areas. However, as I was designing the boss, I decided to throw Rupert inside it to add a dash of colour to the boss.


The music was inspired by early Command and Conquer games, with their industrial funk tracks that took a military/industrial setting and made it catchy rather than being serious or sober like one might expect. For this I started off with the electric guitar hook and added a fast, upbeat percussion track. Thankfully, military settings tend to lend themselves quite well to brass melodies, which at this point were starting to become something of a hallmark of my music. The melody, then, was an absolute cinch to compose once I had the background hook nailed down.

Let me know what you think! The game is on sale this week on Steam:

Building Block Heroes on Steam

Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Plotnus
      Hello all,

      I'm looking to learn some tools for making programmer art. (for prototypes and whatnot)

      Are there any resources you've used that have been very helpful and stood out to you when learning art skills as programmers?
    • By jb-dev
      This is how loading screens will look like. I still have no idea whenever or not I could show things like tips or anything alike...
    • By Tanzan
      Hello  all,
      I just finished my first Android game and published it on Google play...
      I know its not the next red dead redemption2 but it would be nice to have some comments/feedback on it if its worth it to go on with a release 2.0. or move on to the next game? (red dead redemption 3  )
      Anyway thx for your reading time and i hope on some nice reviews!
    • By Sultown
      Good evening.
      Before I get to my question, I'd like to clarify that this is in a 2D (2.5D) view with pixel graphics. While making mockups, a question on map design came to me. If I were to draw an entire section of a map, including stairs, buildings, etc. would I be able to set constraints so that a character could move realistically on one asset (the room, I guess), Instead of having to place each and every tile for every corner, or variation in design, or every stair?
      I feel like this would be much easier when it comes to very intricate room designs that would be much cleaner and aesthetically pleasing if I could just put wall barriers (native to my engine) where the player can not go.
      Let me know if this needs clarification or if this is in the wrong subforum.
    • By Programmer One
      I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go.
      For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better.
      What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has:
      The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]).
      But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either:
      Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking:
      I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!