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.

Building Breakout In 3 Days - Day 1

I've got a programming assignment to program a Breakout clone, and I've decided if I'm going to do this, I might as well record my process and post it here on my blog.

Example of the classic Breakout game

The Brief

My assignment is as follows: create a clone of the classic game Breakout. I'll be coding "from scratch" (no engine) in DirectX. I'll have three types of blocks, with different "health" totals each.

Everything else has been left to me. I don't want to embellish and add too much, as I think it's important to show I am working from the brief. However, I hope to add a few little flairs within the brief specifications to show my creativity.

My Approach

The first step was to choose a graphics API. I already worked with DirectX extensively for a module last semester, so I decided to use that framework for this project.

For the game framework, I have a C++ Allegro project used for a demo last semester. This project includes handling of separate scenes (screens), buttons, and mouse/keyboard input using Allegro. I'll combine this with my 2D DirectX code to build a good platform to start from.

From there, I will begin the next steps to getting the game up and running.

• A paddle that can be moved by mouse input.
• A base level with walls on the top and sides.
• A ball that bounces around the level and off the ball in the traditional Breakout fashion
• Lose condition when the ball leaves the bottom of the level
• A block which collides with the ball and performs an effect after being hit
• A yellow block which disappears on hit
• A orange block which changes the ball color and disappears after two hits
• A red block which disappears after three hits.
• Win condition when all blocks are gone from level
• Level loader which reads a level from a .txt file.
• Textures for each block, different ones after it has been hit (cracked)
• Start screen with play button, stating controls.
• Add sound for collisions, possibly background music.
• Implement a lives system
• Implement a scoring system
• Implement multiple levels
• Ball goes faster over time, or at later levels

...and more, if I have time.

Getting Started

The first goal was to combine my two separate projects to create a 2D game using only DirectX. I started with the DirectX project, since it already had visual studio set up to handle DirectX libraries. I then removed all the unnecessary classes and shaders from the earlier project, keeping only the texture shader since that's all I'd need for a 2D project.

From there, I began adding in the framework from my Allegro project, modified to take advantage of the DirectX api. Primarily, the framework will be used to manage "screens" - transitioning between the title screen and the main level. It also has a set of callback frunctions for taking input, loading, and unloading screens.

All I managed to get to today was to add the screen structure in, but I didn't have time to fully integrate it with the program. That will come tomorrow, when I hope to get the basics of the game coded in, minus possibly loading from level, which I will focus on during day 3.

All in all, I think I made a good start on the project, and look forward to some speed programming tomorrow!

Pollinator, Flower Defense - It's Almost a Game!

My team has been working hard on our game "Pollinator, Flower Defense" for the Abertay Game Development Society, and it's paying off. It almost feels like a real game, now.

Concept art of the play field

 Here's a list of the features added this week:

• Multiple ants
• Multiple bees
• Health bars for ants, bees, and the hive.
• Bee attacks injure ants
• Ants die when their HP reaches 0
• Ants that reach the hive die, but damage the hive.
• Bees are draggable, and can be moved around the field of play

This is all well and good, but there are still a lot of things that need work. For example, bee movement has no constraints right now, and they still attack while being dragged.

The worker ant, easiest of enemies

In the next week, I'm hoping to get the following set up:

• Some kind of level loader which spawns ants at set intervals
• Different kinds of ants (damage, speed, and health can already be customized)
• Constraints on bee movement as designed by game designer
• Integrating new art assets

After that, we still have some other basic features to implement:

• Pollen and Seed generation
• Planting flowers
• Creating new bees
• Animations

The basic starting bee unit

Finally, I'm hoping we'll be able to reach some of our stretch goals:

• Nectar occasionally generated from flowers
• Nectar used for tech upgrades
• Multiple levels
• Multiple enemy types (beyond just base stat changes - for example, grasshoppers that jump over flowers)
• Multiple bee types (again, beyond just base stat changes)

I think it's going very well, and we'll definitely have at least some kind of base game completed by the end of the semester.

The soldier ant, slightly stronger and able to damage bees that come near

From now on, I plan to have a working prototype posted online at all times, updated each week for our weekly GDS demo. I'll post here each week after our GDS meetings and give my readers an update on our progress and overview of the new demo's features.

Here's this week's demo: http://dl.dropbox.com/u/11838203/Pollinator/Demo02.zip

This week it's a download, but I'll use Unity web player in the future.

Enjoy!

Monster Merchant - Laying Groundwork

The last week has been a struggle. A struggle NOT to work on Monster Merchant. With the project finally gaining momentum, it's all I want to do, and sadly many other projects currently take precedence. That said, I've found time to devote to the magical world of monsters, and I'll relate the results here.

Game Overview

