Dissertation Complete - So Long, Uni!

At long last, after NINE YEARS of university (over half for a degree I'm not using), I am finally done! Friday, I submitted my dissertation. Assuming marking goes well, I am now a "Master" of Computer Game Technology. Now to move on to bigger and better things!

I may have been a little excited when it came back from the printer....

What does that mean for me, and for the blog? Well, firstly, I'll now be working full time at Ninja Kiwi Europe, maker of the mobile versions of the extremely popular Bloons games. I've been part time there since September, and it's an awesome place. I'm happy to be able to work there full time now.

However, that doesn't mean I'm abandoning my personal projects. In fact, I'm starting off my new professional life with a bang at the Global Game Jam, with an awesome team of Abertay students and recent grads. Most of us worked together at the TIGA Game Hack, and we're excited to work together again. It should be a ton of fun, and I'll definitely be updating here and on my Twitter (@Jiyambi) as we go.

After the game jam, I'll be focusing on making games with my partner Roy Stevens. Our first project is a mobile game called Bubble Market, made as part of the Abertay Game Development Society. Bubble Market will be programmed in February, with an alpha ready by the end of March and beta at the end of April. I'll be calling for testers during those times, so keep an eye out. Expect to see it on Google Play and possibly other Android app stores in May!

Also in February we will be pitching six game ideas internally. The chosen idea will be moved into pre-production, and work will begin on it as Bubble Market is completed. For this game, we are hoping to find an artist or two to help us out, but Roy is also taking some time to focus on his artwork so either way, we should have a nice set of skills for development.

As for the blog, I will continue using this as a space for development updates and reflections. I also plan to write a few how-to posts. The first of these will be posted shortly, and will cover using Github for Windows (the desktop program) with Bitbucket (the git repository). This has been requested by some of the Abertay Game Development Society folks and I think it could be a big help to student game development teams.

When I look back at when I started this blog, compared to where I am today, I see an amazing journey. It's invigorating to see the progress I've made, and so much more exciting to think about where I'll go from here. Look forward to it!

Creating a PS2 Game: Post-Project Reflection

It's been a while since I've talked about my PS2 project for my consoles class at Abertay. Now that the project is finished, I'd like to look back and see what I've accomplished, what I could have done better, and where I'd like to go from here.

Title Screen for Pyroteknix

The Premise

As I mentioned in my design blog post for this game, I wanted to create a game all about putting on a fireworks show. I decided in the end to name the game Pyroteknix. In this game, the player controls a cannon which can shoot fireworks into the night sky. More specifically, they control a crosshair which the cannon rotates to point to, and which fireworks will target and explode on.

Gameplay for Pyroteknix

An audience watches the show below. Each audience member has a mood (indicated by their facial expression), which contributes to the points gained by each firework. A firework gains points for each audience member which sees it (based on the firework's x position on the screen and it's range), modified by the audience member's mood. The audience members' moods drop naturally over time, but are increased by seeing a firework. Therefore it's important to spread the fireworks out across the sky to keep all audience members in high spirits. If any audience members get upset, they will leave. If all audience members leave, the player loses.

In addition, each firework has a cost associated with it. The player is given a set budget at the beginning of the show, so they must space out the fireworks over time. The show has a set time limit, counting down and displayed to the player throughout the show. The player must balance keeping the audience happy, gaining points, and not letting their budget run out.

Technical Details

Working with the PS2 was an interesting experience. We could not use an IDE, so it was back to Notepad++ and a linux-based g++ compiler. In a way, this was refreshing - I really like Notepad++. But, I'd found I'd grown very fond of tab-complete for my class methods and data members, and missed that quite a lot. Additionally, working with the makefile setup we were given was frustrating, but I lacked the makefile know-how to fix the situation. Essentially, the makefile wouldn't detect .h file changes, and wouldn't recompile based on them, but wouldn't throw errors for things referencing stuff changed in the .h file, and so I got horrible crashes for no apparent reason. This also resulted in a need to reboot the PS2, which took around five minutes each time. Compiling was also quite slow, which was frustrating.

Another huge technical frustration came from working with the vector unit code. This was all assembly level stuff, which for those not code-inclined means very low-level stuff where you are literally moving memory around inside the processor to do calculations. It is NOT my kind of programming, and it was like pulling teeth. I thought what I wanted to do (a cel shading style) would be easy, but despite working on it for a full day I never figured it out, and ended up giving up on the vector unit code altogether. I still managed a very good mark on the project due to my other clever use of the system and a very nice framework.

Now on to technical successes. I was able to re-use the framework I've been using in my DirectX project, since I completely encapsulated all the graphics stuff. This was really useful and let me get a lot done very quickly, and looked quite professional to boot. It included support for screens, game objects, and particle systems. Since particle systems were very important for this game, I spent a lot of time making sure they looked nice and billboarded correctly. I wasn't 100% happy with the results but I think they were well enough for the time period allotted for this project.

I was also able to manage the display of graphics in such a way that optimized the texture buffer use so it was changed as little as possible, while still encapsulating all the graphics code. In addition, I had to edit a lot of the provided framework's graphics synthesizer instructions to allow for transparency and 2-D image rendering.

Finally, I was able to get in some decent effects to really pull off the cannon firing. I added sound effects for the cannon fire itself as well as a whistling as the firework went up. I also added both a screen flash (simply rendering a white texture over the scene for one frame) and a rumble feedback when the cannon fires. This made the game feel much more visceral and was great feedback for the player.

Future Plans

While I feel like what I managed to do with the restrictions imposed by the time frame and platform was pretty good, I would have liked to do a lot more with the project. Different kinds of fireworks, combos, audience requests, higher audience expectations later in the show (finale), and some kind of overdrive mode where you can shoot fireworks off for free - these would all be awesome features to add. I think this game concept is actually pretty strong and hasn't really been done much that I've seen, and I'd like to bring the concept to a mobile platform. I think it would suit touch controls very well, and it's shiny, fun style would do well with a mobile audience.

I'm not sure when I'll have time to work on this, but it's definitely going in my bank of "things I'd like to make". I'd call the project as it is a successful proof of concept and a great learning experience.

PUNCH: Post-Project Reflection

PUNCH (Punching Ungentlemanly No-gooders and Cleaning House) was a game created as a group project for my university this year. The game is a four player smash-'em-up using Xbox controllers where players must break the furniture in the house to gather coins. The first to five coins wins. Players can also temporarily stun each other, making player interactions more interesting.

You can see a video demonstrating gameplay below. Unfortunately, only one player was available to make the video so it doesn't quite capture the manic, fast-paced feel of the game. Additionally, the rest of the art assets and the power-up mechanic didn't make it into the build used for the video. It's possible we'll get an updated video later on, and if so, I'll post it here.

PUNCH prototype gameplay.

The engine used to create the game was Havok. I have to say, it was the absolute worst experience with an engine I've had to date. Nothing was intuitive, the documentation was hard to navigate and often altogether wrong, and the game ran significantly different outside the editor as opposed to inside. It was a mess, and our team could have accomplished so very much more if we hadn't been constantly fighting with the engine. Given the choice, I will never work with Havok again, especially when there are amazing free alternatives that flat out work better, such as Unity.

This was the largest team I've ever worked with on a game. At first things were a bit rocky, as we forged ahead without nearly enough planning and communication. Coding standards, a planned program structure, and a better estimation of everyone's strengths from the beginning would have been very useful. We also had a rather imbalanced team, with seven programmers and only one artist, designer, and producer each. Better use of online communication and version control, and sitting closer together in the lab in general would have helped a lot as well. But this is the environment to make mistakes in, so I'm happy we made them and learned from them. By the end of the project we were operating much better together as a team.

Overall, while I found this project extremely frustrating, I feel we learned a lot and produced a fun, if simple, game in the end.

Solar Sojourn - Framework Work

I've been focusing heavily on my Solar Sojourn project over the last few days. This project is a continuation of my DirectX scene from last semester, and will be used for my coursework for my procedural terrain generation module this semester.

While I had a working graphics framework at the end of last semester, it was becoming very unwieldy and I wasn't happy with it. The main work I've done this semester has been to reorganize the framework into a more useful method. This was helped significantly with the work I did for my Building Breakout project last month. Based on experimentation, examples from the Rastertek tutorials, and my knowledge of object oriented development, I've finally settled on a class set up that I'm happy with.

Obviously the end product will have more shaders and possibly more graphic sub classes, but this should give the framework's general idea.

I've been working hard over the past week to get the basics of this framework implemented in the project code. Unfortunately, it's been a lot more work than I expected, and I've been very busy with Dare and other projects. Right now, I have a project that builds, exits, and displays a black window of whatever size has been set, but it doesn't yet render objects. I'll be posting an update as soon as I have more.

Of course, in the module labs I have been practicing other code that will eventually be incorporated in the project. This includes procedural terrain mesh generation based on noise, perlin noise, midpoint displacement, smoothing, and other techniques. We've also practiced post-processing techniques such as blur and glow, which will be essential in making the bright light from the sun believable.

I'm really excited to get working on the meat of this project, since I am hoping to build my dissertation on it.

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!

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!

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.

Busy Busy Busy

Post frequency has fallen off here quite a lot lately, and I thought I should let y'all know why. I've got LOTS of projects going on, so I'll share what I've been up to.

Procedural Terrain Generation

One of my modules this semester involves procedural terrain generation. I'll be using my space project from last semester and building on it for this coursework. I've been working hard on restructuring my DirectX project from last semester into a class structure that is more pleasing to me. In the process, my knowledge of DirectX is deepening considerably. Where before I understood the existing code well enough to use it, now that I'm restructuring the rastertek framework I am really sinking my teeth into how everything is done.

Unfortunately, it's much slower going than I had expected. I had hoped to have the code restructure done this weekend, but I'm still around halfway through it. If possible, I'd like to finish it by next weekend.

Current Status: Restructuring old code.

This Week's Goal: Complete code restructure, so I can start adding new features.

PlayStation 2 Programming

My other taught module this semester is console programming. Our coursework, and most of the module, is about programming for the PS2. At this point it mostly involves doing tutorials in class, so this is actually my least stressful project currently.

Current Status: Just finished the first 3d graphics tutorials.

This Week's Goal: Keep up to date with weekly tutorials, get ahead if possible.

Havok Team Project

My third module this semester involves two main focuses, the first being a team project in Havok. This is a team of around 10 people, working on a game using the Havok engine, which will be completed at the end of this semester (May). We don't have an external client, so we've been able to pitch our own game ideas, based on the prompt of "physics-based destruction". I think it will be a lot of fun!

Aside from taking up time with meetings, there hasn't been a lot of work for this project yet. I do need to spend some time brushing up on working with the Havok engine - while we became familiar with it last semester, it's easy to forget over the holidays.

Current Status: Formative idea stage - pitching ideas tomorrow.

This Week's Goal: Get up to date with Havok technology.

Master's Dissertation

In addition to the Havok project, my third module also involves individual work on my Master's Dissertation. This semester, I need to choose a research topic, do a literature review around it, and write a proposal for the rest of my dissertation work to be continued over the summer and next fall. This is a huge undertaking, and I'm no good at coming up with ideas. I've been working with one of my lecturers to help develop a project idea, and so far I'm interested in something in the realm of AI. I will either be continuing my Fuzzy Controller / Genetic Algorithm work from last semester or starting on something new.

Current Status: Formative idea stage.

This Week's Goal: Brainstorm several ideas and discuss them with Dr. King.

Pollinator - Flower Defense

Not only do I have all those uni projects, but I also am part of the Game Development Society at Abertay and am working on a mobile game called Pollinator - Flower Defense. It's a tower defense game where you play as a bees defending their hive. I've got a team including a designer and artist, and I'm quite excited to see what we can produce. Unfortunately, I'd hoped I would get some work done on prototypes over the weekend, but that turned out not to be possible due to unexpected emergencies coming up. It's my hope to finish at least one prototype by this Thursday, our meeting.

Current Status: Several design possibilities fleshed out.

This Week's Goal: Produce at least one prototype to present at GDS meeting.

Dare Project

I'm also planning on applying to Dare this year. I've got a full team now, and we're working on solidifying a game concept. At the moment we have general gameplay ideas but need to determine the exact setting and flesh out controls and gameplay. Overall it's going well and I'm excited to work with this great group of folks.

At the moment I am making sure the networking plugin I found for Unity mobile will suit our needs, and getting up to speed on how to use it. Additionally, we are brainstorming ideas and settings, and will be deciding on something at our next meeting this coming Friday.

Current Status: Solidifying ideas, platform and engine research.

This Week's Goal: Complete Unity networking tutorial, brainstorm ideas to bring to the meeting.

Career Stuff

If all that wasn't enough, I've also been rushing around trying to get my CV, portfolio, and business cards up to date to show off at Blitz Open Day, which I'll be attending in two weeks. This involves a lot of iteration based on online reading, trips to Career Services in Abertay to get advice, reading a book on getting into the gaming industry, asking lecturers for feedback, and looking in to printing services. It's taking quite a bit more time than I expected, but I'm hoping the work will pay off. I'm excited to be attending the event, and I think if anything it will be good practice on networking and interacting with industry developers.

Current Status: Electronic copies of CV, Business Card, Portfolio.

This Week's Goal: After getting a last round of feedback, get CV and Business Cards printed.

Whew!

And that's about it! A ton of stuff, as you can see, but I still want to keep blogging once a day. I just have to accept smaller, progress-style posts instead of huge guides or opinion pieces. This post has already gone on a lot longer than I expected, but I'm hoping going over my different projects and goals will help me focus.

Dare to be Digital - Team Forming

Short post today, as I'm feeling fried. Just wanted to share the news that I'll be applying (with a team, of course) to Dare to be Digital for this summer. For those not in the know, Dare is a huge competition in which teams create a game over the summer. Accommodation  a stipend, and a modest development budget is provided for each team - provided you get in. Applications consist of a 5 minute pitch video followed up by an interview.

So far we have 4 of the 5 team members chosen, and I think we've got an amazing mix of talent. I'm really looking forward to seeing what our group can produce, though I'm also very nervous! I'll definitely be posting updates here as we progress.

It's crazy how busy the next year is going to be, but oh so exciting at the same time!

Procedural Terrain Rendering: Project Planning

It's that time again - starting a new semester, everything is fresh and new, and new coursework is on the horizon. One of my projects this semester will involve procedural terrain rendering. Since I already have a project from last semester that's all about exploring the solar system, this semester I decided I'd build on that and allow the user to land on planets. This will allow me to dynamically generate the terrain for each planet, using a set of parameters specific to each planet. I'm hoping this will allow me to show off the ability to write good polymorphic code, making this an excellent portfolio piece.

Screenshot from RasterTek tutorial for height maps

My scene last semester still needed some fixing up. In particular, for me to be happy using it I would need to fix the following features:

• Complete Program Restructure: I'm dissatisfied with the RasterTek framework for such a large project, and want to set it up in a way more intuitive to me. This will also show that I can do more than copy/paste from a tutorial site.
• Particle System Fix: My particle system is currently slightly broken - the particles do not billboard correctly and some work needs to be done on ordering them properly when one is spawned. Additionally, they need to fade out gracefully rather than suddenly winking out of existence.
• Mouse-Assisted Camera Control: As it is, the camera is a pain to deal with. Adding mouse options to the controls would really help.
• Select-able Planets: In order to land on a planet, the user will have to be able to select the planet. Luckily RasterTek has a tutorial for this. I could even have a probe or laser sensor shoot out to the target on click.

Additionally, if I have time I'd really like to add some or all of the following:

• Additional Moons/Dwarf Planets: After the program restructure it shouldn't be too hard to add the rest of the moons and dwarf planets to the solar system.
• Lighting effects (bloom, glare, lens flare): The sun doesn't seem bright enough in the current scene without some effects. More special effects will make the scene much nicer.
• Re-sizing and re-positioning of planets for realistic representation: I'm not sure on this one, as I want it to still be possible to easily explore the system. Perhaps if the planetary orbitals were also added, and if there was some indication of where nearby planets were - maybe a minimap?
• Asteroid Field: I didn't have time to implement the asteroid field last time. This could actually tie in to the procedural generation, as I could generate asteroid shapes on the fly.
• Planetary Rings (Saturn, etc.): A simple disk with a partially transparent texture could represent planetary rings.
• Coordinate Readout: This could help the user find their way around.
• Representation of Planetary Orbit (line): Another aid in helping the user find their way around and see the different planetary orbits.
• Planetary information display: It would follow the theme to have planetary information displayed to the user on their screen. A fancy target-lock would be really awesome, with text on the screen with information about the planet. I know a professional voice actor who might be willing to voice this as well.

State of the scene at the end of last semester

I am hoping to get these objectives done in the first half of the semester, leaving the second half to do the module work. That's all well and good, but I need plans for the actual terrain generation. This plan will have to grow and change over time, since I'll be learning more about my capabilities as I go through the module. For now, I've got some ideas for basic features:

• Mountainous Terrain based on Parameters: For each planet, some sort of mountainous terrain will be generated based on the provided parameters
• Planet color/texture: Each planet/moon will have it's own color or texture
• Navigation on Planet Surface: The user will have to navigate on the planet surface somehow. Most likely this will start as first person perspective.
• Gravity: Gravity WILL be in effect on the planet, and the user will be in a ground vehicle, so it will limit their travel. Gravity will be different for each planet!

In addition to these base goals, I would like to add some more interesting things:

• Gaseous Planets: It would be cool to be able to fly down through gaseous planets. However, this might be too difficult.
• Asteroids: It would be excellent if dynamic asteroid generation was possible. Since asteroids are very small compared to planets, perhaps the user can select the asteroid belt as a whole and fly around through it, only then seeing the asteroids up close enough to see the dynamic geometry generation. When in the main space view, they can just be spheres or a few "lumpy" asteroid models.
• Water: Landing on Earth, it would be quite likely to land near water. Water effects would make this much more realistic.
• Plant-life: Likewise, some plant life would make an Earth landing much more realistic.
• Volcanoes: These are quite common on some planets, so these would be great geometry to look at, as well as some special effects involving lava.
• Precipitation: In addition to rain on Earth, some planets have their own precipitation of various types (acid rain on Venus for example).
• Ice: Some planets have ice of various types (Mars for example).
• Sun/Moons: Seeing the sun or moon (or planets) from the planet surface would be interesting too, especially if time passed normally while there and the time the user landed actually dictated the time of day on planet.
• Rover device: Rather than a purely first person perspective, it might be cool to see a little animated rover running around on the planet surface.
• Gameplay objectives: Adding in samples to be taken or some other kind of objective would make the game more interesting.

I'm sure many more ideas will come to me as I go through the module. 

Creating an AI Controller: Post-Project Reflection

Yesterday I reflected on my DirectX project. Today, I'm taking a look back at my completed AI controller. While I was happy with my DirectX results, I felt I could have done better. Well, I suppose I'll always feel that way with any project, but with the AI controller I apparently blew the project expectations out of the water. My lecturer told me he wished he could give me a higher grade than A+, so I'm guessing I did pretty dang good on this one!

Just a part of the crazy customization section for the controller.

Features

I was worried about the tuning part of this project (though the amount of tuning I ended up doing was laughably small). I also wanted to implement tuning via genetic algorithm, so I had to make my controller robust enough to handle any type of membership function shape, location, and rules. I also wanted to be able to tune it and see the results instantly. Finally, I was doing this work away from university so I had no access to the fuzzy toolset of MATLAB to visually see what my membership functions were doing. Consequently... I basically built the MATLAB fuzzy toolset in HTML5 and JavaScript.

Think this was crazy? Well, it kind of was. But the result is really great to see. The user can slide a slider or enter numbers and immediately see the effect on the membership function curve. They can even edit the controller while it is controlling the car - and see the result immediately! And, when I actually tuned the controller using genetic algorithms, it was great to see the results graphed for me.

Once a controller is customized it can be exported, and other controllers can be imported. The proof of concept game allows controllers to be tested, either via an automated track or by user-controlled changes in the track. The game runs for one minute, after which results are printed to the screen and can be exported for use in a spreadsheet program such as Excel.

Proof of concept game application, showing AI readouts.

The last part of the assignment was to look at a second AI method, and if possible implement it. I was interested in genetic algorithms, and I like the idea of combining AI methods. I dislike the fiddling that tuning a fuzzy controller requires (I generally hate anything of that nature) so, naturally, I decided to try to get the computer to do it for me. It turns out this is apparently a pretty new and interesting use of genetic algorithms, which impressed the lecturer quite a bit. I was able to successfully use genetic algorithms to tune the controller, and while the result wasn't ideal, I have lots of ideas on how to improve it in the future.

Moving Forward

My lecturer seemed very interested in this project, so it is my hope I might have some future opportunities to improve and continue my work on it. There are two main areas I'd like to improve. First, I was hindered by JavaScript's inability to handle complex numbers, and the lack of math libraries available to handle math such as finding the root of cubic equations. Were I to continue this project, I may move to a more robust language.

Probably on a more interesting note, there are several things I would change with the genetic algorithm code. First of all, I would limit the genetic algorithms to only edit half of the membership functions, leaving the other half symmetrical. This constraint makes sense because an ideal controller will always be symmetrical, and will allow more optimization time to go towards other facets of the controller. I would allow more variation in other areas, including variation in rules as well as membership set location. Finally, I would incorporate the elitist technique in the selection criteria, which keeps the highest performing controller(s) from one generation and copies them directly into the next, ensuring that the performance never goes down, but can only grow.

AI is a subject I'm very interested in, and is one of the fields I am considering making a career of.  This project gave me a chance to stretch my wings and really get my hands dirty with AI in code as opposed to concept, and I feel the result was a smashing success!

Creating a DirectX Scene: Post-Project Reflection

Well, all the hectic craziness is over and the coursework is turned in. I'll be using the next few posts to reflect on where I am now and how far I've come. Today, I'll take a look at my completed DirectX scene and discuss what could have been better and what still needs work.

A screen capture of the scene. You can see the sun, Haley's Comet, Jupiter, Earth, and Mars in this image.

Features

Overall, I feel like the scene was a pretty big success. I got the basics of what I wanted very solidly, and even added some advanced features. My planets moved and rotated in a realistic fashion, with textures set up properly. I even had moons rotating Earth and Mars, though didn't have time to set up more. 2D rendering allowed a nice HUD overlay with mouse pointer crosshairs. Camera movement was via keyboard, and while I would have liked to add movement via mouse, the keyboard movement worked pretty well.

For advanced features outside of what was taught in class, I added in-scene point lighting for the sun. I also changed how the sun itself was rendered in order to make it bright, setting it's ambient lighting to 1. A skybox with a starfield texture was used as the backdrop for the scene, rendered similarly to the sun with an ambient lighting setting of 1. Direct Sound was used to add music and a sound effect when the camera is moved, simulating a spaceship sound.

Particle System

The most interesting advanced feature I attempted was a particle effect comet trail. While I am pleased with the result, there are many improvements which could have been made. The particle system functions by dropping a particle close within the vicinity of the comet. Each particle is given a velocity in each direction, but this velocity is smaller in magnitude than the comet's velocity. The effect this produces is the expected shape of the comet tail. In the tutorial I used, the particle system relied on the camera never moving. This meant that if the camera moved, strange artifacts would be seen in the system due to the alpha blending method - the particles had to be ordered based on depth in order to avoid this. This meant I had to implement a sorting function for these particles, something I hadn't really done before. It was one of my proudest moments so far in programming when I successfully implemented an insertion sort algorithm from scratch and saw it working here.

Unfortunately, despite this success, the particle system in the final product is still not perfect. The sorting is not set up when a particle is killed, and this causes a brief flicker of artifacts across the system. Additionally, I didn't realize that in addition to not sorting particles properly, the example also set up the particles as billboards only facing (and only rendered) in one direction. This means that from the sides the system seems distorted, and from the back it does not appear at all due to culling. Finally, the particles blinking instantly out of existence looks a bit odd. Instead, they should have an decreased alpha over time, fading out gently. All of these issues would be easy enough to fix, given time, and I may do just that simply to improve this project as an entry in my portfolio.

Program Structure

I am rather disappointed with my program structure for this project. Code organization is something I am intrigued by and generally pride myself on. Unfortunately, I was hindered in this project because I was learning as I went, and using primarily code from rastertek.com's excellent tutorial series. This code, while quite effective and great for single feature tutorials, is less than ideal for a larger project using many features at once. It takes zero advantage of C++'s inheritance features, and I found encapsulation difficult as well. In my coursework report for this project, I took the time to fully plan out a better program organization, and I may implement this organization in the future.

Moving Forward

This project isn't dead. I hope to continue improving it in the future in order to use it as a prime example of my work in my career portfolio. There are many interesting features I'd like to add, including:

• Program restructure
• Particle system fixes
• All other moons and dwarf planets
• Better representation of the sun's light, i.e. bloom, lens flare, glow
• Re-sizing, re-positioning of planets for better realistic representation
• Asteroid Field
• Planetary rings
• Mouse-assisted camera control
• Pause button
• Readout of current coordinates relative to the center of the sun
• Representation of planetary orbit (line)
• Select-able planets with readout giving information (possibly including voice-over)
• Clicking shoots a probe (possibly giving more readings)

The idea is an interactive, exploratory simulation of the solar system. Something like this could be used for education purposes. Ultimately, though, the goal is simply to create something nice for my portfolio. And I think, even in it's current state, that goal was accomplished!

If you would like to try out the scene, it is available online on my portfolio github. Enjoy!

Creating a DirectX Scene: Spaceship Ho!

I don't have much to report or much time to report it - I'm still working frantically on my DirectX scene. Today I finished the font engine, timers, FPS display, and camera control. Well, the last isn't perfect, but it's sufficient for now.

However, the coolest thing that's been added is possibly the most superficial, but I'm so freaking excited about it I had to share. I've never had anyone good at making pretty things work with me on a project, so when my boyfriend offered to help me with some of the assets, I quickly agreed. He created a simple HUD overlay for my space scene, as well as a crosshair (which I programmed in as the mouse cursor). Check out the result here!

Oh yeah, I also made a whole bunch of Earths. Don't question it!

Next on the list is to get this actually looking like a solar system. Additionally, I'll need to figure out point light to make a convincing sun. I'm also supposed to load in a model from Maya, which I'll need to find.

Then it's time to add some more advanced features. I really would like to add a sky box. Particle effects are also high on the list. I may add "sound" effects - though there is no sound in space, so I might just add sound when the spaceship moves, or perhaps different music when in proximity to different planets. An animated model of some kind would also count as an advanced feature.

Still lots to do! I'll update tomorrow with how things are going.

Creating a DirectX Scene - 2D Rendering

I'm quite busy with my coursework this week, but I didn't want to let the blog languish completely. I've finished my AI project, including the genetic algorithms section, which was a success (mostly). I'll write more on that later, as well as make my project code and report available to anyone interested - AFTER everything is handed in.

For now I'm hard at work on my DirectX coursework. Yesterday I got 2D rendering working (for UI and such). I plan to use it to create a simple targeting reticule and possibly a HUD of some kind.  For now I'm using the same texture that's on the spheres in the background, just for testing purposes:

Awww, it looks like that sphere has a band-aid (or "plaster", for my British audience)

Next on the list is font, input, and FPS display/timers. After that I'll work on getting the actual scene started - yeah this is still all ground work, and I only have a couple days left! I'm feeling pretty good about my other classes, though, and what I have now is enough to pass, so I'm trying not to stress out about it.

Wish me luck!

Creating an AI Controller: Surface Results

One issue I've been struggling with while working with my AI controller is determining a method for evaluating controller performance. Today I've finally implemented a results section for my application, allowing me to view many statistics after running a timed trial of the controller.

Nothing fancy, the results section gives the lowdown on how the controller performed during a trial.

During run time, the result reporter simply records the position and velocity of both the line and the car. Later, the results are processed to determine many statistics including:

• the total deviation from the line over the course of the trial
• the mean deviation from the line
• the median deviation from the line
• the standard deviation of this data
• the percentage of time the system spends in each membership set for inputs and output of the controller

The first four things on that list will allow me to evaluate controller performance, while the last will help me determine whether the track was a good trial for the controller's abilities.

I would like to add the ability to export these results in an Excel-friendly way. I doubt this will be too difficult, but I'll leave it for another day.

I also played around with MATLAB today to obtain a surface diagram for the controller. This graph shows the response curve for the controller output given the two inputs. Ideally, such a graph should have a (relatively) smooth slope, and I'm happy to see that mine does.

The surface diagram from MATLAB is a 3D representation of the action that will be taken given a pair of inputs (position and velocity)

Tomorrow I'll be looking into genetic algorithm tuning for the controller. I expect it to be quite a big undertaking, but I'm also very excited!

Creating an AI Controller - A Distinct Lack of Imagination

Let me let you in on a secret. Imaginary numbers are a pain to work with in many computing languages, unless the language was specifically designed to deal with them. Just my luck, I chose a language which couldn't care less about complex math. And, again on par with my normal luck, it turns out the solution to my "curviness" problem involves imaginary numbers.

Let's back up a moment. A few weeks back I posted about the AI controller I am designing for my AI course. This controller involves equations which I wanted to allow to be curvy. Unfortunately, this curviness means the equations are cubic. This is fine when going in the forward direction, since the numbers are (primarily) outside the range of 1 to -1. Unfortunately, when going from a set member to a recommended action, all inputs are less than 1. This means that the input squared is less than the input, resulting a negative number under the square root in the cubic solver equation - meaning all three results of the cubic are imaginary.

It might be possible to still use this method if I was using a language with better support for complex numbers. Unfortunately, JavaScript is about as far from that as possible. There are libraries for it, or I could write a complex class myself. However, with time as short as it is, I've decided to simply abandon the idea of curviness for the output membership functions. It still works great for the inputs, but the outputs will have to be boring ole trapezoids. I'm hoping my thorough investigation of the problem still wins big "oooo ahhh" points from my lecturer.

In other news, I've coded all the basic requirements for my coursework now, including an automated track for the "car" to go around. Tasks still on my to-do list:

• Tune the controller manually
• Tune the track to cover all test cases (all rules)
• Results display
• Results export
• Controller settings export and import
• Genetic algorithm tuning (and display progress and results of said tuning)

The track here is running on it's own. Yes, that red circle is a car - don't question it!
You can also see the readouts of all the fuzzy controller stats.

It does feel good to know that if I absolutely had to, I could hand in what I have now and still pass (provided I wrote a decent report to go with it). I'm allowing myself three more days to finish this, then I'm cutting myself off and focusing exclusively on my DirectX project (which is going to need a LOT of attention).

Creating an AI Controller - Bezier Curves and More

I've talked a bit here about my coursework for my DirectX module. I also have a project for my AI class, which I've been working on over the past few days.

The Assignment

The assignment is simple: Create a fuzzy logic controller for a racing game that will control the NPC cars. The suggested implementation is extremely simplistic - the road is represented by a line, the car by some simple symbol or sprite, and the line moving left or right represents curves.

Inputs and Outputs

The inputs to the controller are twofold. First, the position of the line relative to the car, negative being on the left, positive on the right, in pixels. Second, the relative velocity of the line with respect to the car, in pixels per second.

The output will be the suggested acceleration for the car in order to bring it closer to the line, in pixels per second per second.

Membership Functions

I've decided to use five membership functions for each input (far right, right, center, left, and far left). For output, I've decided on nine membership functions (extreme right, large right, right, slight right, center, and so on).

For the shapes and locations of these functions, I've created an HTML5 interface which allows several points for the shapes to be adjusted via sliders and text boxes. Internally, all shapes are represented as trapezoids with four points: the left base point, left peak point, right peak point, and right base point. Additionally, each trapezoid has two "curviness" settings, left and right. The idea is that with these six settings, we can create any and all of the common membership function shapes (triangle, trapezoid, curve) and any combination of them, and they are all represented identically within the code. This will allow me to tweak the membership functions easily to tune the controller.

A screenshot of the control panel for modifying the membership functions

This took a bit of doing, but I'm happy to say I've completed it and the interface is really nice.  The most difficult part was the representation of the "curviness" for the sides of the trapezoid. I wanted to keep this simple from a user standpoint, but I wasn't sure what equation to use for the curves and how to constrain the system. After some discussion with an old colleague from my chemical engineering days, Robert Coolman, I determined that a cubic spline function would be appropriate. The native capabilities of the HTML5 canvas led me to investigate the bezier curve. It turned out this was just what I needed - the bezier curve is a spline using one or two control points. Using the demo located on sitepoint.com's excelent tutorial, I was able to visualize exactly what I would use to represent the "curviness". The two control points are located on the same y coordinate as the endpoints. The x coordinate for the control points can range anywhere in between the two x coordinates, but to keep symmetry must be an equal distance from their respective end point. This distance, then, represented the "curviness". I specify some value from 0 to 10, which is then scaled to the space between the two x coordinates.

The next problem, once this was determined, was actually applying the Bezier curve's equation to find a corresponding y coordinate. This is done internally by the HTML5 canvas to draw the curve, but to use the controller I would need to be able to find it on my own. Unfortunately this would require finding the solution to a cubic equation. After some perusal of various articles including Wikipedia's Bezier Curve and Cubic Equation articles, I was able to write a function to find the real cubic root of an equation given the coefficients, and was able to determine those coefficients from the Bezier curve equation and a bit of algebra.

Rules

Given these inputs and outputs, I created a fuzzy associative map in order to ensure each situation was covered under a rule. I also plan to represent the ruleset internally in a similar fashion, to make it possible to procedurally step through the rules, and to even make it possible to tune the rules as needed.

Fuzzy Associative map covering all possible set combinations

Defuzzification

For defuzzification, I plan to keep things simple and use the Center of Maximums method. This should provide fairly accurate results as long as membership functions are mostly symmetrical - for non-symmetrical membership functions, error will be introduced due to the method not accounting for portions of the function below the maximum plateau being uneven. If I have sufficient time I may look into the center of gravity method, but for now it is beyond the scope of my plans.

The Game

The game itself will be coded using the HTML5 Canvas and JavaScript. A line will represent the centre of the road, and a sprite will represent the car. The camera will be centred on the car, but both the car and line can move freely about the game world.

There will be both a defined track (movement of the line defined using pattern movement techniques) and a user controlled track (movement of the line controlled  by the user as described in the assignment sheet).

Second AI Controller: Genetic Algorithms

The assignment also requires a second AI method to be used in addition to Fuzzy Logic. I am interested in genetic algorithms, so I plan to use a genetic algorithm to tune the fuzzy logic controller. I will then compare this result to my manually tuned controller.

Wish List

In addition to the basic features outlined above, I have several advanced features I'd like to add:

• After a track is run, the program should automatically display a summary of the performance of the AI for that course, and several useful graphs and statistics including standard deviation.
• The ability to save membership function settings to file both before and after a track is run would be useful.
• Similarly, the ability to load these membership functions from file would also be useful.
• For the genetic algorithm tuning, it would be great to watch the membership function values change in real time.
• A real-time animation of fuzzy logic operations while AI is running the track could provide insight into AI actions and assist in debugging.

Completion of some of these features could take the project beyond a simple exercise and make it a useful teaching tool for demonstrating fuzzy logic in the future.

Creating a DirectX Scene - This is not the bug you're looking for

I've been working on my DirectX scene over the past few days, primarily cleaning up my code and making it more object oriented. I created an array of models and render them via a loop now. Unfortunately this revealed what I thought at first was a bug in my code. Let me demonstrate:

At first glance, it appears that the light on each of these models is coming from a slightly different location. However, the same lighting direction is passed to all models. I thought perhaps the way I was transforming the world matrix was somehow affecting my lighting direction as well - I tried different things, pored through the code, and generally fumed ineffectually at the problem for several hours before finally writing to my instructor. Thankfully, he was able to quickly resolve my problem, if in a rather unexpected way.

It turns out the bug was not in the code but in my brain's perception of the scene. Because we have so little information to work with in this scene, and we're trying to interpret a 2D image as a 3D image, our brains actually come to the wrong conclusion. If there were more varied objects in the scene providing perspective, or if we were able to move around the scene, we'd reallize the truth - we aren't seeing all of the spheres from the same angle. The light IS hitting them all from the exact same direction, but our camera is not SEEING them all from the same direction.

The give-away is the texture. If you look closely you'll see the light is hitting the textures all in the exact same way on each sphere. The textures appear rotated differently on each sphere from our perspective, too, but they are all facing the same way, it's simply that we are seeing each from a slightly different angle. In fact, the only part of the light that is actually changing due to where we are in respect to the sphere is the specular highlight, because it's position depends on the camera location in addition to the lighting direction.

My mind was a bit boggled when I understood what my instructor was saying, and I admit I raged a bit at having wasted several hours on what was in fact not a bug. But it is pretty interesting to see first hand how our minds, when presented with a limited amount of information, can easily interpret things into a completely incorrect conclusion.

Creating a DirectX Scene - The Beginning

Remember back when I said I was working on a scene in DirectX? Yeah, that didn't stop being a thing. I've been spending most of my time with it so far simply getting used to the system, but I'm finally ready to start getting my hands dirty with the code.

This week, I've added a second model into the scene and learned to move, rotate, and scale the models. This will be essential if I want to have a believable space scene later on. I also unintentionally caused one sphere to orbit another due to a mis-ordering of transformations on my second model. I haven't decided if I want to try to use this method for orbiting planets in my scene or if I will use a less "cheaty" way of doing orbits.

My next goal is to clean up my code and remove hard-coded elements. I will create a uniform method for rendering a model, create an to hold my models rather than having a variable for each one, and work on how to render them using this array or a more object-oriented solution. After that, I'll be working on camera movement via keyboard input. And from there I should be in a good situation to start adding the more complex elements of the scene.

I'll be documenting my problems and discoveries along the way here on the blog, as I'll need all of that for the report due along with the program for my module.

Creating a DirectX Scene - Planning

My coursework for my DirectX module this term calls for me to create a small scene rendered using DirectX. I struggled for quite a while with ideas for what sort of scene to create, until today settling on the idea of a space scene. In today's blog, I'll cover my plans for this scene and what features will need to be added. I'll give updates in the future as I work on the scene.

The Basics

For the basics, I plan to have a small solar system with planets rotating a sun at different speeds. The sun will serve as a light source. The viewer will be able to move around the scene and view it from different angles and locations. 

In class, we've already accomplished several of the basics:

• Spherical model loaded in
• Texture loaded for model
• Directional, ambient, and specular lighting coded
• Input processing added

In addition to these, I will need to add several features to create my minimal scene:

• Multiple objects with models and textures loaded in at once
• Movement of objects
• Input processing to catch movement keys
• Movement of camera (player)
• Light comes from a point within the scene (direction vector depending on location relative to sun light source) rather than an external point (single direction vector the same for all objects)

With these features, I will have what I consider a minimal functioning scene. Once this is finished, I can build on it to make a more complex and interesting piece of coursework.

The Fancy Stuff

From the basics described above, I will continually add features to create a more interesting scene. These might include some of the following:

• Sky-box - a background of stars and interesting space scenery
• Asteroid field - more interesting models than just spheres
• Space station - similarly, more complex model, perhaps with animation (rotating wheel)
• Comet with ice trail particle effects
• Space cloud particle effects
• Fire effects around sun
• Spaceship UI overlay
• Lens flare - possibly an actual realistic reason for lens flare, seen through a spaceship wind-shield while looking at the sun!
• Bloom - similarly, from looking at the sun

Blogging About It

I'll be keeping a development journal here on the blog for both this and my other coursework. This will help me stay on track with my coursework, assist in me in my final post-mortems of my work process, and I hope be an interesting insight into my work process.