Pollinator, Flower Defense - Enemy Spawning and Bee Movement

It's time for my weekly update on my Game Development Society game, Pollinator! I missed last week's update due to having nothing to report - Building Breakout took up all my time that week. Luckily I had some more time this week, and was able to complete two major features in the game.

Enemy Spawning

The first new feature I created was the enemy spawner. This object is responsible for creating the enemies which will then move toward the hive and perform any of their other behaviours. It's very simple for the designer to specify what enemies he wants: just type them in as a string, separated by semicolon. So to create a string of three ants, all at level 1, with a 2 second time between them, you'd simply specify:

"worker_ant,1,2;worker_ant,1,2;worker_ant,1,2"

I may add something in the future to allow a command to be repeated x number of times - this would make it easier to specifies large waves of the same enemy at the same level and interval. But for now, this system should work fine for our needs.

Bee Movement

Previously, the bee "towers" could be moved without restraint. This was definitely not what we wanted for the final game - the bees should only be allowed to be placed on flowers, and they should not attack while moving.

This week, I added this functionality in. Using the Orthello 2D framework, it was actually really easy to add callback functions that are triggered based on dragging events. I'm definitely happy I decided to try this 2D framework because it's been a huge help all along the way.

Now, when you move a bee, it immediately stops attacking and won't start again until it has been dropped. If it is dropped on a flower, it snaps to that flower's center location. If it is dropped outside a flower, it snaps back to it's previous location. We would like to add some fancy features in the future where the hex the bee is being dragged over lights up red or green depending on whether it's a valid location, but it works fine as it is now and is still fairly intuitive.

We do have a small bug in that a bee will sometimes get "stuck" after being dropped on a flower. I need to investigate this further, as it weirdly seems to have something to do with which bee it is specifically.

Demo

This week, I have a web based demo! It requires Unity web player, which is a free download.

Check it out here!

EDIT: Apparently the demo isn't currently working. Bother. I'll look into it in a bit.

Dissertation - A New Idea

Previously, I posted here that I was interested in continuing my AI project from last semester as my dissertation for my master's degree. I am still considering this, but today I read an article that really sparked my imagination and interest.

The article covers a talk given today at GDC 2013. You can read it here on Develop. The main point of the talk was that Warframe developer Digital Extremes used AI strategic mapping (Tac and Influence maps) to determine enemy spawn frequency and locations in procedurally generated levels. This seems like an area with lots of interesting possibilities, and would go very nicely with my procedurally generated level backgrounds in my Solar Sojourn project.

I'll be talking to some of my advisers tomorrow about this idea, as well as my previous idea for a fuzzy logic controller plugin generator. I'll definitely share more information as soon as I make a decision!

Solar Sojourn - The Design

Earlier this year, I mentioned that I would be creating a game centered around dynamically generated terrain for the coursework for one of my modules. I planned to build on my scene created for last semester's DirectX module, which consisted of a ship flying around the solar system. I planned to allow the user to land on specific planets and explore them.

I've decided to modify and simplify that idea a bit. Instead of freely flying around space, the user will simply select a planet from a menu (though I hope it will be a graphically beautiful menu, showing the planets rotating around the sun in space). The main gameplay will be on the planet. I've decided on a Star Fox style shoot-em-up, where a series of enemies attack the player. Like Star Fox, it will essentially be a rails shooter where the player only has freedom of movement in a limited plane that is constantly moving forward.

Each planet will be a different level. Levels will be fairly simple, with the ground and scenery dynamically generated while the enemies and collectibles will be planned out. Each planet will have different atmosphere and gravity settings, with unique hazards to each. For example, some planets will have high winds or a corrosive atmosphere, or a deadly sunrise.

I still have quite a lot of work to do for this project, and I'm still in the early planning stages now. I'll post updates here as I progress. Look forward to it!

Pimp my... Everything!