The game can be described in one sentence: In Monster Merchant, you catch, breed, raise, and train the monsters which populate the traditional dungeons of fantasy role-playing games. 

Gameplay consists of three main things: Filling orders and managing relationship with dungeon overlords; breeding new monsters by mutatation and egg fuzing; and going out into the wild, battling wild monsters and catching them and raiding their nests for eggs. There will also be a crafting system using monster parts, harvested from wild monsters killed in battle.

Game Design Document

After a lot of deliberation, I've finally completed enough of the design document that I'm willing to move into code work. It's far from finished, but the core mechanics are clearly set out, even including some vital algorithms for how monster breeding works. A few example traits and abilities have been laid out, monster characteristics decided on, and combat system has been described. Many more traits and abilities will be needed for the final version, the combat system needs to be more clearly fleshed out and heavily tuned, and the story is skeletal at best. But the core way that monsters and monster breeding works is done, and that's the first thing I want to get into the game.

Coding Has Begun!

With the design document in hand, I opened up Unity and created a new project. A monster can now be created and specified easily within the editor. I deliberated for a while on how to create Traits - in editor, in XML, or as sub classes of a parent Trait class. I finally decided on the latter. I think it will make future expansion much easier. All I need to do is create the new trait class and attach it to a trait library, and it becomes immediately available to the game. This should allow easy additions later in the project, or with DLC.

I also am going through Unity's GUI tutorial, mocking up a GUI for monster stat display.

Getting Started with Art Assets

Roy has started working on a simple monster to use as a placeholder in the GUI screen, and has begun thinking about how to do the modular monster models. It's really exciting. I drew up some (absolutely terrible) concepts of how the monsters vary based on their traits. Here's an example showing different body types for a dragon monster:

Team Building

In addition to the coding, design, and art work, I've also done some work bringing the team for the project together. Communicating our progress, setting up a private Bitbucket page, and creating the lovely banner you see at the top of the page are some of these activities. At the moment, the core team consists of myself doing programming, design, and management; Roy doing design, writing, and art; and Angelina on sound. I also have a large number of volunteers interested in playtesting, writing, and fiddling with numbers. Unfortunately, the game requires a significant amount of 3D art assets, and complex animations for the modular monsters, and Roy may not be able to do all this himself, so we may need to seek another 3D artist and/or technical animator.

Overall, the project is finally moving forward and I'm extremely excited for the future!

Game In Scotland 2013

Friday I attended this year's Game in Scotland career fair. It was a great experience, pulling together students, industry veterans, and company representatives from all through Scotland. Wandering through the stalls and talking to employers was actually really fun. I got to learn about many companies I previously knew only by name, and see first hand what kind of openings were out there for when I graduate.

The biggest thing I had impressed on me from this career fair is that good programmers are sorely needed in the industry. Previously, I was terrified that I wouldn't be able to get a job after graduation and would have to go back to America. Now, after having promising chats with multiple companies and interview requests from two (Tag and Climax games), I'm feeling much more confident that I'll be able to find not only a job, but a job I truly enjoy when I'm done with university.

Creating a PS2 Game - The Beginning

Similar to last semester, this semester I'll be blogging about the development process for my coursework at Abertay. One of my modules this term is Console Development, in which we learn about developing for specific hardware and input devices. For the coursework, we'll be creating a game for the Playstation 2.

The requirements of the coursework are fairly simple: Create a 3D application which accepts user input via the control pad and processes graphics using Vector Unit 1 in the Playstation hardware. The application doesn't even need to be a game, but I think I would like to make it one if I can. Higher marks will be given based on how well the application takes advantage of the Playstation hardware.

My current idea to fulfill this coursework is a game in which the player controls a cannon shooting down things in the sky. This covers user input, as the player will be aiming the cannon using the analogue sticks and firing using one of the buttons. Vibration will be used to give user feedback when the cannon fires and any mid-air explosions, making them feel powerful. The project will involve loading and rendering 3D models, determining collisions (though this can be VERY rough and simulate everything as spheres), and possibly allow the player to move to avoid projectiles.

For graphics, I'm very interested in the cel-shaded style, and may attempt to create the game using it. I plan  on using a cel-shaded style for another of my upcoming games, and this would be a good excuse to learn about it and show my abilities to make something different than the other students. If I choose this, the theme would have to match it - something silly and fun, perhaps shooting "party bombs" with confetti particle effects, or flowers, or something.

This is just the beginnings of the idea, and I don't want to settle on anything too soon. Next week, if I still like the sound of it, I'll start planning the tasks I'll need to complete the game.

Dissertation - Formulating Ideas

