Not a lot of time at the moment but i finally fixed the key input issues i was having with my rendering. While i finish the other minor details, i can post something else.

I really love uplink.

In honour of its awesomeness, you may notice some resemblance to it in certain places.

The original :

My game : 

 

 Its intended as a tribute cos i really loved the original.

Meh, trying too hard to redo the same image, with more detail. Got bored so im gonna do something completely different instead. [caption id="attachment_110" align="aligncenter" width="450" caption="ignore this one"] [/caption]

Taking on a challenge (while waiting for certain things to be finalised on shadowracer, and other things taking my time), I decided to challenge myself to some code architecture design. Like designing systems that are clean, simple and efficient while being powerful enough to maintain their stability and usability on a much larger scale. Things like networking, user interface design, game core runtime designs etc. V8 One of those steps was getting the v8 javascript engine running nice and smoothly behind the scenes of the core code base, which was incredibly easy thanks to their simple approach. Using a modified base of CProxyV8, i have managed to expose entire classes to script on a whim via some really minimal preprocessing of class files and macros, which will be polished and released here as soon as its a viable tool. Multi User Interface design Allowing the switching of user interface engines at any time (even runtime) was another challenge i took on, which has also proven quite fruitful so far. While using the PhoenixCore engine for rendering at the moment and hooking up some gameswf flash UI code to that is quite powerful , i still have the flexibility to change those at any time with minimal wrapping of gameplay code. Interesting Gameplay While the engine may be all cool and dynamic it doesn't serve any good without a nice fun game to play. I wont be speaking on what exactly i have gotten into making with some friends but i can post some mockups that have come up so far. [caption id="attachment_110" align="aligncenter" width="598" caption="Coming sometime"] [/caption] [caption id="attachment_110" align="aligncenter" width="800" caption="Coming sometime"] [/caption]

man, i went back to visit this underground art community im part of only to find : Amazing interface designs I found out the day before the deadline! So i spammed a rush entry, and didnt get very far , The concept being a split/broken interface, something like : Which then after a few hours was like this : Long story short i got reinspired by insane timeframe and managed to pull the final out just in the nick of time. I turned the design into a wrecking ball instead... [caption id="attachment_110" align="aligncenter" width="600" height="760" caption="BB 53"] [/caption] Hope you like it! I enjoyed painting it.

Wow, this is some really awesome news. During the month of December 2009, you can pickup full fledged binary (no source code) licence to the amazing Torque3D game engine. Not only that but that constitutes a $250 licence discount on the professional (full source code) version at any time. Read the blog here : Link!

Some time ago i started my game project for shadow racer. I looked to release a nice playable demo by rage expo 2009. Well crazy enough, thats a month away. This doesnt change my time line much as i was planning this all along, its mainly down to assets for the demo. This is always the hardest part. Another note, SuperTuxKart is using irrlicht and they are doing an amazing Job. Get the game and the info for free from : http://supertuxkart.blogspot.com/ Theres a little of this and that going on around too. Ill post more info soon but for now : And lastly , Oh, sleeper 's new album kicks a huge amount of ass. Worth buying twice imo. http://www.solidstaterecords.com/promo/168/

OK so i fixed the wrong orientation in the reflections while i had a spare bit of time. They definitely look a lot better now, theres ONE tiny little thing left to do. Theres seaming from this technique which is normal, but for some reason theres a wrong seam elsewhere. I know where, just will take some more time to fix. For now, some better images :

Another idea i wanted to try was mixing the environment colors into the diffuse color of the object, making it pickup the lighting from the environment around it. This was helped by the realtime reflection, because Blindside gave me a cool idea. He suggested i blur the reflection map and use that to calculate the ambient lighting, but i have opted for a number of techniques i will try. The first was to simply do a color multiply from the diffuse to the reflection, seeing if it "taints" my diffuse color as i had hoped. It worked as expected and i was glad to see the lighting from the scene affecting the objects. I tested with some white diffuse and the db9 model from someone on the forums (aux) and i managed to bind the lighting to the scene with not much extra cost. Below are the screenshots before i attempted the objects catching the environment light, and after is the results of todays quick test. No environment lit objects : Using the lighting around the car to light it as well : Nowhere near as awesome as it can be, ill obviously tweak it more and more... As well as fix the inverted reflections as soon as i have time to.

Thanks to SteelStyle who write a nice HDR Image format loader i was able to throw in a quick HDR lit environment map, which i can test with and adapt easily for use in the game. Some other cool things is i keep going round in circles with the reflection. First its upside down, but the right way round. Then its the right way but horizontally wrong etc. I only tried a couple brute force values but ill fix it whenever i get around to thinking on it again. For now, some more in game eye candy.

So i went through some tests to see what was going down and i have a few conclusions. The distance the camera is from the reflection is not adhered to (i must test this in other DP examples i have) but its obvious to see below. First image was rendered in blender with raytracing, and the other 3 are in game (the reflection is not changing size at all). Ill fix this later, amusing as it is.

So i was using a modified version of blindsides realtime dual parabloid reflections for shadowracer, and it was looking quite decent while i was testing and was enjoying the look i managed to achieve. I then decided to actually take a screenshot with some other objects in the scene (this is quite a few months later) and realised that the reflection was infact completely wrong??! Something im doing is wrong but ill fix it later and ill have something new to show soon. In other areas the level art isn't going too badly, more work to be done. The reflection below shows just how wacked it is : The moral of the story is test your stuff extensively and often . Dont rely on the hope that it works in all cases.