As you might notice, if you have visited the blog before, I've made a few changes. Today I spent most of the day updating my online presence. I've updated my Linkedin profile, changed my background and banner here on my blog, updated my Twitter background to match, and finally got around to making my portfolio website. Through all this, a lot of care was taken to keep a similar style and feel for all of my online locations. I see this as my personal brand, and I want it to be instantly recognizable by potential employers.

If my lovely readers have a chance to check out my portfolio website, I'd dearly love some input on it. I'm in the process of transitioning from a plain set of code on github to a real website, and want to make sure everything looks good. I'm also a little nervous about doing this, since I got some really good responses at the career fair about my github portfolio. But I think the main idea was, "Oh, you're on github? Good!" and I can still convey that by including my github user name on my cards, CVs, and portfolio.

You can find my new portfolio site here: http://jiyambi.webs.com

Thanks for reading!

Creating a PS2 Game - Designing the Game

Last week, I settled in on an idea for my PlayStation 2 module project. In case you missed the previous article, the project is to create some application for the PS2 which uses the controller for input and the vector processing unit to render graphics. The better it takes advantage of the PS2 hardware, the higher a mark I will receive.

Today, I did some more thinking on the idea and have decided to tweak it a bit. Originally I was planning to make a shooting game where the player controls a cannon shooting things flying through the air. I wanted to try a cel shaded style, though, so I thought I'd make it cute. Today I was sitting in class and realized that shooting fireworks instead of missiles would be a lot more playful and match the art style better, and could actually lead to some really interesting gameplay.

I then spent the next few hours figuring out how to make a game about putting on a fireworks show. I've decided to call the game "Boom!" for now.

The Premise

The player controls a cannon that shoots fireworks into the sky above a watching crowd. The player can choose the firework color by moving the right analogue stick. Each of the four main buttons fires a different type of firework.

The main goal of the game is to keep the crowd happy during the performance, while carefully managing the number of fireworks used - each firework costs money, and the player only has a limited budget to work from. This means using all the fireworks up front will leave the rest of the show empty, and the audience will leave in disgust. The gameplay comes from choosing what fireworks to fire, when, and where to fire them.

Here is a graphic showing all of the elements of gamepay. Ignore the terrible art and the clutter of the screen - I wanted to get as much on there as possible just to show how everything works.

Concept for Boom! gameplay

Pacing

Choosing the pace at which you shoot will be a very important part of gameplay. In the lower left corner of the screen, you'll notice there is a blue and yellow bar. This is represents the length of the show. In the blue sections, the audience is expecting a slower pace, and will be patient with longer times between fireworks. In the yellow sections, they expect a faster pace. If too long goes between  nearby fireworks, their happiness will drop - and it will drop much faster during the yellow sections.  The player will have to ration out their budget to keep the audience happy.

Location

Everyone wants to be able to see, so the player must make sure to spread fireworks over the whole field. Fireworks higher in the air have a larger range. Clouds appear and can block audience view, and must be dispelled by a firework. Leave a cloud too long, and it might start raining! Fireworks placed on top of each other give fewer points.

Combo

The player can string together certain types and colors of fireworks to create combos. For example, the player could use colors together to make the flag colors for the country the show is set in. Other combos might simulate shapes (flowers), explosions (three flash-bang style fireworks at once combo called "Bombs bursting in air"), etc.

Bonuses

The player will get a bonus if they fill audience requests. Occasionally an audience member will ask for a certain type and/or color of firework. Sometimes, several will get together and ask for a combo. Filling these requests generates bonus happiness and points. There will also occasionally be rainbow rings in the sky - aim your fireworks here for bonus points.

Progression

Difficulty can be changed, which changes the budget available and the patience of the audience. Different stages can be selected, which changes the city in the background, audience preferences and standards, available budget, and firework costs.

Audience Happiness

Each audience member has its happiness evaluated based on how recently a firework has gone off near them. Audience emotions range from the following values:

• Very Happy: High increase in points per second, bonus for fireworks seen.
• Happy: Small points per second, bonus for fireworks seen.
• Unimpressed: small negative points per second, normal score for fireworks seen
• Unhappy: medium negative points per second, no score for fireworks seen
• Angry: high negative points per second, no score for fireworks seen. After a short time as angry, audience members leave the field.

If all audience members leave, the level is automatically lost. There may be other loss conditions, as well, such as having a low enough score at different points or having a low enough total crowd happiness.

Fireworks Types

There are four types of fireworks that can be purchased. Using the same firework type over and over reduces it's effectiveness until it hasn't been used for a while (similar to the bonus system at the end of a song in Rock Band).

• Flash+Bang: Very cheap, but lacks color so can't fill most requests. It doesn't last long but has a high range due to it's bright and loud explosion.
• Shooting Star: A wide trail going up followed by a few colored sparks. Medium price, long life, short range, colored.
• Crackler: Loud, colored bloom, followed by crackling white sparks. Medium life, medium range. High price.
• Traditional: Huge, colored bloom. Longest life and range, very expensive.

Finale Mode

Filling requests also fills up a meter (which will be displayed on the cannon itself). Once the meter is full, the player can press a button to go into Finale Mode. In Finale Mode  for a short time the player can fire fireworks without worry about budget. There is still a fixed fire rate, but this allows the player to recover if the audience was getting upset. It's best saved for high audience expectation moments, but can be used to get the player out of a pinch at any point in the show.

Going From There

That's a LOT of features, and I almost certainly won't implement them all in my PS2 module game. However, I am thinking of taking this game to other platforms, possibly just building it in Unity. I like the idea a lot and I think it's fairly simple in execution. I'm looking forward to working on it!

Building Breakout In 3 Days - Day 3

It's the final day of my mad rush to build a clone of the classic game Breakout. If you missed the first two days, you can find them here and here.

Today my biggest goal was to get the level loader working. After that it was pretty much just polish - scores, lives, and increasing ball speed are all just extras

Finishing Up The Basics

I hadn't quite finished the basic gameplay yesterday, so that's the first thing I did today. First I took my existing block code and created screen change buttons from it, for the menu screen. I created placeholder screens for both the level and the high score screens.

Final version of the title screen, with button blocks.

Once these were working well, I got to down to business with the bricks themselves. I needed three types:

• A yellow block that disappears after being hit once.
• An orange block, that disappears after 2 hits and changes the colour of the ball when colliding
• A red block that disappears after 3 hits.

I created the textures in GIMP, with two "broken" textures, one building on the first. It came out a lot better than I had dared hope, and really got the point across that the brick was damaged. Implementing these took no time at all, and soon I had blocks that had one of three types. The color changing effect of the orange blocks was also easy to implement, causing the ball to cycle through one of five possible colors.

At that point, the basics were done. It was time to create the level loader.

The Level Loader

The first step to building a level loader was to decide what number of blocks would fit on the screen. I had the level automatically generate a bunch of blocks in a line going off into the distance, and counted. With my setup, it looked like about 17 blocks fit horizontally, and 23 fit vertically.

Next was to decide how to represent the level information. It seemed using simple numbers (1,2,3, and 0 for no block) separated by spaces might work best. While I was a little worried this would be an annoying and fiddly part of the development, it actually went quite quickly, and I was able to make some interesting designs.

Level 1. My attempt at recreating the Ninja Kiwi logo.

Level 2. Not so subtle plug.

After loading in the levels, the only thing still to do in terms of the level loader was making the levels transition after you beat them, and increasing the ball speed as they transition. I created a level transition dialogue to smooth this out, though I had some trouble getting it to not register mouse input to the ball while in the dialogue.

Adding Polish

