• entries
22
26
• views
42996

I'm making a new game and videoing the whole process for the world to see. Scary stuff.

## Probably Archery: A Brief 7DFPS Post-Mortem

This year's 7DFPS game jam is the first game jam South East Games (my cousin Shane and I) has taken part in, but I'm pretty sure it won't be the last. In one of those all-too-common moments in developing our larger game where we stopped, turned and began throwing around concepts for something smaller to make, we threw out "what about something like QWOP and Surgeon Simulator except its multiplayer archery". We liked it, but normally that idea would be put into some dying part of our brains and we'd return to working, but (un?)fortunately, 7DFPS was a less than 2 weeks away and that gave as an excuse to do it.

7 Hours - Hemisphere

The weekend prior to the start of the 7DFPS, the organizers decided to put on a 7 hour version, the 7HFPS. This would be used to start getting things active early and help test their web site systems prior to the main event. At first I wasn't particularly interested in working on something for 7 hours, instead eagerly anticipating starting on our silly archery game. Then we thought of making a first person bullet hell game. It seemed simple enough for 7 hours and we created Hemisphere.

7 Days - Probably Archery

I was a little worried about how development of Probably Archery would go over the 7 days since I got pretty bored making Hemisphere and that was only 7 hours. That wasn't the biggest concern though, because Shane had full time work on all week and I had contract jobs to work on. The amount of hours we could spend per day during the 7 days would be fairly limited. There was around 3 days where I could work for decent stretches of uninterrupted time on the game, otherwise coding bits and pieces here and there. Shane had to make art assets after work, but got most of what we needed done during the starting weekend.

When thinking about how the game would play, we pictured awkward looking people struggling to get arrows nocked and fired in something resembling the right direction. As we built the game, it became harder to tell how it would feel to new users and felt less silly than we expected. Still, we wanted to keep the sense of humour so we had some very obviously inaccurate and silly aspects (players are balloon-headed sack people). Also by choosing to not research anything about archery at all and not worrying about accuracy, there are some aspects like the arrow being on the wrong side of the bow that probably annoy the hell out of people that know about archery, physics, etc.

I'd normally be very keen on the idea of live streaming development of the game, but the erratic development times weren't ideal for that. I did enjoy sitting in the 7DFPS chat and watching various live streams over the course of the week. Playing the in development builds of games and having people in the chat test Probably Archery's multiplayer early was awesome. The latter half of the week once I started doing this made the experience much greater as I felt more connected to other people and the jam as a whole instead of working on some silly game in solitude.

Ultimately I was fairly happy with how the game turned out. When I woke up this morning and decided to Google "Probably Archery" I was excited to see a couple of YouTube videos people had made while playing the game. Unfortunately one was prior to me updating the controls text to make it clearer that you could move the left arms shoulder and elbow joints as well, and the other was recorded before I fixed an issue where 3 people could be in a multiplayer match instead of 2 which would cause all sorts of issues. Still, just the fact that anyone played a game we made in 7 days and didn't hate it is exciting to me.

Some brief technical points on how various parts of the game are done:

• The arms are rigged and skinned and have a few animations for hand poses
• ?The clavicle/shoulder, elbow and wrist joints are moved in code with min/max angle restrictions
• Hand animations are set to only affect finger joints and can be played without affecting the rest of the arms
• 2 pass arm shader draws translucent (arms fade when close to the camera to not obsure aiming vision) and opaque parts of the arms separately. This allows for proper depth sorting.
• 2 cameras are used, one to render player arms/bow/arrow and one to render everything else. This allows for higher quality shadows from the directional light on the arms as the camera farClip-nearClip distance is short, while also allowing other environment shadows to look good with effective distance for cascades.
• Bow string and hanging target rope is a quick script I wrote that generates a cylinder mesh of customisable quality and allows you to set Transforms as segment points. The bow string has a center Transform that gets attached to the hand when the arrow is nocked and drawn. The hanging targets have Transforms attached together with spring joints.
• Bow drawing sound is a looping clip that I mute/unmute based on whether the draw strength was changed in the last frame.
• Arrows have an Audio Source playing a whistling wind loop. This gives a really nice 3D effect as arrows fly past your head.
• Multiplayer uses Unity's built-in networking because of time constraints. We setup a master server and NAT facilitator on an Amazon EC2 server. When the player hits the multiplayer button, it will look for a hosted game with only 1 player (the host) in it and join. If it fails to join (the host has their Firewall blocking connections for example), it will look for another host, only trying that same one again after 30 seconds. If it doesn't find a host it will host a server. This is fairly simple for me to setup and for the player to use, but it has some issues. If the player is full screen and hosts, they won't notice a Windows Firewall popup asking them to allow access for the program.
• Besides connection/disconnection code, all networking calls the same RPC method sending though a byte array with the first byte being a packet type. I assign callbacks/delegates to the NetworkManager to be called when certain packet types are received.
• Arm collision is handled through capsule/capsule intersection tests (closest distance between 2 line segments vs the sum radius of both arm parts being tested). After moving a joint, collision is tested on that part of the arm and all parts down the hierarchy against the parts of the other arm. If they now intersect, the movement is ignore and reverted. When drawing an arrow and moving the left arm, collision is ignored to allow the right arm to intersect anything for gameplay purposes. After this, the right arm could be intersecting the left so intersection is allowed following drawing an arrow until there is no intersection. This allows the player to move the arms out of each other without issue, but not back in.
• We added Google Analytics events to the game so we can see stats of how many people play each version, play the single player, multiplayer, etc.
• I didn't mean to put 'COLOR' instead of 'COLOUR' in the colour picker text in the menu, but American spelling of color in the Unity code was messing with my head .

Again, we're happy with how it turned out. It was hard to judge how it would play to a new user since after a short time with the mechanics, it became very easy for me to hit what I wanted. I think the game is a perfect fit for higher end motion control like the Razer Hydra, albeit with a separate control scheme where you only moved the hands (position and orientation) and the parent joints moved with IK. Having the WASD keys free also leaves the option for movement to be added if we wanted to develop it further and have larger scale multiplayer.

Thanks to the 7DFPS organizers for putting on a great event. There are a lot of really cool games that were made during the week. I think I've played just about all of them at this point. We'll definitely get involved again next year and will hopefully have 7 days full time we can dedicate to making something cool.

Probably Archery 7DFPS Game Page
Probably Archery Web Player page

## Volumetric Objects in Unity

