Messing around with menus

The menu system is a whole different beast that I need to tame. Many months ago I downloaded the Game State Management code from the official XNA code samples, and found much of it helpful, if a bit too much for my needs. The code sample organized everything in “screens”, and any different game mode in it is a screen, whether it’s a loading screen, a menu, or a gameplay screen.

I found it odd that the menu should be a screen itself, and to me it made more sense to separate the Menu objects from the concept of the screen. So over time, I reworked the code so instead of screens, it just deals with the menus and the interactions from the user. In my game, I use a game state system completely different from the XNA sample, where each game state is a class derived from an abstract GameState object. This system doesn’t use stacks at all and just runs one state at a time. The game tells the current state to update itself, and the state is responsible to change the current state of the game when needed.

Menus are just an optional thing that the game states can have, and each one has a MenuManager (altered from the sample’s ScreenManager) in its base class. Those menus only belong to that particular GameState. It’s also possible to have multiple menus in each class, and the menu events can tell other menus to load. This feature is close to the one in the sample code, and it’s the one I chose to keep the most. Menu events can also tell the current GameState to replace itself with a different one, but that’s as far as it goes to being connected with them.

Getting the menus to play nice with the system I had already in place was a bit of chore. They wouldn’t communicate with all the objects very well, and I had some crashes where the game state would change, but failed to load the resources for the menus because the Content Manager wasn’t set. I also didn’t like the fact that it communicated with the Game object for a lot of things. Long story short, I changed the menu manager so it only needed the content and graphics services, which is all it really needs to begin with.

Skins for my menus

Finally, a more interesting feature comes along: menu skins. This is all custom-made feature I made just to mess around with the look of the menus. The original menus use SpriteFont to write the text to the screen. A menu skin class looks for an XML file with a particular name, loads it and parses the data to determine the SpriteFont, colors, and sprite dimensions of each text item.

This is all well and good, but I wanted to make it a bit more flashy. In each menu entry, I saved the text to a render target texture, then when it comes to draw the complete menu, draw all the textures to separate quads. Now you can add sorts of crazy effects to the text through shaders, having them activate when one is selected. But that STILL wasn’t enough for me 😛 Afterwards I applied a perspective projection before drawing the quads, so you can now render the menus with a 3D perspective! Here is a very exciting screenshot with a sample menu:

Title screen with skinned menu

I know, I desperately need some artistic assets, but I hope the picture is clear enough to show what it does. I intentionally added solid rectangles to make the perspective effect easier to see, but by default the background behind the text is transparent. So to recap, here’s what the menu system does from the presentation side:

  • Loads the XML file to determine style properties of the menu
  • Sets a render target for each menu item
  • Renders the text, and then off to the next item
  • After all items are done, a perspective projection is applied
  • All the menu item textures are drawn to different quads
  • This menu itself can be saved to its own render target texture, so it’s separate from whatever else is on the screen

That’s a lot of texturing and drawing to do. Right now it’s not optimized to re-use textures, or use texture atlases/primitive batching etc, but I will get to that eventually. For now it works fine for basic menus containing a small number of items, which is fine by me. One thing I want to point out is that the menu item text is not set in the XML. I intentionally left it this way to separate content with presentation.

Why a puzzle game?

Here’s a confession I have to make: I haven’t released any completed games to the public. When I mean “complete” I mean “fully loaded,” with finished options and menus and enough features to be considered a complete experience. Yes, I’ve gotten enough experience with XNA and DirectX (9) to make a decent 3D renderer, but I haven’t delved too much into creating full games. Understanding how to translate game design into programming is different from programming in more technical areas, like graphics or physics. Guess I got really enthralled by graphics programming last year and was hooked ever since. It’s all right though, since I consider that going into one of the deeper ends of XNA programming, and I can always tack on what I’ve learned from it with any games I make.

Most of my games up to this point have been very quick demos, or just proofs of concept. No menus on anything (well, except for a small text RPG battle system I made years ago), and nothing that I would consider good enough to show off. People are usually told to make Pong for their first game with graphics in them. Well, I couldn’t even finish making the AI for Pong. Most of that I stuck doing is doing some puzzle games here and there but back then I haven’t had enough experience to keep pulling through. Actually, I did release one homebrew puzzle game for the PSP, and it was featured on the site’s articles as well, but I never got around to finish it. It was a pretty cool experience for developing homebrew on the platform, though.

So what is it about puzzle games that keeps bringing me back to make one? Well, for one thing, a lot of stuff can be abstracted away from them and still have the potential to be fun. A lot of the focus seems to be on the rules more than on the presentation. The rules of a puzzle game are very tightly defined, and the right set of rules would produce a winning formula that can make a game fun for many years, even if the graphics are out of date.