Now that all the main bits were in, it was time to add polish items. The first thing on the list was a lives system. Using the number "font" I made for the level dialogue, it was pretty easy to set up a lives counter. Next was to add a game over dialogue - I basically used the same system I had set up for the level dialogue.

Next up was a scoring system. With the life system already in, it was easy to add in scoring using it as an example. More difficult was the high score system, as I wanted this to store high scores in a file. I didn't want to implement a full font system so I decided not to include name entry, just a recording of the numerical score. As with the level loader, loading scores from file ended up being very simple. The file saving only took a small amount more effort, and a high score system was born.

At this point, pretty much everything I wanted to implement was in the game. I finally got around to adding sound when the ball collided, and improved a few other small things. I also went through and cleaned up my code.

Overall, I'm extremely proud of the result. It's one of the most complete games I've ever made and I did it all by myself, using no engines, in just three days. I'm absolutely exhausted but very happy!

Building Breakout In 3 Days - Day 2

As I mentioned in my post yesterday, I've received an assignment: Build a clone of the classic game Breakout, using only C++ and either DirectX or OpenGL, no game engines or editors. I plan to do this in only 3 days.

Progress To Date

Yesterday, I combined my DirectX project from last semester with one of my C++ game demos, removing unrelated code specific to those projects and 3D code from the DirectX project. This took quite some time, and the DirectX 2D code still needed to be tested (to make sure I hadn't removed anything vital by accident).

The goal for today was to get the basic gameplay implemented, minus level loading and any frills. Those would be tackled tomorrow.

Creating the Title Screen

I decided to create the title screen first, along with a button that will progress to the next screen. This would allow me to make sure my framework was working properly before moving on to more complex features. In fact, I got the idea that making the title screen into an extremely simple level might be a good way to teach the player how the gameplay works.

First, I created a very simple title screen image, including the game title, my name, and instructions on how to play, as well as a mock up of where the button would go when complete.

Mock up of title screen.

The next test was to see if my new graphics API was working. Unfortunately  it wasn't - I had gotten rid of the camera class but actually needed it to set up my view matrix. This was easily enough fixed, and soon I had a scaling title screen placeholder.

Then, I needed to get the title screen worked into my screen framework. This meant determining how my game objects and logic would work with the graphics API. I decided to convert my graphics, input, and sound handlers into singletons so the various parts of my program could easily use them.

Once the basic background image was working with the screen framework, I added in the player paddle and clamped it to the confines of the play field. Then I added the ball, initially moving with the paddle until the player clicks the mouse button.

The next step is to implement collision detection with bricks and walls. Collision with the paddle would be handled slightly differently to get the Breakout feel (hitting the side of the paddle causes the ball to bounce in that direction, rather than being based on the incident angle). I had a bit of trouble with this at first, with bugs for corner cases (literally), but managed to get it all ironed out after a bit of thought.

I also added a respawn function to the ball, which re-attaches it to the paddle so it can be fired again. I added a trigger for this when the ball leaves the screen to the bottom. During an actual level, this will reduce the player's life by 1. But for the title screen, it simply respawns with no consequences.

Next Steps

By the end of the day, I had all the basic mechanics in the game - input, the ball, and collisions. Tomorrow I'll be adding the following:

• Hitting button blocks transitions between screens
• Sounds for ball collisions (based on the material being hit)
• Sound for ball being shot from paddle
• Outline for high scores screen
• First level with test blocks
• Blocks that break when hit
• Sound for block breaking
• Orange blocks take two hits
• Orange blocks change ball color to one of several random colors
• Red blocks take three hits
• Blocks show their damage via cracks
• Lives and a game-over state
• Score increased by breaking blocks
• Level loader and pre-created levels
• Three total levels
• After three levels are complete, game cycles, increasing ball speed each time.
• Score recorded in file for high scores (name entry?)

I may not get to all of this, but I hope to. The basics are already in, the only really challenging things to come are the level loader and high scores system, the latter of which is not even necessary as per the brief.