At the end of this semester I will be submitting a proposal for my MSc dissertation. The dissertation will be a semester long project during which I will have no other coursework, and will be working full time researching a game programming topic. I will be expected to present new and useful findings that better the game industry knowledge as a whole, with the understanding that this is not a PhD and I only have one semester in which to complete the research.

Today, I've at last settled on a possible research topic. As regular readers will remember, last semester I created a fuzzy logic controller and genetic algorithm optimization using HTML5 JavaScript. My lecturer Dr. David King seemed interested in developing the project further, but I wasn't sure how to go about doing that. After our meeting today, however, I think I have found a way that combines many of my programming interests into one project.

Fuzzy controller input membership functions for last semester's project

I'll frame the topic first as a product: An online tool that game developers can use to create fuzzy control systems for their games and automatically generate a plugin that is ready to use. Optionally, it can also generate a genetic algorithm optimization method for them - however, since this requires knowledge of the game implementation, this would be more difficult to implement - but also more interesting and potentially rewarding.

However, this is not just a semester long project - it is a research dissertation. I have to be able to phrase my topic in terms of an investigation, or research question. I'm still figuring out how to do that, but one possibility is: "Can a modular FIS tool be created to suit an arbitrary game's development needs, and if so, how useful is it to the development process?" Measurables include: How effective the FIS generated by the project are (do they work); how easy the interface is to use (survey); and how easy the generated plugins/modules are to use in the final game (survey). Things that would be needed to show this include: the tool itself (HTML/JavaScript); and one or more game applications that use the generated plugins, if possible some games that weren't created by me. I may be able to get Dr. King to make the tool available to next year's AI module for MSc students to get some feedback and help them understand FIS controllers, and may also release the tool to the Abertay Game Development Society in return for feedback and use of their game in my dissertation demonstration.

My next task is to research and see if this has been done in any form previously. I'll also need to do general background research into fuzzy controllers  genetic algorithms, writing plugins and tool programming, and user interface design. Once the base research has been done, I'll write my proposal and get started.

While I'm a little concerned that this project may not qualify as research, and more just making something, I'm hoping it can be massaged into meeting the assignment requirements. It is a great combination of my interests, in AI, tool programming, and user interface/interaction. I may be creating something that is immediately useful to fellow students and developers. I'm quite excited and looking forward to developing the idea further.

Pollinator, Flower Defense - Detailed Enemy Design

We've been working like busy bees on the Pollinator project for the Abertay Game Development Society. While we still don't have a fully playable prototype, we've made a lot of progress on enemy, bee, and flower designs. In addition, our wonderful artist Piia has produced some gorgeous concept art, as well as as some initial enemy art.

In case you missed the game description, Pollinator, Flower Defense is a tower defense game in which you play as bees defending their hives. Previously we had planned for the main enemies to be wasps, but we've since changed that to ants. This makes more sense for a lot of reasons - first, it differentiates the heroes and enemies more. Second, it makes more sense for ants to be blocked by flowers, since they are land creatures.

In the last week, our designer has been generating all sorts of interesting enemy designs.

• Worker Ant - Straight-To-Target: Plows on towards the hive, mostly for scouting rather than actual offense.

• Soldier Ant - Creature Attacker: Attacks friendly creatures that move against the creep wave.

• Winged Ants - Flyers: Weak flyers that bypass flowers.

• Stag Beetles - Tank: Slow to move but packs a punch and can take a beating. Hive destroyers.

• Rhino Beetles - Flying Tank: Very slow to move but packs a punch and can take a beating. Can fly over flowers. Extremely dangerous. Hive destroyers.

• Millipedes - Iron Defenders: Protects other creeps with long carapace body. Creatures attacking creeps under the millipede or the millipede itself will do less damage.

• Hairy Caterpillar - Spiky Defenders: Protects other creeps with long spiked body. Creatures attacking creeps under the caterpillar or the caterpillar itself will be damaged.

• Cricket - Speed Boost: Increases the speed of nearby creeps with its violin music.

• Kamikaze Ants/Pea Aphids - Suicide:  Rushes through defenses and explodes at targets.

• Grasshopper - HexSkipper: Hops quickly between hexes instead of regular creep movement. Skips one hex then pauses before the next leap. Can leap over flowers except Wallflowers.

• Water-Skimmer - Non-Slowed: The pads on the feet of these insects prevent them from being slowed by honey or sap.

• Dung Beetle - High Defense Wave Leader/Protector: Moves at the head of the line of creeps, taking attacks with its large ball of waste. Melee attackers will be slowed when striking the dung ball. Speeds up when ball is destroyed, though has low health.

He's also been working on bee, flower, and tech designs - but those will be the subject of a later post.

I'm quite excited at how well development is going. I'll be posting a video of a playable prototype as soon as we have one ready, hopefully in the next week.