Speaking of graphics, there isn’t much pressure to make them look top-notch in puzzle games. Great graphics are a plus if you want to get soaked in an atmosphere and setting, like Luxor or Puzzle Quest. But they are not necessary. Setting and story are completely optional for these games. You don’t need a good artist or a writer to create a compelling puzzle game. It’s much easier to do and I don’t run the risk of my expectations overshooting my abilities. Many aspiring game developers want to make the next great RPG or action shooter, but I quickly realized that’s biting more than what I can chew, especially when it comes to balancing the difficulty.

In that vein I chose the match-3 formula of Puzzle Bubble/Bust-A-Move as this was a game I really enjoyed many years ago, and a lot of people still enjoy playing, even if that game is one of its many, many knock-offs. So even though it’s a very overdone kind of game already, I’m just hoping people will still pick up my game and enjoy it. Of course, I want to add my own touch here and there. I already have a gimmick set up for it- climbing up towers, and my game will hence be conveniently named Bubble Tower.

Game modes

How will Bubble Tower be played? Well, in its single player mode, you can expect pretty much the same kind of gameplay as Puzzle Bobble, just with a slightly different feel for progression. In Puzzle Bubble (don’t know about the sequels, though), you play through 99 stages and then get to the only boss in the game. As any good game should, the stages consistently increase in difficulty.

However, I want to add a “hook” with the tower climbing idea. In just about every bubble-popping game I saw, you want to keep the bubbles from dropping too low. In Bubble tower, the game will pull a reverse Soviet Russia and instead of having bubbles crush you, you go straight up to the bubbles. Basically, you will be riding a large elevator/ lift inside the tower that has your bubble cannon on it, and the lift gradually goes up as you fire more bubbles. If you can clear the bubbles in time, the ceiling retracts and your elevator quickly ascends to the next stage. You finish climbing the tower by completing all the stages in it. That will reveal more towers that you can enter and complete.

Other modes may include the ever-predictable Endless mode, which is just what it says. Keep removing bubbles as long as you can, in a infinitely long tower. I think it would be cool to start on the ground, gradually make your way into the sky and even into space. Some other thoughts are, increase the speed as you get farther into it. Then there’s the additional Puzzle mode which are just stand-alone stages for a greater variety of puzzles.

Aside from single player modes, I plan to make Bubble Tower a multiplayer experience on both PC and Xbox 360. I could only find one other game like it on Xbox Live Indie Games, and I thought to myself, I can do better. It doesn’t even have multiplayer, so I will already have an edge on that. Plus, Puzzle Bobble Live on XBLA costs 10 bucks. Selling it for $1 or $3 will be an attractive price point as an alternative.

Multiplayer modes will include the usual 1 versus 1 game, with you against a computer or other person sending attacks at each other every which way. I also want to include an online versus mode, which could be a challenge because I haven’t done any network programming before. I’m also considering 3 and 4-player versus modes, which can get hectic but possibly also more fast-paced and exciting. There may even be a co-op option in various combinations, like 2 vs 1 or teams of 2 vs 2.

Extras, and what’s next

Features I will add to the “maybe” pile are a stage editor and a replay saver. The stage editor is not something out of the ordinary, but the replay saver is something I haven’t seen in these types of games before. I think it will be a nice addition to the hardcore puzzle enthusiasts that not only want to share high scores, but their best games as well.

Now to talk about what I’ve already done, and what’s next immediately ahead of me for this game. So far I’ve put stuff on the screen, load random bubble, shoot bubbles, make said bubble clear a bunch of others, a simple scoring system, and have the minimum Victory and Game Over conditions to restart the game. It’s still not easy on the eyes, but this is actually starting to become playable considering its progress. The logical next step seems to be adding a basic title screen and some menus, so you have to actually click a Start button or whatever to get into playing. I already have my own game-state switching code I’ll use for the game so it’s not so hard to continue with that. By my next post, the game should have some of the menu items finished. Finally, it will start looking like a real game 😛

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!

Bubble game, day 1: From paper to the screen

I will now be focusing more on actual games I’ll be making. To read more about this, go to my previous post.

Here’s have I’ve done for Day 1 (yesterday) on my bubble popping game. I will be posting a new article at the end of each day to show my progress.

It all started with the idea of making a Puzzle Bobble-like game with XNA, which could eventually be “facelifted” and ported to the Xbox 360. I really liked playing Puzzle Bobble when I was little and it’s a formula that never gets old. With a mix of action and puzzle gameplay, it’s a good candidate for my first XNA game. I’m sure most of you know of Puzzle Bobble, or if not one of its more recent clones like Frozen Bubble (just look it up).

