Well, it’s been six long months since my last post, and boy have I been busy. Shortly after Game Jam I was approached by Gauge Entertainment as they were looking for someone to do some 2D art for their current UDK project: Backfire (which I will go into detail about further into this post). Some time later, the project has boomed and we have a full working alpha version of the base combat and a playable level. 

All the while, I slaved away doing something I’ve never done before: texturing a 3D object: the Minigun! I have to say, that’s no easy feat, especially when you don’t have direct access to the modeler nor any idea of how to structure your work flow. I jumped from many different angles, starting with Photoshop provided filters then, later on, over to using Filter Forge to take advantage of the flexibility it can provide. The problem there, that persisted for the several months I worked on the Minigun model, was that I had to actually learn the tools for Filter Forge which ended up slowing me down tenfold.

That said, by our pre-alpha deadline of August, I was able to get a basic diffuse of what I wanted to do with the minigun texture out the group. And while a good chunk of the end result won’t end up in future builds, it still feels good to have done that aspect of it all. To top it off, the team as a whole still feels I’m on the right track and could seriously improove if I keep it up. As such, I’ll continue on the texturing work and will start branching out into more aspects of Kismet as we don’t have anyone doing a whole lot with it currently.

All in all, my time with Gauge has been a fantastic one. While we are far from being in an ideal position as a game development group, we work well together and our commitment to the project will, hopefully, get Backfire out the door.

Screenshots of everything are on their way. Once we get our proper website up for Backfire I should be able to give a few sneak peeks.

Over the weekend I participated in Edmonton’s first foray into the Global Game Jam which is a gathering of game developers, artists and sound and music engineers in an attempt to create a game from conception to completion in the span of roughly 48 hours. Needless to say, it’s a hell of a weekend from start to finish as you desperately try to get that last piece of art or that important line of code into the final project. I want to go through the process of the project myself and my group, some of the people from Gauge Entertainment, went through.

Sparing the trivial details of actually getting to the event and first impressions, I went with the guys at Gauge with their game idea. They wanted to make a game that I can best describe as the flash game Toss the Turtle but with a high-tech sniper round, a 3rd person camera, and a final target, which seemed simple enough to at least get something going come Sunday. Now, of course, that ‘something’ would likely turn into just a proof of concept as we opted for a 3D engine for the 3rd person camera as we just did not have enough time to do much more.

Now in out rush to get things started and going we didn’t quite do something that we all realized in hindsight: we never prototyped and as such we dove right into making assets. While that worked out to some degree with our project leader and his modeled bullet with appropriate particle effects, it didn’t quite work out for myself and my quick and dirty materials. Had we aimed at creating the prototype from the beginning I feel we could have coordinated better and ended up with something a bit more representative of the target idea. That said, our final proof wasn’t all bad.

In the end our programmers were able to allow the camera to follow the projectile as it should and give control to the player after firing it. This at least gave a rough outline of how we wanted the game to control and how to build levels according to the variables put in place. Now I can only hope that we continue the project, there’s much we can do to make this a true game.

To see the event as a whole, check out User Created Content’s write up on it.

A quick project of mine: I took some very basic geometry from Blender, baked some lightmaps in pureLIGHT then brought all of that over to the UDK to see how it would all work out. The level concept consisted of a very simple maze-like level that woul be able to fit two players just nice, while demonstrating that you don’t just have Lightmass at your disposal if you want pre-calculated lighting.

The maps turned out just nice and showcased what pureLIGHT was capable of, while also demonstrating just how easy it is to implement a sort of middleware like this.

Anyway, on to the level!

All the meshes of the level where very basic exports from Blender, which was one of the harder things to get going as I eventually needed to just ask the pureLIGHT guys for a proper export script as none I found did the trick. Once that was said and done, the momentum with the project grew tenfold. With everything in pureLIGHT, it was as simple as telling it to bake, as the materials from my lights had saved and pureLIGHT imports the x,y and z from all meshes so fiddling with positioning shouldn’t be required.

Once processed, pureLIGHT dumps all of the final mesh and map data into ASE and TGA files that can be easily brought into just about anything, be it a game engine like UDK or 3D software like 3ds Max. The best part is pureLIGHT does all the custom UV work, meaning once it’s imported you just drag and drop the texture/material onto the outputted mesh and you map is applied perfectly onto it.