For something a little different than just posting hours of video of me making an unnamed game, I thought it would be good to write something and talk about something different here for a change .

First, I recently left my lead programming job to start doing indie development full time. The job was slowing and a combination of events created what felt like the perfect moment to pull the trigger on this. I'll post more about my experiences trying to generate in income to live on from the comfort of my home as I have more to write about, for the moment I thankfully have some great contract work that still keeps things in the black week to week at the moment.

For this entry however, I want to talk a little bit about volumetric objects, specifically the volumetric objects I've created and added to my Advanced Surface Shaders package for the Unity engine.

# Volumetric Objects

[media]

[/media]

The volumetric effects I've created so far are 3 basic shapes: box, sphere and cone. Rather than create and modify actual geometry for these shapes, I simply render a basic mesh just to have something render and I extend it's size/bounding volume on the CPU when the object's attributes change to encapsulate the size of the object. At this time I also pass information about the shape to the shader.

The shader is where the actual visual shape of the object is determined. Raycasting is used per pixel to determine the near and far intersection points (if any) of the volume and from that information the opacity of the object can be determined. The further the ray travels through the volume, the higher the opacity. I provide a visibility property for the shaders to determine how far you can see through an object before it becomes opaque. The effect also support the camera being inside the volume.

[size=2]Click for higher resolution image

One of the key features of the volumes though is the support for texture sampling. Currently I support only world space sampling which is useful for the typical use cases of dust and fog within the volumes, especially when they are moving or there are multiple volumes near each other or intersecting. This way the textures shown within them will remain "in place" in the world as the volumes move and the textures can appropriately "move" from volume to volume like pieces of dust moving from within range of one spotlight to another. In future updates I will support local space texture sampling with control over the direction of the sampling for effects like light enclosures casting shadows down the length of a spotlight cone shaft.

To achieve the texture effects within the volumes I ray march along the intersecting section of the ray and sample the texture at that sampled position.

[size=2]Image from the Volume ray casting page on Wikipedia

I really love what can be done with these sorts of effects and just throwing an arbitrary texture onto a volume and seeing the results gives new ideas about possible uses that would provide effects I've never seen before.

Over the coming weeks I'll add all the additional functionality I can think to add to the shaders for the package and provide variations on the shaders that are optimised by not doing what that isn't needed. For example if there is no texture used then there is no ray marching required and a far simpler path can be used in the shader to find the opacity per pixel. Or for cone volumes if there is no top cap required then calculations within the cone intersection test can be ignored.

I'll post more about work I do in Unity and for the Unity Asset Store here when there's something I think is cool enough to share. I'm working on a new system at the moment that could be released in the next couple of weeks that I'll be sure to detail here .

If you want to grab the Advanced Surface Shaders package for these volumetric effects and a host of other shaders (e.g. Triplanar texturing, cone stepped relief mapping, parallax occlusion mapping, skin shading, etc) then you can check it out on the Asset Store from here or go to the Unity forum thread for more videos and info.

## Every Semicolon: Parts 13 to 18