It’s a huge departure from the graphics rendering stuff I’ve been doing, but don’t think that’s over yet. During my week in completing the game, I will only focus on the essentials, which are the core game mechanics, a menu system, and a good presentation. Past that, however, I would want to revisit the game and polish it a bit more- move from 2D to 3D graphics, add a few more game modes, and more features like special bubbles, skins, and items, and even perhaps give it personality with added characters. With the core gameplay already done by then, I can more easily pitch my game to  people in order to get more interest in it.

This is what I’m all hoping to do if I were to actually sell it on Xbox Indie games, as I want my first game to be as polished as possible. But that’s all a ways to go, so back to Earth for now. What did I do on my first game of development? Well, not much on the programming side. All I wanted to do on that end was at LEAST get some graphics onto the screen. The first day was dedicated mostly to planning and sketching out ideas. I started writing up some design ideas, but mostly just to get the gameplay stuff out of my brain and onto paper. I wrote some pseudocode to describe the logic flow of the game, and for some steps (like matching up bubbles), I will write more on how I will solve these steps in detail.

I also decided the general order on the game features I’ll be added so the game will be built as logically and smoothly as possible. From first to last, I plan to do the following:

  1. Get a grid of bubbles onto the screen
  2. Placing bubbles on the grid
  3. Match same-color bubbles and the steps to remove them
  4. Add basic physics to shoot the bubble from a “launcher”
  5. Set rules for next level / game over conditions
  6. Load a puzzle (simple level) from a file
  7. Add menus and perhaps options for settings
  8. Improve graphics, add sound
  9. Give it a title!

This would be the general order but I don’t know exactly which days I’ll be working on what. I would want to have at least a playable self-enclosed “game level” by mid-week.

Step 1 was done on the first day. I made some very simple sprites and put them up on the screen. I’ve decided to have a fixed number of rows, displaying bubbles of random colors. Each bubble is just represented as an integer for now, but that may change if the game rules demand more complexity. The numbers 1 through 8 represent eight colored bubbles, and 0 is for empty spots.

As with all games like this, the bubbles are arranged in the usual staggered fashion, with alternating rows being offset horizontally. This will be a big part of how I will figure out how new bubbles “snap” to the grid and how to clear them. For now I wrote a simple function to place random bubbles to fill a fixed number of rows. As a debugger I assigned a keyboard letter to re-load a new group of random bubbles. This was all done in about an hour, so as I said before, not much programming work that day.

There’s not much to show right now but it will be a lot different in a few days. Note that I have them arranged in rows of 8 and 7, which is like Puzzle Bobble. However newer clones of this game take advantage of higher-resolution screens, so they might have 10, 12 or even more bubbles per row. I might bump it up to 10 per row, and reduce the size of each bubble sprite from 64 pixels down to 48 pixels.

The game may be ported to Xbox, and it will use the widescreen aspect, so there is a lot of real estate that’s not being used for gameplay. Most of that extra space will be used simply for decorative purposes, which is why I would like to make it look a lot nicer after the game proper is finished. Well, that’s all I have to show for Day 1 and today I am working on the next step- placing bubbles onto the grid. Since my time for making the game is pretty limited, I don’t want to waste much time writing these posts. Day 2 will follow soon!

New game plans, and going further with XNA

So where was I? Well, for the past few months I haven’t had a job, so I’ve been preoccupied looking for a new one, as well as trying to get my personal finances together. Because of that I’ve had little drive or motivation to continue game programming. But all is better now, I’ve finally found work and glad to get back on my feet and start coding again! I won’t have as much time as I would like, but because of that I will be working more efficiently.

My blog will also be taking. It will be focusing more on game programming and talk about actual games I will be making. This will be a big change, because most of the past posts so far have been very technical and also about ideas and techniques that may be applied to games, but not really about games themselves. It’s a new direction I hope will improve my productivity, since for over a year now I have always wanted to create some indie games and launch them on gaming platforms such as the Xbox 360 and PC. With a clearer mind, I can finally picture that happening.

However, due to my past circumstances, the racing game idea I brought up in my last post never even got off the ground. It was way too ambitious considering the real life challenges I was facing, so that will be put on the back burner for an unspecified period of time.

Instead, I am holding back for now and do something more basic but still enjoyable- a bubble popping puzzle game. To make it more interesting I plan to finish the game in one week! I’ve actually started working on this game yesterday, on Friday, so today (Saturday) will be the 2nd day and Sunday comes afterwards… yadda yadda etc. Today there will be a post for Day1 and one for Day 2 will follow up shortly.