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!

Pollinator, Flower Defense - The Beginning

I've decided to join the Game Development Society at Abertay this semester. The idea of the society is to allow teams of members to produce a game over the course of the semester. This semester, the society is recommending it's members produce mobile games. I'm in a team of two, myself and my partner who is a designer and artist. We've decided to make a tower defense game based around my old game, Pollinator.

The player plays as a queen bee protecting her hive. As queen, the player can send bees to gather pollen from flowers, or send worker bees to guard duty. Enemy wasps fly in, attacking bees and eventually the hive. Pollen is used to purchase and upgrade bees, while nectar (gathered slowly along with pollen) can be used for upgrades between levels, such as new bee or flower types. After a flower has been worked for some time by a worker bee, it will produce a seed, which can be planted anywhere on the map to grow a new flower.

It's all very much in the planning stage at this point, but I'm excited and I think it will be a lot of fun to create.

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. 

Scottish Game Jame: Post-Project Reflection

The game jam is done at least. After a weekend of fun and learning and meeting new friends, I finally got a good night's sleep and am ready to look back on how things went.

Concept art of our game, but the finished product looks essentially like this.

Our game was a 2D running game in which the hero, Denizen Pop (the Ultimate Mare) must escape being turned into burger meat by a wall of... well, of burger meat. She runs across a surreal landscape, collecting carrots (speed boosts) and foals (bonus points) while avoiding barbecues, hedges, and onions.

The game was rather simple, and the gameplay pretty unoriginal. We didn't have a designer on the team and I think that made things much more difficult for us as a group. None of us were really "idea people" and even this simple idea took us longer to decide on than most of the teams. However, we were able to completely finish our game with time to spare and limited stress, so perhaps this simple idea was best.

For programming, we used Unity. I had never used this engine (or indeed, any engine) before and it was a wonderful experience, especially because Dave was a Unity veteran and was able to teach me. Luckily I was fairly familiar with C#, so it was our scripting language of choice. I was very glad to have Dave's guidance in finagling Unity to 2D, as it wasn't particularly intuitive.

Overall, I learned an absolute ton, made some great new friends, and had a blast. This was an excellent experience, and I suggest anyone interested in making games definitely get involved with a game jam as soon as possible. With only 48 hours of your time (or less, depending on the jam length) you'll end up with a completed game, which generally looks better in a portfolio than an incomplete one no matter how fancy. You'll learn to work with others, often both others of your discipline as well as cross-discipline. You may even learn a new technology, as I did. You'll make new contacts in the industry. Most importantly, you'll have a great time and make memories that will last a lifetime.

If you want to play my game, you can download it here: http://globalgamejam.org/2013/denizen-pop-ultimate-mare

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.

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!