Game, meet engine

Hey guys, this time the update will be short, but some significant updates that they are. I have successfully compiled a library from my engine that would work in other projects more transparently. In fact, I was able to get the Meteor Engine to run in Bubble Tower.

But hey, check it out, more exciting game screenshots! Here’s an example of the Meteor Engine running in it.

Menu screen with 3D render

Also, particle effects! That is actually not part of the engine (a lot of things in the game still rendered ad-hoc), but it could well be.

Note that I’m using a 2D sprite image for the background here. I have deliberately made the rendering engine not clear the screen automatically so that it’s possible for other GameScreens to be seen behind it. I plan to make auto-screen clearing a selectable option soon.


The engine runs in its own GameScreen class, so it can operate independently or swap data just as well as the other screens. It still needs to be loaded as a game component for the main Game class, which is necessary to do all its updating in the background. Both screens are active as shown in the text in the upper right corner, so both the camera controls and the menu controls are working! While using the arrow keys or mouse to select menu choices, the WASD keys still move the camera around the scenery.

This is all for testing purposes, but it shows great possibilities with this kind of interaction. With some further implementation, the camera can be scripted to move around the scene according the options you select. As of now, there is no interaction between the engine and the menu screen, but that will be worked on soon.

As this project is still far from complete, I am using a debug build of the DLL to link with my applications. At first, all the content files (such as shaders and sample textures) were referenced by the library, and I often had to copy the .xnb’s over to the working directory of the program. It’s not very practical, and not a good option for distributing it to other users. A couple days ago, I added a resource file to embed all of its contents. Still no public release of the binary yet, but all the latest content and project files are now uploaded to Codeplex. The full size of the binary came out to 430kb, still pretty small for a debug build.

Already, this game has the potential to take on a much more professional look. I’m still wanting to get my own 3D content, though.


Tightening up graphics, and the other subsystems

– This post has been a hold-over for a few weeks, but I decided it’s now time to flush it to the screen! –

After coming to grips with my shortage of artistic inspiration, I’ve decided to go on full steam ahead with my game features and underlying systems. More menus, more screens- including the ubiquitous Pause screen- a continuous rebuild of the underlying system that controls them, and I even did some touch-ups with the visuals. Bubble Tower is slowly but surely becoming more polished in gameplay and presentation.

First I want to talk about the visuals, because it’s will just be a short overview. There are no graphics other than menu text, bubbles, and backgrounds, but I’m moving on to using more with 3D rendered graphics for a lot of the stuff. So I start with the most obvious, the bubbles. The original spritesheet contained 8 bubbles, one for each color. I decided to stick with this principle but generating the spritesheet at runtime by drawing the mesh to a render target with 8 different colors and viewports. I get to keep the original code that splits up the spritesheet and select the appropriate colored bubble to draw.

What’s nice about this is that the bubbles can be animated, or they can be replaced with another mesh. After working on a shader to get the highlights and shading looking just right on the bubbles, I messed around with some other geometric meshes, and found one that I got stuck on. I was inspired by the gem puzzle games and wanted to use more interesting shapes. Mine look more like some sort of paper origami balls than bubbles now, but I actually like the look. So after all it looks like I am getting somewhere with the visuals. Afterwards I just stuck in a wallpaper as a test background.

Improving the screen system

The more I try to make the screens do what I want, the more bugs I was finding, but I’m smoothing out the screen system as I keep progressing. The screens have the ability to transition in and out of view, with user-defined times (as far as user-defined animations I’m working on it). This added a lot of code bloat to the GameScreen class, so I isolated all this transition stuff into its own Transition class. Now every screen just has a Transition that it can use internally.

I’ve also made a new type of screen, the Splash Screen. Splash Screens are non-interactive, stay on for a fixed amount of time on the center of the screen, and leave. They can have text or an image. In the essence of time, I initially reused a class to display menu text, but broke it down further because it wasn’t using the button click functions.