From here on out, it was as simple as placing and scaling all of the meshes and a few dynamic lights to get the end result. I do have to give thanks to Andrew Czarnietzki, he explained to me how to disable much of the UDK’s Simple collision that was wreaking havoc on my meshes. I found out soon after, however, that there must have been something that Unreal didn’t like about my meshes, as every time a bot or I moved while on per-poly collision, we both rose and fell. In the end I was able to add a BlockingVolume to even things out, but in the future collision meshes may be the way to go, even with this very simple geometry. I’ve noted that the next time through it would likely be better to export per mesh instead of per group of mesh, just to avoid some of this strangeness.

What I did right:

- Went to the resources available to me. The script I got directly from the guys at pureLIGHT Technologies worked exactly as I wanted it too.

- Had a clear plan from the beginning and executed it.

- Doing the project at all. Had I decided to bring this into something else mid project, it likely would have stalled everything.

What I did wrong:

- Very rough meshes, making for some light bleed and extra unnecessary polys. 

- Lightmap resolution not fully optimized.

- No collision meshes.

What I will do in the future:

Outside of adding the collision and making things a bit more optimized, I plan to move on from Blender and work toward adding proper materials and details into similar levels.

My recent workings with PureLight. Makes some really really nice baked lighting.

While elements of textures haven’t been a totally new to me; I’ve put some heavy hours into Photoshop over the years. That said, there’s always been concepts that I could not figure out with other engines. A while back I tried my hand at Unity and while importing base textures to it was a breeze, figuring out how to apply basic bump mapping seemed very out there for one who had just picked up the software and was just now trying to figure out C#. Moving from that to the UDK, especially with Materials taking president over base textures, was worlds better.Materials helped me figure out what I was doing, what I can do and, best of all, how easy it is to get proper texture, detail and specular within the game engine.

This screenshot is of a material I’ve been working on for that second UDK level I showed some screenshots of. The focus was to take a previously created texture (in this case, it was the base of the M_PoolDirt_02_Opt material) and revamp it to match a very wet and well trodden piece of mud. Through both my own tinkering and some help from the gracious 3DBuzz, I was able to reach the target as well as grasp how to implement future materials, all within an afternoon. Compare that to what I ended up doing with Unity: Googling, finding someone who coded a solution and then having to backtrack through someones very very ugly script.

I will keep playing around with the editor, and hopefully I’ll have some more to show of it in the near future.

Flash has always been a strong suite for me. Even when I first started getting into the program 5 years ago, Flash was as pick-up-and-go as it could get for me. As such, it’s no surprise that my first real planned project using Actionscript 3 would turn out a success. 

Fly Smasher is one of the projects that came from my experience over at Guru Digital Arts’ Interaction Design and Game Level Development. The assignment was to develop a simple story driven game that is played through only one player input and that can be developed as quickly as humanly possible. Right out of the gate I had a project document detailing out the simplicities of the game as well as a paper prototype.

Let it be known, if you can create a paper prototype of your game prior to actual development, do it! It’s the most effective way to get your idea across visually to both other people in your team as well as possible targets of your demographic. Had it not been for the paper prototype, many of the final ideas that went into Fly Smasher wouldn’t have come to the light of day. On top of that, a prototype should only take a few minutes to and hour at the most.

Development was interesting to say the least. At the time, Actionscript 3 was still rather new to me, with only a small chunk of Red Knight being the only previous experience with the script. As such I used what I knew to come up with an Alpha version quickly, but it was the polish that took it’s time. As I attempted to move on from that version I quickly hit brick walls; I had never really used aspects like XML and Flash, nor had I used AS3 to code priority in a mouse click over other MovieClip collisions. Suffice to say, I eventually got all of that sorted and quickly jumped onto getting as much testing as possible in.

As the walls fell, and the testers’ grins grew more and more, it became apparent I was on to something. When looking for proper art assets, Albert jumped onto that faster then you can say: “You have two weeks!” He had been rather excited about the project since I first brought it up, and was the first to jump in as a tester whenever he could.

In the end this was the big success of my Guru career. The scope stayed intact, it remained fun and simple, the story-while basic- is enough to get players interested and the art style Albert came up with was brilliant.

Summary

What I did right

• Paper Prototype, paper prototype, paper prototype
• Get some testing in whenever possible. This was a huge step into keeping the game interesting and consistent.
• Building the fundamentals before assets became a factor. This allowed for both the concept to be proven, as well as the assets to be designed around the game, not the other way around.
• Simple concept was the right scope for an junior developer like myself.

What I did wrong

• Not enough research into XML and Flash. Relying on PHP to transfer data between the two wasn’t a very elegant solution.
• Took too long trying to bash down the “brick walls” instead of changing focus and coming back to those barriers. 

