Saturday, January 26, 2013

Scottish Game Jam 2013 - Day 2

I didn't feel like I had time to post yesterday in the frantic rush to start coding, but today things are a little calmer, so here I am. I'm participating in the Scottish Game Jam (and Global Game Jam) this year, at the Dundee location at Abertay University. Our theme this year is a heartbeat sound file, plus a bunch of optional constraints that can be used if desired.


The team! We were already a bit tired when this was taken, if you can't tell...

My team consists of two people who were complete strangers yesterday - Miranda (@Fluffgar on Twitter) and Dave (@BigHamm3r on Twitter). Miranda is an artist, a student here at Abertay, and Dave is another programmer. We decided to make a 2D game using Unity. I'm quite excited since I am terrible at using editors and haven't used Unity before, so this will be a great crash course.

Our game is coming along quite nicely. It's rather simple, but that's good for the size of our team, time available to us, and my inexperience. I don't have any of Miranda's awesome art to post yet, but I can show a screencap of the game in the Unity editor.

The platformer without any art assets. That red thing is a wall of death.

So far this experience has been amazing. I don't think we'll have any trouble finishing on time, and it will be great to have another piece of work for my portfolio. I'm almost getting to the point where I can actually CHOOSE what I show off to employers, rather than putting everything in there since I don't have much.

Monday, January 21, 2013

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!

Sunday, January 20, 2013

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!

Wednesday, January 16, 2013

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.

Tuesday, January 15, 2013

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!

Friday, January 11, 2013

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!

Wednesday, January 9, 2013

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).