It’s also possible to load a series of splash screens, each following in succession, with just one function call. The trick is passing a string array with your text in it, and storing it in the splash screen. The first splash screen uses the first string of text, removes it from the array and when it’s going to exit, passes the shorter array to a new SplashScreen constructor. If there is a transition time, you will see the text/images smoothly crossfade between each other. This feature is great for displaying several game logos in a row, or  having a visual countdown with your own text. I would not use it for long still-frame cutscenes, though. The player doesn’t have control of the splash screens, so not being able to skip through them would be very annoying.

Rules and control flow

Adding new splash screens on top of interactive screens have made the control flow a tad unpredictable, because I would want some splash screens to take away some control from the player, but not some others. I initially decided to make a distinction between interactive screens and non-interactive screens, and loop through the interactive screens to read input events, but that just made the results more confusing.

Here is the current list of screen classes that are used in this game:

  • GameScreen
  • GameMenu
    • MainMenu
    • LevelSelectMenu
    • PauseMenu
    • GameOverMenu
  • MainGameMode
  • LevelEditorMode
  • BackgroundScreen
  • LoadingScreen
  • SplashScreen

The menus may seem redundant in distinction, but I won’t need many menus anyways, and totally fine hard-coding the pathways in them instead of using external scripts. On the quest to make the screen manager more robust, here are some rules I’ve set to implement:

  • If a new screen is added, start reading input (if it’s interactive)
  • If the new screen is marked “exclusive”, stop updating/reading input for other screens
  • If an exclusive screen is removed, read input from the other screens again
  • Screens may start reading input as soon as they’re entering, or when they’ve completely entered
  • Screens should stop reading input as soon as they’re leaving

Pretty straightforward stuff. Here’s where the rules become more involved:

All screens undergoing transitions should be allowed to complete the transition phase.

What this basically means is, if a screen is exiting or entering, the transition timer that counts down or up must not be stopped at any cost. Just keep it going. To accomplish this, the transition updates need to be decoupled from the user-defined update code.

The reasoning behind this is, sometimes, an exclusive screen may enter at the same time other screens are entering. The exclusive screen wants to stop the others from updating, but if the transitions are ran in the Update function, those other screens will never get to complete their transitions! Decoupling that from the Update function would be the way to go, so I moved all the transition logic to an UpdateState function, which will always get called no matter what.

Avoid adding or removing screens while other screens are being queued for updates/input reading.

The screen manager has two special lists, ScreensToUpdate and ScreensToReadInput. ScreensToUpdate is a mainstay from the XNA code sample for game state management- it simply tells the manager to call Update on the screens in it. ScreensToReadInput was added later, and this tells the manager to HandleInput from the screens on that list. This action is done before calling Update on all the screens.

Here is the order of functions that are called in the game’s main loop:

  • Read input from screens
  • Update screen events
  • Draw each screen

There is no particular spot that says where AddScreen or RemoveScreen is called. They may be called one or multiple times where screens are updated or reading input. That can have undesirable effects and can lead to subtle bugs if we’re not being careful.

Suppose that in one screen inside the ScreensToReadInput list, a key press was detected which will tell the screen manager to remove this screen and then add another one. That would potentially modify the list while it’s still looping inside of it! This would throw an exception if done in a foreach loop, so you have to use a for loop to iterate through instead. Still, modifying a list of screens while screens are updating can lead to unexpected behavior.

Updating screen lists

To resolve this problem, screens should not use AddScreen or RemoveScreen at all. These two functions can be made private, and there are two new functions to supplement them: PushToAdd and PushToRemove. Those would be the functions that screens can call, to notify the screen manager that there are new screens waiting to be added or removed.

Both functions would add a screen to one of two new lists: ScreensToAdd and ScreensToRemove. They are a sort of waiting list for the screen manager to go through. The purpose of this to move AddScreen and RemoveScreen calls inside a separate function, away from updating and reading input. The new loop of functions would look like this:

  • Add or remove screens
  • Read input from screens
  • Update screen events
  • Draw each screen