As mentioned in my “The UDK: Great resources for the up-and-coming” post, this project took me a few weeks to get to a level that I had planned for. Now why might that be? Well, lets run through it, shall we?

From the beginning, I had actually planned for a simple concept level (yet expansive in scope, once I sat down and went through it all) that would push what I knew about the toolset, though keeping those lessons simple. Little did I know that a lot of those simple ideas were far far beyond what I would ever be able to figure out on my own. Yet, I plugged away at it endlessly until I hit points that I just could not figure out: “Why is the lighting shifting when I add this pointlight here, but not here?!”, “How come this wall is transparent from this side, but not the other?!”(Normals where a new thing to me), “Why is it giving me errors when I try to spawn a bot?!”, the list goes on.

It was around this point that I decided to scrap the whole initial plan entirely, I needed to do something I understood right out of the gate, while keeping the learning end of it as simple as possible. What turned out was the 0.1 version of the level you currently see in the YouTube video I’ve posted. To put it simply, just about everything that is in the current version was in the 0.1, with some simple changes such as no proper grass material, no “god rays”, ect.

Now, as I moved on with the level, trying to impliment some changes to make things much more believable became quite the problem. I hadn’t learned how to properly plan development, and as such the stability of my level fell through the floor; whenever I tried to add a new terrain material, change some figures in the lighting or an other major change, everything would crash. After a few days of trying and trying again only to have the same issue come up, it became clear I’d have to start over again. As such, I noted the locations and set-up of every mesh and terrain and started over from scratch.

It was around this time that I came across the 3DBuzz tutorials, these things would quickly teach me concepts that I never would have figured out on my own, as well as some strong development fundamentals, such as ordering what elements should be focused on first, which led to my final version.

To wrap it up, the learning experience with this project was very similar to the RedKnight: design within your own knowledge, know when something may be out of reach or beyond your skill level. And if you want to go that extra distance, take advantage of the resources before you dive head-first into the unknown. Should you feel you are unsure of your own skills, do as I just mentioned and take advantage of the resources you can and see how your knowledge compares to what they have to offer. Having this mindset from the get-go will save you a lot of wasted time and frustration.

Summary

What I did right

• Start development with what I knew, to keep the scope in focus.
• Taking advantage of the resources available to me. I can’t stress enough how much those tutorials helped me.
• Restarting from scratch. Though I ended up having to restart one too many times, I was still able to get something out of it in a reasonable amount of time.

What I did wrong

• Not tapping into the previously mentioned resources soon enough. Look up this info as soon as it comes into question, it’ll save tonnes of time.
• Not enough pre-planning. Much of the final level design I came up with as I went and found where my limitations are as a junior developer. This may have worked here, but it sure as hell will not for any future projects.
• Distractions. Since this was my first proper project I was jumping all over the place, deciding suddenly that I wanted this material here, that mesh there, and it made a jumble out of m development cycle, slowing it down considerably.

Well, they’re here! I have both a quick slightly-less-than-one-minute video of my first (and currently only) playable level designed in the UDK as well as a few screenshots of both this level as well as my other work-in-progress.

Pictures url: http://www.flickr.com/photos/48200295@N05/sets/72157625176406141/

Video: (Note: HD resolutions available on the YouTube page)

As I’ve had some issues trying to get Flyswatter hosted on a site proper, I’m uploading it to allow for those curious to play. Please note that this was my first true game developed by myself, with art by Albert Gunawan.

The download link is: http://rapidshare.com/files/427661789/Flyswatter_Final_1.0.zip

Albert’s company, Alien Element: http://www.thealienelement.com/

Over the past few weeks I’ve been rather quiet here in blogging land as my focus has been on my graduation and seeing what I can do about adding a UDK project into my portfolio. So far that work has been coming, albeit slowly. Just about anything that has come out of my playing with the kit has been due to my own experimentation and a few YouTube videos that fail to mention quick and necessary shortcuts.

That said, I think I’m finally on to something thanks to the guys over at 3D Buzz and their exceptional tutorials. And it goes without mention how flexible these tools are and how easy it is to actually work with them once the essentials are in your head.

Now, I’m sure you’re now wondering: “So…where are some examples you’ve thrown together in this time?”. We’ll I can say: they’re coming. I’ve set up a fully playable level in this time as well as begin setting up a quick set-piece. I’ll have pictures and some narrated video very soon.

3D Buzz Tutorials: http://www.3dbuzz.com/vbforum/sv_videonav.php?fid=292838127fecccd8b151c72003546386

UDK: http://www.udk.com/