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!

Building Breakout In 3 Days - Day 3

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

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

Finishing Up The Basics

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

Final version of the title screen, with button blocks.

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

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

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

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

The Level Loader

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

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

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

Level 2. Not so subtle plug.

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

Adding Polish

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

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

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

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

Building Breakout In 3 Days - Day 2

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

Progress To Date

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

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

Creating the Title Screen

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

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

Mock up of title screen.

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

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

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

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

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

Next Steps

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

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

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

Building Breakout In 3 Days - Day 1

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

Example of the classic Breakout game

The Brief

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

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

My Approach

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

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

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

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

...and more, if I have time.

Getting Started

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

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

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

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

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