The ScreensToAdd and ScreensToRemove lists are guaranteed to be cleared by the time the screen manager is done with the first step. Now we would know exactly where new screens are pushed or removed from all the lists.

Determining screen priority

Why not just have the topmost screen receive input, you might ask? Sometimes you’d want more than one screen at a time being interactive, like a group of menus for a strategy game. Or the aforementioned splash screens that would still allow player control of screens underneath, I’d have to give them a special flag or property that says they are not “exclusive”. I plan to use splash screens more in this way, such as displaying larger score numbers or messages for clearing certain groups of bubbles.

Once I have all these problems sorted out, though, I can go back to adding more game-centric features, and hopefully adding a two-player mode. Still don’t know how I’ll work that one out, as I am just using a keyboard and don’t even have an Xbox controller to hook up. I can always take the more daring route and start coding an AI to play against the player. That would certainly be another challenge, but most likely I will just start out making the “AI” fire bubbles at random times in random directions, then gradually mold its crazy mind into something more coherent. But for now, on to polishing more menus!

Quick update on some of the game’s modes

Just wanted to add a quick update with a video on the progress of my game. The features it has so far: almost working 1-player mode, easily customizable menus, level progression, a level editor, 3D graphics for billboard sprites, and a slick screen animation system.

The graphics are still not final (far from it) and game art will probably be the last thing on my list to finish. More details to come soon!

New screen system, but stuck on the visuals

Bubble Tower is still underway, but the progress has been somewhat slower since its inception. There’s a lot that I fixed and improved under the hood, but I’m at a standstill for creative work. First the good news…

I spent a lot of time last week with moving from a game state management system to a screen management system. If you are familiar with the XNA code sample, you’d know what it is. If you’re not, I basically have moved away from using a last-in-first-out data structure to manage game states. Menu management and state management are now one and the same, with them all being treated as “screens” which can be added on and removed at any layer. This adds a ton of flexibility for creating better interactions and transitions within games, and easier to scale in more complex games.

Through the course of converting all of my code, I stomped out a lot of bugs related to loading and displaying menus, background screens, and content in the game. I also got around to getting levels to save and load correctly with a flat binary file. All the levels in the main single player mode of the game are to be stored in one file. Before, any level you saved completely overwrote the entire file, so it was impossible to keep more than one level at a time, but now all levels should save and load correctly. Now to improve on the menu so that I can scroll through several “pages” of levels.

Coming short on visual details

Now for the stuff I’m still stuck on. I really need some art for my game. After doing so much to improve the functionality of the game, I want to move on to the more artistic visual work. Problem is, I’ve hit a creative roadblock. There’s not much inspiring me to add some nice art to the game, and it’s really killing me to keep working on my game when visually, it’s not so appealing.

I know this is a puzzle game, where I can get some leeway to be more simple and abstract with the art, but I’m already getting tired of looking at the same plain screens and graphics. Maybe this is part of what game testers feel when they’re repeating the same tasks, but at least they’re not responsible to do the work that artists will eventually do.

What’s interesting is that I’m a visually inclined person- I majored in art, and know a good UI when I see one, but I am not really that good in going into extensive periods of drawing and sketching out from my ideas. Those only come to me in short bursts. Also interesting is that making 3D art tends to come easier to me than 2D art. Not that I make some super detailed, realistic stuff, but that I am more satisfied with the finish product in 3D than whenever I take a shot at doing 2D art.

Looks like I should start playing more games for inspiration. The theme of climbing and ascending towers is still something I want to do, so at least I have a starting point there. I might have to go the 3D route to do most of my art, but it will take me some effort to actually get into sketching out some ideas on paper until I find something that I like and can work with on the computer. Time to get my other side of my brain to work overtime.

Bubble game, after the first week