[color=#111111][font=Helvetica, Arial, sans-serif]

### [background=rgb(254, 254, 254)]It's been a while since I've done a post here in the journal. I didn't want to do a post per episode, but since there's been 6 episodes since my last post I thought I should do the update. I think that's all I'll write because well... there's 9 hours of video below. Yeah... Lots of good progress and cool stuff worked on so if you're one of the crazy (awesome) people that has time to sit through this stuff then this should keep you busy for a while .[/background]

[/font][/color]

Part 13:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I setup the ballista so that it will interpolate it's animation based on the adjustable power and tilt

• I make the ballista play a shoot animation adjusted depending on the selected power and tilt

Part 14:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I setup more intuitive controls for the ballista (and other weapons) for adusting tilt and power

Part 15:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I identy the cause of editor freeze that occurred in the last couple of videos through a process of elimination and fix the issue

• Some small tweaks and fixes

Part 16:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I introduce the Developer Console system

• I create an exploding barrel block

• I make the trajectory indicator remain full when changing size

• I ensure the ballista bolt ejects from the ballista at the correct angle

Part 17:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I discuss my scene view camera technique

• I add and setup the new clouds model and skybox

• I add the WIP cannon model and setup the cannon mechanics

• I update some of the textures to higher resolution versions

• I add a custom inspector for the standard Transfom component allowing copy and paste and world space changes

Part 18:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I create a Quick Selection tool to allow for fast selection of multiple nearby objects

## Every Semicolon: Parts 11 and 12

I've done another couple of episodes focusing first on getting the first iteration of the Dwarf model into the game and then creating a component copying editor window using reflection. I wrote up some thoughts on my experience doing these videos a little while ago and never posted them. I'll most likely update that and post it in the near future. There's a lot of benefits to doing this that weren't immediately obvious, and I think it will be much easier for me to articulate those in text than while rambling away while programming in the videos.

Part 11:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I add the first iteration of the Dwarf model

• I write a script to reassign bones for skinned meshes to another skeleton

• I write the first step of an Actor script that randomly changes the playing idle animation

Part 12:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I write an editor window for copying entire components or component values to another object

• I fix up the initial orientation of the fired projectiles

• I setup the platforms to be able to move up and down on a sine curve

## Every Semicolon: Parts 9 and 10

Keen to get some of the new artwork in and working, I've done another couple of episodes of Every Semicolon. One of these days we're going to need to name this game...

Part 9:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I integrate some new block artwork, creating functional prefabs for each
• I modify the duplicate offset objects shortcuts to make the next prefab object in a series
• I setup a new test fortress with the new blocks

Part 10:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I setup the ballista bolt projectile with proper collision and custom center of mass
• I setup the ability to change the firing angle for the ballista (and other future weapons)

## Every Semicolon: Part 6, 7 and 8

I decided to hold off on posting about episodes 6 and 7 (which have been online for around a month) until I'd done episode 8 and was ready to continue rolling along with this game. After episode 7 I knew it would be a while before I had the time to do so since the project at my day job was entering the final ultra-crunch stage. Now that's over with (WHOO!) I'm more keen than ever to keep moving forward with this game's development and the video series.

Part 6:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I re-setup the scale of my assets and level

• I create a treasure chest block with code to spawn particles when it's destroyed

Part 7:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I setup the first version of the Ballista model

• I create a number of shortcut functions for object manipulation including duplicating objects with various offsets, translating objects around, creating new child objects and deleting children of selected objects

Part 8:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I create a projectile motion trajectory class to determine what the trajectory of a fired projectile will be

• I setup a 3D visualisation to show the trajectory while playing

I'm actually planning on doing a whole lot of work on this over the next few days, possibly doubling my current number of hours (14 hours 36 mins).

## Every Semicolon: Part 5

Part 5 is now online. I wanted to spend a bit of time on something other than the core gameplay mechanics so in this relatively short (1 hour) video I create a waving grass shader and an editor window to support mass placement of said grass (or any other prefab).

Part 5:

[media]
[/media]
(I recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I create some grass and write a shader to make it wave in the wind

• I write an editor window to mass instantiate objects within a certain region for mass placing the grass and future detail objects

It's still early days so I'd love suggestions on how to improve the videos so that I can evolve this video series as it goes on. I'm definitely going to continue doing it for the foreseeable future as it's a great cure for procrastination and a way of keeping track of exactly how long I spend working on the game.

## Every Semicolon: Parts 3 & 4

Parts 3 & 4 are now online. I've created a playlist that I'll update as new videos are added.

Part 3:

[media]
[/media]
(I Recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I develop the initial elements of a camera manager to handle smoothly repositioning the camera

• Made blocks have different damage states and be damaged based on collision velocity

• Write an editor window to revert multiple selected prefabs

Part 4:

[media]
[/media]
(I Recommend watching in fullscreen 1080P. Youtube).

Some of the events in this video:

• I spend some time on the 'blocks', making them something other than cubes and adding a stone block

• I make blocks destroy themselves when their health hits zero

• I create a couple of custom inspectors to manipulate and find scene objects

• I add object following and look at functionality to the CameraManager and track fired shots in towards the target

• I setup a system to determine when blocks are in an idle state to return the camera back to gameplay

## Every Semicolon: Part 1 & 2 - A video capture of a game made from start to finish

Before starting our new game project I had a thought: that I could record the entire process from start to finish and put it online as both a learning tool for others, and a way of receiving feedback on what I do so I too might learn some new things and improve the game before it's released. This will be a fairly long series as while the game is not massive, it's certainly not a small weekend game-jam sort of production.

So far I've recorded 2 videos, one 2 hours and the other 4 hours long. Trying to talk to yourself while working for 4 hours straight and not devolve into inane rambling is difficult (so far impossible), but this is something I want to improve on as I continue with this series. I'd really appreciate feedback on any aspect of the videos, be it the game itself, the video production, what I talk about or my programming and development techniques.

Here is Part 1:

[media]
[/media]
(I recommend watching in 1080P. Watch on YouTube)

Some of the events in this video:

• I start a new Unity project and begin setting up the folder structure
• I discuss some general concepts of the Unity engine
• I write some basic scripts and show how to apply and use them
• I show how to setup and use prefabs
• I show some shader development and get fooled by Unity 3.5's new Linear lighting solution which sends me on a shader debugging session
• I write a new custom editor window for measuring distance between objects

Here is Part 2:

[media]
[/media]
(I recommend watching in 1080P. Watch on YouTube)

Some of the events in this video:

• I develop the initial elements of a camera manager to handle smoothly repositioning the camera
• I create the first basic siege weapon in the game, the catapult with placeholder graphics
• I create the top and side aiming modes with placeholder controls and graphics
• I create the first "bullet" and set it up to be shot into the fortress

A little about me: I work full time as the lead programmer of a team working on large "serious game" projects in Unity and work on my own stuff (like the game in this series) on the side in my spare time. I've been working with Unity for around 3 years almost every day.

I really want to evolve and improve these videos so any feedback is appreciated. Especially important is if you really hate anything I'm doing, please let me know and I'll try to change that.

## Unity Asset Store

As an indie game developer it is hard to find the ideal marketplace for your current needs. Depending on your circumstances, the time and budget you have available will vary, as will the required monetary success.

Thus far through South East Games' short existence, our focus, like most others, has been the iOS App Store. While it can't be denied that success on the iOS devices is possible, achieving it can be more difficult than the thousands of aspiring game developers that have tried might have hoped. While we're still trying to find the spare time to finish our current in-development iOS (and other platforms) title, I thought it might be worth testing the water in some other markets. First, the Unity Asset Store.

[color="#E4E4E4"][/color]

Unity launched their Asset Store as a built in window in Unity 3.1 in mid November 2010. Upon release I was interested in getting in early with some products in the hope that being early would have the potential to be successful whether the store ended up a viable marketplace or not. Unfortunately as is often the case, my full time job became too busy at the time and I wasn't able to complete the product I was working on.

Over the past few days I've been reminded of the Asset Store once again thanks to a few blog posts showing some relatively successful products. First, Unity [color="#E4E4E4"][font="Georgia,"]showcased[/font][/color] their top seller on their own company blog.

[color="#000000"][color="#5497dc"][color="#E4E4E4"][/color][/color]
[/color][font="Arial"][size="2"][color="#E4E4E4"][font="Georgia,"]A&B Software[/font][/color]'s products are first-class and fill voids that the core Unity product releases with, namely an advanced GUI system and a 2D sprite manager.[/font]

[font="Arial"] While[/font] ~$15,600 isn't a massive number when we're used to seeing news of the million selling iOS game or the tens of thousands of dollars Notch rakes in daily from MineCraft, it is still a very desirable number for many developers and it's on a store that has a fraction of a percent of the competition as other marketplaces. This is not a one in a million proposition. [font="Georgia,"] Lets take a look at the featured product shown in the first image in this post, RageSpline. I saw the creator's blog post detailing his successful first five days on the store after Unity's lead graphics programmer linked to it on Twitter (@aras_p). 61 sales in 5 days at$50 each is a fantastic result, and since that post it seems to have continued selling just as fast or even faster.

For an experienced programmer, neither RageSpline nor A&B Software's products are difficult to develop, but they found holes and filled them. They've also both created polished products and have spent the time to create videos and showing off how to use their software and also the results it can achieve. I think this is a very important factor in their success.

The way I see it, the prioritised list of things to consider when developing something for the Asset Store is:

1. Find something people want that is not built into Unity
2. Develop a solid product with as much flexibilty (i.e. Inspector options, etc) as the design allows
3. Create videos that show off your product's ease of use and results in the best possible light

My final point there is mainly based on a hunch. Branding is obviously a significant aspect of many retail markets and I won't begin to understand the intricacies. A&B Software's Brady Wright has his 'EZ' branding and Juha Kiili can reuse the 'Rage' prefix on future products. If confronted in future with two competing products that do essentially the same thing, if one is branded with a name you trust from one of their previous products, that will be the one you choose.

So now I will begin at step 1, looking into holes in Unity that I think could use filling. The holes may not be immediately visible. RageSpline is an example of a product that fills a void you previously did not know was there, and Juha came to it through chance when working on his own title. I have some ideas already, but comparing features with other game engines and reading complaints on the Unity forum seem like a good place to start the search.

I will post back once I find the product and begin development. I'll also post any and all details on the submission process, sales, etc when the time comes.

Also posted on the South East Games blog.[/font]

## The Bridge

• Stopped working on my engine because of time constraints (next point)
• Worked at The Creative Assembly for a year on Xbox 360/PS3/PC game Stormrise and briefly on their next title
• Moved to a programming job at a company making 3D 'serious games' training sims (still there)
• Started a business to develop indie games on the side called South East Games
• Released 4 iPhone apps
• Slowly (very) chipping away at the 5th and most promising iPhone app

And that's essentially what I should've been blogging about here for the past 2 years. August 2008 was my last post, but in attempt to turn what once I fittingly named the 'Tool of Procrastination' into a motivational force of good, I'll begin posting here with a far higher degree of regularity.

Now that two years of my life (well, the game dev relevant aspects anyway) have been summed up in 5 points, I've bridged the void between then and now and my next post will be a rant on something interesting (with any luck) relating to the now.

## diarB dna kroW enignE

This entry: Entity Component System for my engine, Braid and stolen ideas (!!! :) ).

But first, I've got my first (well... second, but first that I'll be sticking with) job at a game dev. It's pretty much as entry level as you can get, but that's fine since there hasn't been any other jobs locally all year for me to go for. I might talk about it a bit more in future after I've actually started. I'm actually looking forward to an hour each way on the train (rather than loathing it as I did during uni) as it'll give me a distraction free time to code.

ES Engine Development: Entity Component System

No screens this time cause there's nothing new to show visually.

Edit: Added random screen of spheres... yay!...

Unfortunately I've not managed to get any of the methods I've come up with over the past couple of weeks to motivate myself to get work done has worked. Having the Olympics going all day every day on my second monitor didn't help. What I did manage to do over the last few days wasn't what I'd first planned, but I decided that getting the Entity system worked out was an important step before getting into what I was planning on doing.

I've based my 'Entity Component System' on the Game Object Component System (GOCS) from Game Programming Gems 6 which is a fairly simple, but good system. Essentially base objects/entities have a collection of components which each have their own specific data and functions. So an entity might have a visual component, physics component, AI component, etc. I'll talk about it more once I've finished.

I also had an incredibly frustrating loss of code LUA Manager code that I forgot to mention in my last entry. Basically the loss of code happened 4 months ago or so from my estimation. For whatever reason, I must've accidentally saved the cpp file after deleting everything inside a binding function. It was about 1000 lines of binding functions and whatnot to LUA. Considering I'd forgotten how to do all this not long after first doing it, the idea of re-learning and rewriting it was not one easily entertained. So I pretty much scoured every folder on my PC to no avail. Every backup was after the deletion. Thankfully I found the code on my laptop and all was well.

Lesson Learned: I'm an idiot... Or perhaps something about doing better backups or whatever...

Braid

So after the reviews started coming in on Braid, I thought I should check it out. So a week or two ago I downloaded the demo, played through it and then proceeded to buy the game.

I don't really want to talk too much about Braid since it's been covered everywhere, but it's an amazing game. As an indie game it is exactly the type of thing that all indie games should be aspiring to be. It's artistic and different. It offers a unique experience that people haven't seen before.

I'm not the biggest fan of the story. I like how it's told, but I prefer stories that are sort of weird and ambiguous to ultimately have a sort of brain explosion "oh snap" moment where everything suddenly comes into focus and retrospectively now makes sense. The ending to Braid, which was one of the best things ever in any game, did that somewhat, but still remained ambiguous and open to interpretation. While this mightn't be the case for Braid, it's sort of like a movie like Southland Tales where stuff makes a sort of sense, but remains open to interpretation to the point where the writer doesn't have 1 ultimate "this is what it is" answer to give. Although my reasons for why I don't like this don't apply to Braid as much since it's not really story heavy enough for any resolution to mean too much to the player.

Stolen Ideas

Obviously this is mainly faux frustration, but now that we're going to make another game based on our 'Outworlder' concept which revolves around jetpack equipped soldiers going to worlds and fighting bad guys (woah!), I'm more attentive to all those out there ripping us off.

Eg #1:
">Outlander
- Basically the same name.
- Features an alien guy coming to a planet to battle bad guys.
- Replaces jetpack (or does it...) with Vikings

Eg #2 - Dark Void (Yes, Jeff Gerstmann's GiantBomb.com. Awesome site. Hilarious videos & weekly podcast)
- Jetpack game... nuff said

Now okay, so perhaps both of these were being made before I started making the original Outworlder, but that's hardly an excuse.

Also just a something else I remembered when writing about Dark Void at E3, there was a game at E3 that probably was probably overshadowed by a lot of games and might've seemed to just another generic title. Darksiders: Wrath of War is the game and while initially I just saw the cinematic trailer which I thought was solid and well directed, it was once I heard the developers talking about the game that I decided it could be something good. Basically they just describe the game as being like a Zelda game. I'm hoping for a sleeper hit.

## Slow development

I'll be talking in this entry about my engine progress, changing game plans, some thoughts on potential XNA development and thoughts on making a game using Exult Studio.

ES Engine Development

I realised it has been a while since my last journal entry so I thought I could use it as a way of getting myself back into a good attitude for development.

Following my last journal entry, I wrote out a roadmap that detailed what I wanted to get done for each subversion leading up to version 1.0 of the my engine. It only took me a day or two to reach version 0.3 (I called what I was up to when writing the roadmap version 0.2) and estimated it would take me about half a week to reach version 0.4. About 1 month and 1 week later I got there. I can put this down to a few things, the top one being laziness, but I've also had some job interview-y stuff going on that has distracted me.

At any rate, looking over the upcoming tasks for 0.5, I'm really looking forward to getting back into it and I'm hoping to get through it all much quicker now. The roadmap was shifted around a bit as I decided on new features of the engine that affected others (such as going with a component system for game objects), but mainly what I've done recently is:
• Animation system
• A base per pixel lighting shader with features that can be toggled (eg. Num lights, normal mapping, parallax mapping, specular, specular mapping, shadows, shadow quality, glow/emissive map)
• Rewrote LUA Manager to work by running already loaded functions rather than loading the lua file every time it's used as I was doing earlier (LUA beginners mistake :) )
• Fixed timing functions

I'm still having issues with calculating the time delta each frame. I've never had this issue in the past and rewriting the functions 4 times with different time functions and precision didn't yield any different results. The deltaT seems to have an erratic result a couple of times per second (depends on the current frame rate) which results in jumpy movement. I've got to test the situation more on other PCs to see if it's a hardware problem. I'm using an Athlon X2 4200+ which is known for timing issues, but I've downloaded the supposed fix and in my code I'm setting the thread affinity manually in an attempt to avoid any issues, but it hasn't fixed the result. I've tried it briefly on a higher spec PC which was fine, a much lower spec laptop which was fine and a similar spec laptop (totally different CPU than on this PC) which seemed to have similar issues.

So to get to 0.5 I've got to code:
• A console
• Physics stuff: Tri-mesh objects, convex objects and a base physics character object
• Ragdoll objects
• XML Parser (probably will just use TinyXML)
• Hardware skinning for boned animating entities

Changing Game Plans

So last journal entry I talked about probably moving away from making an RTS and instead making something smaller in the vein of my previous game 'Outworlder'. Shane, my cousin and the artist I made Outworlder with and collaborator on any future games, and I came up with a game idea that we have since postponed (and therefore I won't talk about it now) in favour of an Outworlder-esque project that would have a short dev time and will let us create a more visually compelling game.

We're starting to design the different elements of the game now and I'll talk about it more in a future journal, but it's safe to say that it won't re-use anything from the old Outworlder game. So you won't be seeing this Outworlder (player character) or the Scaly (dead enemy) and hopefully not such dodgy ragdolling :) -

Instead we'll probably be going for a totally different Outworlder character and will probably have him on a world where the enemies are something like an ancient Mayan tribe. Those sorts characters and their architecture should suit the style we're going after.

I'm hoping to get a strong toolset created for the ES Engine so that once we've completed the one level version of this game, it can easily be developed further into a longer title if we want to.

Possible XNA Development Thoughts

I've thought on occasion about looking into XNA development, but haven't as I've instead been too preoccupied with developing this ending and university before that. When deciding to postpone the previously mentioned (but not revealed) idea, I thought I should look into XNA as a possible platform for when (if) we decide to develop it. While it might seem strange to ignore my own engine after it's finished, I'd merely be choosing a platform more suited to the goal of the project and being that I like to have multiple projects (game dev related or otherwise) at any one time, I'd no doubt be developing something with my engine at the same time.

From the little I've seen so far, it looks like a pretty solid framework and since I'd only be using it as a means to get a game made, I'd probably use an existing engine. The upcoming 3D editor features of Torque X are looking good so at the moment I'm thinking at the moment that I'd use that to cut down on dev time.

Exult Studio

I'm a big fan of the Ultima series, especially Ultima VII (especially especially Serpent Isle) and always look over fan remakes, extensions and the like. Exult is a fantastic project that needs no introduction for Ultima VII fans, and recently my desire to slowly develop a substantial RPG an hour at a time during train rides and the like led me to considering Exult Studio.

The idea of creating an Ultima VII style RPG over the next couple of years in my spare time when not working on other projects definitely appeals to me, but unfortunately I don't think it'll happen. When checking out Exult Studio I was quite easily able to edit the existing Ultima VII titles, but I had a lot of issues (crashing) when trying to start a new game project with Exult Studio. I spent a few hours trying to figure out if I could get around the crashing and get something started, but wasn't able to. I decided if I have that many issues with starting the project, it might not be a stable enough environment for what I wanted.

While making an Oblivion mod with TECS might be the best option at the moment, it's neither new enough nor old enough to appeal to me as an option at this point :).

## Engine work

Since my last entry my focus has been on my engine more than any RTS gameplay aspects. I did get level editing/painting stuff working and generating pathfinding information from the terrain done, but I'll talk about that more later when I get back to it.

The main reason I've avoided working on RTS stuff and also haven't posted an Outworlder post mortem is that I decided that I'd like to develop a complete game with the engine in a shorter period of time than an RTS would take and that will probably be a remake/sequel of Outworlder. Also, I thought there might be too many big RTS titles coming out soon for this to be the right time to make an indie RTS with delusions of grandeur.

Things have been progressing quickly with the engine when I've actually been working on it. I've got soft shadows working that I'm satisfied with using depth maps and VSM.

A shot of some shadowing from a transparent branch onto a monster

I've integrated PhysX after looking at Havok. Read into that what you will.

At this point I've got a pretty small list of things remaining to do for the engine before it's ready to make a game with. Fix LUA integration (make faster), add a console, create an AnimatingObject base class that entities can inherit from and create a particle manager.

At the rate things are progressing I'm pretty sure I'll work on it enough to get that done within the next couple of days. The only thing left to figure out is whether or not I develop tools any time soon.

I'm also planning on getting some sort of journal entry writing pipeline sorted :). Gotta get standardised image sizes (and thumbnailing) sorted out and also figure out how I'll be posting videos. I guess I'll also have to get around to sprucing up my journal template.

@Gaiiden, I missed your comment to my previous entry until just now. I don't think I'll write a post mortem to the original Outworlder anymore, but I'm going to be documenting the process of the development of this new Outworlder game and that will culminate into a post mortem. So a Feature Article might be an outlet for it at that point. Hopefully that won't be too far off. I'll be scheduling development soon so I'll have a better idea of when I expect to finish in my next journal entry.

## Some info on my new game project

WARNING: NO PICTURE IN THIS ENTRY :O

I thought I'd provide a bit of information on the game I'm currently starting because I'll be updating the journal often to talk about what I'm doing, what I've done and how I did it, and anyone that's interested in seeing how this project goes will know a bit about what to expect.

I was going to post an Outworlder post mortem in this entry, but I think I'll leave that for the next entry so I can put a bit more thought into it and get some screenshots and whatnot for it.

So even though no one would have noticed, this topic I made yesterday pretty much reveals that I'm making an RTS. I've actually wanted to make this particular RTS for a while now (which I'll probably talk a bit about in the Outworlder Post Mortem) and being fairly confident that I could, I've decided to just do it. I've followed a couple of RTS games made by independent, online teams for a while now: Dawn of Fantasy and 0 A.D.. The quality of these projects is inspiring, but I'm hoping to complete my game in a much shorter time than they've been in development.

While I've got some story details, factions/units, a tentative title and whatnot in my head at the moment, I'll hold off on talking those sorts of details at this point because they're pretty insignificant at this stage of development.

What I will mention now is some of my intentions with what I'll be programming and how.

Engine
I've been working on my engine for a little while now. After the mess that was the Outworlder code, I really wanted to create something that was clean and well structured for my next game.
I'm not that interested in creating a rendering engine at this point as I don't think it would ever really be of benefit to the end product so I'll be using Ogre again for rendering.
I'll also probably look into using Havok for physics when it's released for free, but at this stage there would only be minimal need for a physics library in the game.

The Object Factory is what I've probably spent the most time on at this point, but it's essentially finished. I really wanted one factory that could handle every single object in the game (it's templated, obviously) and handle all memory stuff (dead pooling, etc) and it's now doing all that nicely.

Scripting and Data Driven....ness
So before this project I'd never actually used a scripting language and external data file usage had been minimal. While I'm still doing lots of speed testing, I'm intending at this point to use LUA scripting for a lot of stuff in the game. I'm hoping every unit would run a LUA script for it's logic, every game state would just be a base state class and have all it's functions (entry, exit, logic, rendering, etc) written in LUA scripts, etc. Most of the logic heavy code would be written in C++ functions and I'd just give the LUA scripts access to those functions.

I'm also going to use a lot of external files for pretty much everything I can. I want to keep game specific C++ code to a minimum. There's a few reasons for that which mainly revolve around keeping things clean, development without much compiling and allowing easy modification to the game by the end user.

Tools
I'm intending on making tools (or one all encompassing tool) for creating/editing some of the things that will be in the external data files. At this stage I'm definitely creating a Level Editor that will allow for terrain deformation and texture painting (I just spent a couple of coding this already) and placement of environment objects, etc. Beyond that I might develop an in engine cutscene creation tool. Anything else I'd only develop if it was something that wasn't easy to do just by writing text in the data file.

Graphics
I'm going to be pushing the game as far as I can graphically. That may not mean technically pushing the hardware as far as I can, but instead it may mainly be the art direction and quality. I'm going to get some core systems working (terrain, unit selection, unit movement/pathfinding, RTS camera) and will then spend as much time as is needed to get the terrain, a few units and graphic effects looking as good as I'm after. During this period I'd also be developing the effects framework in the engine because graphical effects and particle effects in Outworlder were just hammered out all over the place. I'm looking forward to have a clean interface for adding effects.

So I'll post the Outworlder Post Mortem in my next entry and after that I might have something to show on my progress with terrain editing and/or pathfinding.

## 6 Months Later...

I guess it's kind of fitting that I stopped updating my "Tool of Procrastination" after finishing my game ("Outworlder"). I never intended to stop so abruptly, but things were pretty hectic at the end of my degree and my intention had been that I would get the game ready to be put online for download and would provide it and a post mortem in my next journal entry.

It turns out that I really really felt like the game was "finished" after we'd submitted it and displayed it at the Qantm Industry Night and Open Day. I was physically incapable of making the few changes I felt were necessary in order to release it. Also, although I'm happy with how it turned out, it's still only a one level game and I doubt anyone would be too upset with not playing it.

A blurry photo of our display at the Qantm Industry Night/Open Day and one of the many drooling gamers that got their hands on the game

So since then I've been looking for work and working on some new stuff. I've turned down a couple of job offers (possibly a mistake at this point...) and I took a job at a large game developer here in Australia, but moving to work there didn't agree with me so I didn't stay. For now I'm working on a few projects and waiting for more local game development jobs to become available.

One of those projects is a new game (and Ogre based engine) and I'll be updating this journal with more information about it as development continues. I'm really enjoying the freedom of having no set deadline with this project, but with any luck development will move quickly enough for it to be finished before too long.

I wrote a post mortem as part of my course at the end of last year for Outworlder and I'll probably expand upon that, post it in my next journal and give some information on my new game project.

Edit: No idea what happened to my old avatar, but I'm unable to upload a new one. I get: Microsoft VBScript runtime error '800a0007' Out of memory: 'CreateObject' /community/forums/editavatar.asp, line 80

## Play Testing

So here's the promised entry about my experiences thus far with play testing.

To summarise my following thoughts on play testing: Do it. Do a lot.

One of the most painful experiences on development of Outworlder has been the play testing and the key reason for that is silence. When someone that had never seen your game before tries to play it when it lacks any sort of tutorial or instruction and you can only respond to their confusion with silence... that's not easy. Unfortunately, I think that's absolutely the best method, at least for the majority of the time. We've done testing now at a few different stages of development and when there's no guidance, you can really see just how unintuitive your game can be.

Play Testing Pain #1A: The Scuttlers Not Caught Red Handed

These slightly menacing looking bug creatures pack quite a punch when they hit you. It's hard not to notice a large explosion around you and your health dropping down significantly, but it turns out it's a bit harder to notice the little brown scuttling culprit. It's not that they're hard to see, but more that they don't yet make any sound and the player isn't forced to look at where they spawn from. So the first problem with these little guys was making the player aware of them and what they could do.

We'd always been planning on having a character talk to you and give you help and also to make the Scuttlers make a distinct, unmistakeable sound as they scuttled along. While those two things will help a lot, we also incorporated Scuttler training into our new tutorial area (which was the main by product of play testing).

Play Testing Pain #1B: Stop Running From Scuttlers!

So little exploding bug like creatures isn't that unique or exciting in a game, but when you add the fact that you can suck up and shoot small objects in the game, things become more interesting... or so you'd think.
Picture this: There's a cave. In that cave is a pool of water and if you get close, a Scuttler is spawned every so often.
Now imagine that the person playing the runs away the first time. Fair enough, it hasn't dawned on them yet that they could use this creature as a weapon. Now imagine that this player repeats the above 10 times in a row. Take a deep breath.

So how do you fix this issue? The same way I did after the tenth time: you tell them what to do. Of course you might want to do it in a calmer tone of voice, perhaps like the one of the help character. As you saw in the previous entry, there's a wall blocking the way in the new tutorial island and we force the player to learn how to suck and up shoot Scuttlers before they can proceed.

Never expect the obvious to be obvious to everyone.

Run away!

Play Testing Pain #2: Fly Up, Stupid

So flying up a 1 metre incline is difficult. For some reason, play testers would often try to take a running start and boost themselves up anything in one go instead of first gaining altitude. While this is possible if you know that you can use the blast function to instantaneously gain height, most people didn't figure that one out.

To fix this, we added better flying training to the new tutorial area and also made the jetpack give you more of a height boost straight away when using it on the ground.

Play Testing Pain #4: Repeatedly Clicking When Nothing Happens

So the combat in the game is based around shooting rocks, Scuttlers and coconuts that you've sucked up into your jetpack back out at enemies. This means your ammo supply is limited to what you have sucked up. At the time of play testing we did have a HUD element showing the amount of rocks you had sucked up, but it was fairly ambiguous. This led to people often attempting to shoot when they had no ammo. It would usually take a good 5 seconds before they realised the problem and sucked up more ammo.

To fix this problem I put the most time in HUD creation into the rock meter. It now shows the maximum amount of rocks you can hold at your current Fuel Cell level, whether or not you are holding Scuttlers and also how many rocks you'll eventually be able to hold.

Play Testing Pain #5: Keep Shooting, It'll Die Soon

So Fuel Cell's shields were another problem. They would take about 4 rock hits to be destroyed, but the player wasn't told this and there was no indication that damage was done when they were hit.

An easy fix. We block off the passage in the tutorial island with a shield so that the player is forced to destroy it to progress. Also, the shield's colour will now change when damaged.

What to do... what to do...

Those examples were just some of the wealth of things that play testing helped me recognise. Play testing helps you determine what isn't as obvious as it should be or as easy or as simple and so on. It's extremely important to be open to change and to recognise what isn't working in your game and be willing to make changes no matter how much you like it. Something might be awesome for you, a master of the game; but to the new player it's a liability. The secret in those situations isn't to throw in the towel and change it to suit those players and not you, it's to put the thought and effort into creating a compromise. The amount of times that something in the game could've been changed to suit one type of gamer instead of another was numerous, but I always took the approach of finding a mechanic that would suit both and would be better than the original method in every way.

Notice the small things when people are play testing your game. Where do they look when they enter a new area? Do they follow the path that you intended? If they don't follow that path, is the game going to be a worse experience for them? Is there adequate feedback from the game to inform them when they've done something? Do they know what to do in the next 20 seconds of gameplay?

Get people to play test your game. Do it with different levels of gamer at different points in development. Never assume they're at fault when they can't do something. Take note of everything they do. Think about all the little things that could be added or changed in the game to make the play experience they had better.

## So tired

I never intended to have such a long gap between journal updates, but things just got really hectic for a while and the journal suffered because of it. After an 80+ hour week on Outworlder though, I now have the time to update.

We've done a lot of work over the past month and now that we're probably 2 weeks away from having a "finished" game, everything's starting to look fairly polished compared to what it was. The most significant part of the past month of development was play testing, which was even more painful than I expected, but I think my thoughts on play testing deserve their own journal entry.

I'm also going to talk about the music in the game in an upcoming journal entry, but to give you a sneak peak, you can hear Outworlder's main theme on our fantastic composer's site - www.piotrmusial.com.

Since I'm so tired I'll avoid writing too much and will instead just post some screens of some new stuff I added to the game in the past week.

A menu. Not especially exciting, but so much cooler with the music.

Fuel Cell shield blocking the way in our new tutorial island.

Damaged Fuel Cell shield after I shot a couple of rocks at it. The shield changes colour to show the player when they've damaged it.

A wall blocking the way...

No more wall. This is where we teach the player that they can suck up and shoot the exploding Scuttlers.

The path up to our reveal. Up until this point the game has taken place in a bland cave.

The reveal. Time to use the moves we just learned in this big island.

A boring old coconut.

Death by coconut. Coconut's split in half after hitting something hard. Shoot coconut halves for massive damage... Also note the dodgy ragoll system that I made in 2 hours. I'll make it better one day...

Hard to take a good screenshot of this, but I just rammed into a Scaly while flying really fast and he died, went ragdoll and flew off in the direction of pain.

I'm so glad that development is almost finished. While I like the game, it's hard to remain passionate about something for so long. I've got ideas for 2 other games I want to make now so I can't wait until I can get started on the first.

Edit: Also, what is with there still being no avatar uploading. I was sure there would be by now.

## Big Week

So coming off the week where I possibly did the least amount of work of any week yet in development of Outworlder, I'm now at the end of my busiest week yet. My goal this week was to get level editor and game to the stage where the level could be created and then played from beginning to end. I'm happy to report that this goal has been met and more.

Since our Beta (sort of) is due tomorrow, I'm still working heavily at the moment so this update will be short. The main things I did this week:

- Finished level editor
- Created a sound manager
- Improved Scaly AI
- In game video playback
- Added stuff to the level

Shane, the modeller/animator on the project also did more work on the level and texturing and it's all starting to come together really well.

I'll post more in a day or two about the level editor and other new additions. For now, here's a couple of new screenshots:

Looking at main island from the starting island

Fuel Cell with a shield in the distance

About to get shot by a Scaly

## Design Things

One thing that comes to mind that I've perhaps learned from making Outworlder is that you should make the player learn as few things as possible and give them multiple abilities based on what they learn. In Outworlder this is achieved with the jetpack. All the player needs to learn is that the main thruster is the most powerful (this is learned via the graphics) and the side thrusters can rotate, suck and blow. Once the player knows this, you can give them as many abilities as you want that make sense and are easy to control and the player will know how they work and how to use them.

Video of Side Thrusters

The jetpack has to provide all the gameplay in what is admittedly a short game. It can:
Fly w/ Main Thruster: Main thruster pushes the player up. Limited manoeuvrability.
Fly w/ Side Thrusters: Allows the player to (almost) hover when not flying forward or back. Forward or back movement is fast.
Fly w/ both: Fly higher quicker and better manoeuvrability.
Blow: Blows small rocks forward, potentially damaging enemies. Can also blow back Scuttlers.
Blast: Uses all main thruster fuel. Launched player up. Unearths small rocks. Damages nearby enemies.
Suck: Sucks up rocks in front of the player and stores them (number storable depends on number of Fuel Cells collected). Can suck up Scuttlers for a short time also.
Shoot: Shoots stored rocks or Scuttlers, potentially damaging enemies.

Side thrusters blowing rocks and partially extended.

Side thrusters fully extended.

What would probably be even better would be some way of combining abilities at the same time. That would extend the design concept I spoke of further. For now though, the abilities that are there give the player some freedom to create unique situations/solutions.

I also feel like most core aspect to a game should be inherently fun. As Gaheris commented in my first journal entry, jetpack gameplay is typically automatically fun. The basic act of simply playing the game should be fun, even without doing the things that the developers spent probably the majority of their time trying to make fun and interesting.

Despite my own opinion of the game being like a roller coaster so far throughout development, I'm overall pretty happy that I don't hate it completely yet and I'm actually really looking forward to playing the finished product. That said, I'm extremely keen to start making another game. I'm thinking after I've finished Outworlder I'll work on an engine/framework for a short while using the same things that I'm using now (Ogre, PhysX, FMod, etc), but giving me a much cleaner and more comprehensive framework for developing another game. At that point though I'll probably (hopefully) have a job, so it might take me longer than usual.

This week I'm going to do a lot of work on Outworlder because we've scheduled the Beta release for next week which means that's when that assessment is due for us. It's not worth a whole lot of marks, but I really want to get things finished.

Hopefully by then superpig will have got the avatar uploading working :). If he does then maybe I'll make the game that I thought up for 4E6...

## The To Do List

As well a new season of TV shows starting up, a wealth of new games coming out and limited "free time" because I'm interning in a programming position as part of my course 2 days a week, a big problem with working on the game at this point is the deceptively short to-do list. It makes me feel like I don't need to work too much to get the game done on time.

Basically I have about 9-10 weeks to do:

• State Manager
• Scaly AI Improvement
• In-Game Help Text/Subtitles
• Sound Effects
• Optimisations: Basic impostor system
• Optimisations: Occlusion culling

Plus I'd like to get ragdoll in for the Scalies when they die.

Compared to the amount I did in the first half of development this is nothing, but my internship leaves me burnt out by the weekend. Still every Monday and Tuesday we have to go in and work on the game from 9-5 and show our progress in a weekly meeting, which is good cause it prevents any major slacking. Ideally I'd like to have everything on that list completed in 3-4 weeks so I can spend the rest of the time polishing and tweaking.

So a little more information on the game: Humans occupy almost all planets in their galaxy and in an effort to expand their empire, they send expeditions to neighbouring galaxies. One of these finds hostile alien life which then traces the expeditions route back to the human galaxy and invades. You play as Outworlder Alpha-87, the 87th inductee into the elite ranks of the Outworlders. These soldiers are sent to remote planets that don't have a strong defensive presence.

The game takes place 10 years after the start of the invasion and Outworlder Alpha-87 is sent on his first mission which is to retrieve new Fuel Cell technology that has been developed on a research planet. Unfortunately the aliens (the Maurosaur) arrive first and shoot down the Outworlder's ship. It crashes into the ocean with your equipment and you're left with only your jetpack to battle the aliens and retrieve the scattered Fuel Cell prototypes.

You jetpack has a main thruster which is mainly used for flight but can also blast all its fuel out at once, damaging nearby enemies and unearthing small rocks from the ground. The jetpack also has side thrusters that can suck or blow. They can assist in flight, blow rocks or suck up rocks and then shoot them out. The more Fuel Cells you collect, the better your abilities will be.

The main enemy the Maurosaur or "Scaly" is a humanoid lizard creature that shoots bolts of energy from their weapon. They will take cover behind nearby rocks and whatnot when being attacked.

The other enemy is the Scuttler. These are small crawling creatures that are about the size of the typical rock that the Outworlder can shoot. They will charge at the player and explode on impact, but the Outworlder can blow them back or suck them up and shoot them like grenades. They will explode after a few seconds once sucked up if not shot.

The game is being made to be short and sweet. It will take place on one level and there will be 8 Fuel Cells to collect. Once the player has collected them then he'll be able to fly high enough to reach the research outpost and fly away.

Very boring but I guess I had to explain all that. To show that I did actually fix the Scaly weapon offset after the last update, here's a screen:

## Journal Justification

If this journal is about my game, then it's not really procrastination, right?

I've been reading GameDev journals for years now and I've been waiting until I had something to write about before I ever made one of my own. I don't know if that time was really now, but I should be working on my game at the moment and this felt like a way to get my mind back on track.

My game is Outworlder, a 3rd person action game in which you fly with a jetpack and suck up rocks and shoot them out to kill enemies. I'm programming the game with 1 animator for the final project of my games programming degree using the Ogre engine. The other 4 groups making games for their final projects in the same course have 4, 7, 8 and 9 people; which I guess made us the 'underdogs'.

I'm sure I'll go into more detail about my game and myself in future journal entries and I'm determined to post pictures every update (they're what keep me constantly checking for updates to Dan Green's journal).

This time I'll start with some screenshots from various builds of my game throughout its development.

June 14 2007:

Small test terrain. Testing my texture splatting shader.

July 02 2007:

Cubes (placeholder rocks) with PhysX physics and ribbon trails.

July 13 2007:

The first "Scaly" (main enemy) model in the game.

July 29 2007:

Scalies with specualar mapping and crappy edge lighting shader effect I wrote.

August 15 2007:

Scalies moving to cover positions and shooting at me and my water shader I wrote reflecting terrain. The Outworlder model is finally in the game with specular mapping.

September 07 2007:

First pass of the level mesh put in the game and testing texturing it. Early lens flare effect. New Outworlder shader: per pixel lighting, rim lighting & specular map.

September 29 2007 (Latest Build):

Updated level mesh, terrain texture splatting sizes changed, lens flare changed to different sun flare effect. Added side thrusters to Outworlder.

Outworlder falling.

Outworlder flying up.

Outworlder flying forward. Starting island shown.

Looking out onto beach area from inside canyon. Trees.

Looking at beach area from water. Water reflection, refraction with fresnel term.

Blowing Scuttlers (other, exploding enemy) back. Fuel Cell pickup with shield shown.

Scaly with updated shader (basically the same as Outworlder's). Inaccurate weapon offset from hands (I'll fix that after this journal entry ;) )

I'm really happy with how developments gone thus far. We've still got a ways to go, but it's all starting to come together now. Check back in for my future updates where I'll detail more about the game's development and more about the game itself.