So i haven't posted in ages, this is normally the first line of most blog posts so i thought i would follow suit. I have been working on shadowRacer for quite some time in my spare time and have done a load of work on my framework, but most of all iv had a lot of fun. Ill post a more detailed blog about the development at a later stage but for now i will post some concept art that I and others are working on. Firstly my original vision started out as being really strong ambient occlusion baked into the textures, with some high quality shaders and vivid colors. Then i saw mirrors edge previews and saw exactly what i had imagined (within reason) and i liked what i saw, and continued in that vein. The second part of the concept was "sticky black stuff", imagine venom/carnage style architecture and world environment based on that. As i came around and around concepts all the time i decided that it would be cooler to tie into a story, and the black stuff was "taking over" and theres a story why, and a reason to race. Ill start the line of concepts from day 1, to current. First few concepts : The original vision was shiny black gloss stuff, with white pristine worlds. And the spheres being shiny and glossy and vivid. Some ingame concept shaders were proving interesting : The realtime scene reflection came into play in game to help further the vision : Started messing around with some of the sphere concepts, realising that solid spheres cannot get really interesting, so see through ones with cool details inside was the next step At this point, one of my extremely awesome artist friends did some 2 minute sketches to help me visualise stuff a bit better : Messing with the baked lighting approach which im still going towards : Some more concept paintings (a paint over on a tutorial environment) of the black stuff and a quick sketch of the color circle concept (the way the city will be built), and finally, a quick render of the city concept : This post is just a preview. Ill post a lot more on this soon including in game videos and shots. Thanks for reading. Notes : All in game renders are done using the shadowEngine game framework, which is a mini layer on top of the awesome irrlicht engine. All artwork unless otherwise mentioned i made. The game will feature many popular effects (already implemented) such as realtime depth of field with focal changes and shifts, selective realtime screen space ambient occlusion, soft shadowing with point light shadow maps and other fun things. All gameplay is also driven fully by bullet physics engine and includes things like soft body, camera controllers and other fun things with physics.

I was learning some things in zBrush and its really cool. I generated some cool pillars and stuff, made a couple of normals and template textures, now i have a number of unique pillars off a single 30 poly mesh :)

Using max for game development has been done time and time again. As an artist, using max is natural. As a programmer using max is powerful but hidden a lot of the time. Merging the artist and the programmer makes things simple and effective in game development. “The technical artist” is supposed to be the gap filler in this situation. In large game companies, multiple artists and multiple programmers bring a good turn around, but with the right tools the job gets easier, faster. Give an artist a functional tool and the programmer wont need to spend time a) explaining what code does, b) explaining why the tool cant perform certain tasks, and c) wasting time fixing small bugs over and over as the engine progresses. As a smaller company working together is vital. “The aspect of team comes in very handy”, is a thing of the past. The integration is crucial to making games games, and making games well. The artist, for example can flourish given the toolset he or she may require, leaving the programmer free to make the game play more game like. Keeping things tight as a team makes it fast and easy to update things. Keeping your head out of the clouds and keeping ahead of things can be difficult in the industry, but the first steps in the right direction give amazing amounts of progress, fast. This is where we have gotten to lately. An artist with a tool, that can be extended, should be given the tools he needs to make the game easier on everybody. Understanding that taking a few days to learn new things and taking a long time to figure things out comes naturally when programming, but the artist without the tool, can wait without the tool. The programmer taking 15 minutes out of the normal code to toy around with a new tool for the artists can greatly improve understanding on all levels. Once there is a familiriaty with the language, and or extension toolkits there can be massive improvements to everyones workflow . Below i outlined a couple of pointers for the two sides of the team, should it benefit you. Artist : 1) Be clear and concise. No programmer needs vague explanations and needs to figure out art jargon while programming. 2) Be reasonable. No programmer wants to spend 6 months making a tool for the game. Start small, and start simple. A toolkit is made up of many parts, massive toolkits are made from massive amounts of code. Start with automating repetive tasks. Things that will increase your workflow will slowly show you where you can grow. Show you where you can learn. 3) Be understanding. The programmer SHOULD dedicate time to you, and your workflow. In a small team this can make sense and can be easier, where as larger teams this requires perhaps dedicated technical artists but the concept remains. Give the programmer a clear, concise, simple tool addition description, and give the programmer time to work it out. Keeping in mind that the team is a team, you can do great things if you let them happen. 4) Be predictable. From the start keep things consistent. How you like things, make it clear. How you work through toolbars, make it clear. How you layout your shortcuts, make it clear. As you work further, there can be less interaction, and more working together. An understanding of who you are working with makes it easy to guess the next step. The next feature. “Working in the zone” makes it easy to program, knowing what can help and improve your artists workflow before asking, makes it faster to develop, faster to please the artist and easier to make games. Hope this helps, the next post regarding this subject will detail a few techniques in maxscript that will definately help in game development, as well as in making custom formats, or using existing formats to exploit the engine you are using. We are using torque in some cases and we use XNA for others, writing tools for Max, XSI, and other 3d apps doesnt take too long, and can make the game engine itself unbelievably easy to control content, to control art assets, to control scripting engines, to automate importing exporting, almost anything can be achieved in a short time.