As you may have guessed I haven’t had time to keep doing daily updates for my bubble game progress. It’s not that I haven’t been working on the game anymore, but for most of the week I’ve been at work which doesn’t leave much time for me to work on my own projects. For those days, I’d have 2 or at most 3 hours for myself if I’m lucky. Drafting and posting an article can take me up to an hour, so for any time spent on that, it was better spent finishing up as much of the game as possible.

Finishing up?

So the week’s gone and it hasn’t all been complete as I originally planned. I didn’t get to start on the menus, and no additional graphics or scoring system is in place. But I have managed to put together something very workable in just a week’s time, and have a good foundation towards a fully fleshed-out game. During that time I fixed the a major bug that kept some bubbles from falling when you popped the ones above, and it only happened in certain cases, where almost the whole is cleared and you were able to get to the ones in the top row.

Additionally, I’ve placed all the necessary rules for a game over, so now the game keeps you from shooting bubbles when they overflow, and you can restart with a fresh new group of bubbles by pressing the A key. The targeting system has been left nearly untouched since I last worked on it, and for me that’s okay. There’s still a decent amount of challenge to be had with that, considering that there are many bubble games on phones that use the touch screen to directly aim where you will shoot. Eventually, I will add a more traditional control scheme using left and right controls to rotate the launcher towards the direction you want the bubbles to shoot.

The bubble sprites have been resized from 64 to 48 pixels, allowing for at least 11 rows of matching fun. This would keep it closer “to the original” in terms of challenge and gameplay. This left even more empty space on both sides, which could be used for a lot of things in a first player setup, and roomy enough for two-player screens as well. I may consider having an extra one-player puzzle mode with larger, wider playing areas.

The future of this project

In a step I would consider making the game project “official” in the long term, I’ve set up a Subversion core repository with Assembla to keep track of my updates. This will go well beyond what I’ve done in my first week. I plan to turn this into a serious project, and showcase my progress in various communities online when it’s at a good enough state to get some detailed feedback, and get a feeler for interest on the game.

Since it’s being made with the XNA framework, Xbox Indie Games seems to be the natural first step towards distribution, but I’m keeping my options open for anything else depending on the progress I’ll be making. I know these sorts of games can be found for free on the web so I have been doing some research and exploring similar games, to see what I can do to give my own game an edge. I’d be happy already if I can get it in the hands of dozens of players, and get some positive reviews from it. But these things will be on the long term list. For now I am comparing other games to see how I can add or enhance on them.

Bubble game, day 3: Shoot ’em up

For the third day of this project, I worked mostly on getting a shooting mechanism to launch the next ball onto the board. This also meant I had to introduce simple physics into the game and re-created some the Bubble class in order to make it work. The game’s main Update function grew a lot here. Here’s the pseudocode for it:

// See if the current bubble is moving, then update as necessary.
if (currentBubble.IsMoving())

    // Find picking/target spot with the updated position
    picked = PickClosestBubbleSpot(currentBubble);

    // Check if bubble collided based on target spot
    // If there's an empty spot in the first row, just add it in
    if (currentBubble.InTopRow())
        AddBubbleToSpot(currentBubble, picked);
        foreach (neighbor)
            // Check each neighbor for collision until it found one
            if (currentBubble.CollidedWith(currentBubble))
                AddBubbleToSpot(currentBubble, picked);
    // At this point, all color matches have been counted
    // Bubble is waiting to be launched
    if (MouseButtonPressed())
// Clear any bubbles if there have been at least 3 matched

The bubble launcher is what I’ve been doing most of the day, though I didn’t spend much time working on the game. But I can say there were some bugs along the way, such as trying to position bubbles from an empty array (which caused the game to crash), and bubbles replacing existing bubbles in rows that start off being empty.

Not much else to show graphically, as it’s all still the same, so I won’t be posting screenshots. After fixing all those related bugs, I added an animation to make the bubbles drop after they have been matched. The dropped bubbles still have their original row and column location, but their actual position on the screen is updated. After they leave the screen, the bubble Type is cleared to 0 and the positions re-calculated.

Now, time to add a scoring system, and some standard rules to make the game more flexible.

Bubble game, day 2: Matching and picking

Another day has gone, and I have made much progress with my game. I have implemented some very accurate (but not completely perfect) bubble picking, as well as the ability to match like-colored bubbles and clear them from the board. Also, I’ve made some nice bubble sprites as a head start to give the graphics a more professional appearance. Even though some important features are still missing, the game is already looking very playable. To add some more flair, I made the bubble grid move which tested the new features really well.

Bubble Picking

First, I wanted to figure out how to pick the bubbles individually. I did this so that I get to testing the color matching algorithm sooner than later. This way I can just move my cursor to any point on the screen and place a bubble in the closest empty area near it. Also, this would be a good foundation for a “puzzle editor” that I will no doubt work on later to easily make new levels.

Picking items in a square grid is very straightforward to figure out, but these bubbles are laid out with rows overlapping slightly and alternating positions on even and odd rows. The best way to look at them is that they are closely packed in a hexagonal grid. Imagine a hexagon tightly enclosing each bubble, and the hexagons are all next to each other in a repeating pattern.

Figuring out the picking system for hexagons actually stumped me for a while. I decided to cheat a little and take a shortcut. The picking system isn’t 100% accurate but its inaccuracy is almost unnoticeable and still feels intuitive. Due to the tighter packing, the ends of the bubbles overlap a bit in rows. Since the bubbles are next to each other at 60 degree angles we can conclude that the vertical distance between each row is diameter * sqrt(3). Then just take the Y location of the mouse cursor to determine what row it’s on, and then clamp the values if you go off the edge. The column is determined whether it’s an odd or even row, offsetting the position by the radius where necessary.

Matching the Colors

There are many coding tutorials to make puzzle games that use the “match 3” mechanic, but I chose not to use them and code it from scratch. Yeah, I know this is a 7-day challenge, but was pretty confident in knocking this one out quickly. I had already figured out that I would be using a recursive function, and just returning the total number of matches in the function seemed to be the most logical way.

At this point, using an array of numbers to represent bubbles wasn’t enough anymore, so I made a smallish Bubble class to store row and column position, bubble type (color) and a general purpose bool flag. This flag would be useful for doing all sorts of checks in the game loop, whether to clear matching bubbles or do something else like prep them during changing gameplay states. When a new bubble is added, it checks its neighboring spaces (up to 6) to see if any bubbles with the same color exist. Any matches are flagged and added to a local list, and after all neighbors are checked, it start the process again with the found matches, moving on to another bubble.

When the last color matching step is done, the game needs to “clean up” the bubble area. This means, if at least three matches are found, it removes all the flagged (matching) bubbles. In reality, no Bubble objects are removed, they are simply reset to a “neutral” type of 0 (no bubble) and the flag is reset to false. It took a while to get the results I wanted, since I also optimized the code a bit after adding the Bubble class.

New Sprites and Movement

After being satisfied with the various short tests I did, I made some new bubble sprites. Although I’m not a great artist, I’m pretty familiar with most of the Photoshop tools and was able to make some shiny new bubbles just with some reference images. I don’t want to end up borrowing/remixing a ton of free game art, as I want to make the game truly “mine” and avoid dealing with the rules of how to use the art. The new sprites already make the game a lot easier to look at and play.

I feel that’s good enough progress for one day, but then I thought “does my stuff hold up with moving bubbles?” The functions to draw and pick bubbles use an offset location in calculating where the bubbles are. I made the offset’s vertical position change each frame with a basic sine function so the whole board smoothly moves up and down. The cursor responds accordingly- it knows where the bubbles are at any frame and picks the right spot, and the newly added bubbles move along with it.

That concludes day 2 of my game development. Now it’s time to make it more action-y, by adding a launcher and physics for moving objects!