Switching gears

As of a few days ago I have switched gears back to working with UDK, as it was suggested to me that being familiar with Unreal would be a big plus, currently. Thus my racing game is being put on hold as I work on a quality portfolio piece in Unreal :)

Loading up the latest (Nov 2012) UDK really surprised me as to how many new features and visuals are present! This really got me excited as to what kinds of amazing things I'll be able to create, and the wheels in my head are already turning.

I'll be reimagining a section(s) of a game that is near and dear to my heart, so stay tuned for more details later on in the week! :D

Reworking the code

With the release of Unity 4 I've decided to rework my code and make it more modularized again, just like what happened with Star Gen 4. This is partly to do with the fact that I've written myself a design doc streamlining and shaping my ideas, which in turn made me realize that the way my project was written made it unsustainable for a large scale development beyond a proof of concept. And it's a great way to learn how to do things properly as well, or at least better than before.

In my new iteration I'm planning on having the ships pretty much assemble themselves within the script instead of pre-assembling them in the editor as complex prefabs, as part of the modularization.

With regards to art and style, I've been examining XGRA for inspiration since, like Extreme G3, it has some incredible race tracks, probably some of the best I've ever seen. And it makes me wonder what a game like F-Zero would be like in those types of levels. There is only one way to find out! Nothing like getting inspired, and wanting to reach the final product so you can play it!

Now time utilize the available time properly and make things happen :D

Oh yeah, and I haven't given up on Star Gen 4 either, I just need to figure out a decent renderer, one that won't take a month to render a full skybox. It makes iteration and debugging rather painful!

Descent controls

This is just a quick post about my recent experiences with Descent 2 and 3. While I don't think I've ever played Descent 2 all the way through, I must say that it's an interesting experience playing both games with an Xbox controller, and more or less at the same time.

Some of the key things I've noticed is that a proper controller setup makes all the difference in a game, even one as complex as Descent. At first I thought that the whole 6DoF would present an issue, but it didn't, especially with standard FPS controls. After a while it became pretty intuitive.

But one of the biggest differences that I felt was in how different the two games felt in terms of their movement. D2 (and probably D1) feel a lot more loose and floaty compared to D3 which has a damped and rigid feel; the ship doesn't drift as much. Now mind you that might have a lot to do with joystick deadzones and how they're setup in both games, but this goes back to how it affects the feel of the game. Something so simple having such a large effect.

Not that I don't mind D3's controls, if anything they feel a little more refined. At the same time, D2's controls just seem to fit the game just as well. Just goes to show how the whole package makes a game what it is :)

Yay game design!

Game prototype update

Since I've had a week or so to dedicate to my Unity project again, I've decided to start implementing those nifty advanced features I've been talking about. Mainly jumping between different versions of the track, basic AI, and a smooth camera, as well as some more inventory items.

The track in itself has been a learning experience for me, as it needs to be fun and challenging at the same time. Not just from an art point of view, but from a level design perspective too. To be honest I think I got a bit TOO ambitious with the current track design, but I was going for a vertical slice style concept :)

The AI, while it works well enough, is still pretty dumb. A lot of it's movements I need to tone down on curves because it clearly can't steer fast enough to avoid the track edge, and due to the physics, it ends up crashing. With no reset feature yet, once you crash, it's game over :)

The smooth camera was a simple matter. I simply needed to unparent the camera from the player, and then add frame averaging to both position and rotation. 4 frames for position, and 16 for rotation. The update the position, rotation, and apply an offset to look pretty.

I like my laser weapon too: a line renderer with an instanced prefab at the very end. I'm debating whether to add any sort of autoaim to the inventory items. Either as a cone, or only vertical like in Extreme G3. Although I'm not quite sure how to implement it without testing the positions of each racer every frame. Maybe have a invisible "target" which always stays ahead of the ship and follows the track? Hmm, I'm certain there are tutorials or whitepapers on this kind of thing, lol.

I've mentioned this before, but I'm looking forward to working with a programmer or two on this! Someone who can take this to the next level in terms of polish and functionality. So far my code works, but something tells me it could be prettier and more optimized. Good a demo, but might not scale well for a full game.

Here is the latest video update of my work. Mind you that there is still a lot of grey blocking and temp art, so don't expect anything TOO fancy, yet ;)

Woot!

-M

Side notes

After 8 years of doing continuous mixes for cruising around and listening at work, I've decided to post them online to share with the world :)

http://www.mixcloud.com/Renalicious/

Unity, three weeks and counting

For those who are interested, here is the third progress video of my Unity project. It represents about 3 weeks worth of work.

Some of the major changes to the physics was the use of wheel colliders, instead of spheres, as well as how the forces on the ridigbody are being calculated: grounded and airborne flight are treated differently, but less so than before.

I also implemented a Wipeout / MarioKart style inventory and item system. Running oven an item pad selects a random item which you can use, etc. And also a functional GUI, which was surprisingly easy to implement =D

Next comes AI, and some of the more advanced game features (which will remain a surprise for now!), and finally the main UI and menus. I'm hoping that by mid - late October I'll be ready to begin creating high quality art, and more tracks as well.

More later!

Unity and me

Looks like things have shifted a bit and I switched my focus from making tools and programs, to learning them, while I am working towards my next gig in the industry. I thought why not take the time and learn Unity? After all, it's used a lot through out the industry, and knowing it well can only be an asset :)

I got myself Unity 3.5 and began tooling around; it was a great first impression. Although I'm not sure why, I wasn't expecting it to be as powerful and capable as is it, but seeing the kinds of games people make with it, and some of the videos people post online, it is clearly a very powerful toolset!

For my test project I decided to create one of my game concepts, a racing game akin to Wipeout, F-Zero, and Hi-Octane, with unique added twists ;)! Things came together quite quickly thanks to the plethora of available generic assets, online script references, and people's Q&A discussions too. Within a week I had something that was at least presentable, and after another 10 days it was almost a game (sans race logic, GUI, front end, AI, etc). Truly not bad for something I had never touched before this month, just reinforces the simplicity and power of the toolset.

While it has a ways to go before I'd be willing to release it as a playable demo, I can offer some WIP videos :)

WIP #1, 7 days

WIP #2, 17 days

I use a rigidbody for the hovercraft with 4 spheres on each corner, and then apply various forces and torques based on the player input. While I managed to remove some of the jumpiness using Unity physics interpolation and smoothing out the track (more polygons), I think I need to go one step further and make a very smooth collision mesh, and loosen up the track. After all, looking at Wipeout and F-Zero, aside from jumps and a few hairpins, the tracks are pretty loose. But naturally that kind of decision really needs to factor in how the hovercraft will ultimately behave (having been coded by a skilled SE) and if flying off the track has any inherent fun to it.

After a short break talking to my game designer friend about project ideas (And an awesome Orbital concert) I'm ready to start scripting more fundamental elements. Once those are in place I can piece together an experience worth sharing as a playable demo. And naturally make sure the art isn't placeholder either. A fresh coat of paint can go a long way to improve the overall appeal of a personal project (not to mention give me an excuse to spend some quality time in 3dsmax ;)

More later!

Linked lists

I must say that linked lists are pretty crazy, having never used them before. While the concept is fairly simple to visualize as a series of connected 'nodes', it's a brain buster to code and visualize as far as code is concerned. At least for myself, at this point :)

The whole structure appears to be the epitome of recursion right from the start; like a hall of mirrors. Of course after running through everything in my head it's beginning to make more sense.

The interesting part is that linked lists appear, to me, to be a gateway to BSPs and other such trees (such as Oct trees). After all, you have nodes, traverse up and down, and can remove and add quickly. What linked lists don't have is hierarchy of trees, but that's a simple matter, right? ;)

So far I'm still hung up on the render of Star Gen 4, but I think that may change soon(ish) once I've begun sorting stars for efficiency. That and I haven't really done much coding in the past month. Priority has shifted to other areas in life.

More to come about linked lists and BSPs from a tech art perspective soon :)

Star Gen 4

Star Gen 4 has been coming along nicely, and amazingly I've reused pretty much nothing from Star Gen 3, save for the idea of how to do everything. But even so, how I'm doing things now is much better than before. I'm talking considerable improvement!

I've written as much OOP as possible; nearly everything is OOP except for the two highest level functions. Now the program looks and feels like something that was written by someone who knows what they are doing, hah! :D

Not too keep droning on about programming practices (which everyone probably knows anyways), but I'm amazed at how much easier to understand the code becomes when you know you're dealing with functional and object oriented programming. I have a function and I know what it will return, I have a class and I know it will handle it's own data properly, etc.

Star Gen 4 is also different in that it is almost much more of a simulation than previous versions. I've decided to generate stars based on real world properties, not just as a pixel with RGBA values. A lot of weird math is involved, but I'm certain this is the way to go. All I need now is to create a renderer which doesn't take 12 hours to complete one texture, and I'll start the tuning and polish phase ;)

And eventually I'll take the guts or Star Gen 4, and transplant them into a shiny new GUI version ;)

Math functions

I'm in the process of expanding my own math library, without STL, and as usual it's quite the learning experience. What has me racking my brain now is pow(float y, float x), which I need to properly compute exp(float x).

Integer powers are easy, but floats provide that extra bit of frustration because of the decimal place. Maybe it's just late, and it'll come to me in the morning ;)

The premise with an example number: pow(12.5, 4.205), how to do it? It breaks down into pow(12.5, 4) * pow(12.5, 0.205). So how do you get the second part? As it turns out, it's not too trivial to solve, at least by hand, or personally written algorithm.

As is outlined here: http://lamarotte2.blogspot.ca/2011/04/hand-calculation-of-fractional-decimal.html
Yikes... O_O!

So basically:
result,  value,  exponent
1.00 = 12.5 ^ 0.0
???? = 12.5 ^ 0.1
...
???? = 12.5 ^ 0.205 <--- we need to find this
...
3.54 = 12.5 ^ 0.5  <--- sqrt(12.5)
...
???? = 12.5 ^ 0.9
12.5 = 12.5 ^ 1.0

So we need to bounce back and forth performing square roots on numbers to find a result of 0.205. And use that number to then multiply it with (12.5 ^ 4)

And all of this is needed so I can solve exp(float n) without using STL. Yeesh, the goals I give myself sometimes ;)

Strings to numbers

As I'm working away on my program, sans STL, I realized that I have a need to read a file and use the data within for various means. However this presented a problem because I didn't have a string to number converter, and as I didn't want to use STL I would need to write one.

Researching the problem of string to floats I found out just how complicated the issue could get. To do things properly the function needs to be able to handle all manner of different inputs, and still produce a useable float, naturally. But looking at strings and how error prone they can be that's where the real challenge lays I thought.

I did find online documentation that broke the problem down into a very handy intermediate step by using a so called "triad", or an int array with three elements: [sign][number][exponent], and as long as these three are populated properly, reconstructing the float is trivial. 

Started writing this I decided to put it in my string class to make use of it's functionality instead of in math or somewhere else, and that made things a bit easier.

First find either "nan" or "inf" and return the appropriate result, which in itself is rather interesting. How do you define a not-a-number, or infinite float? 0/0 isn't a number, but it won't compile either ;) It's only through cleaver casting of strange values is it achieved.

if(input.findTextNoCase("nan") >= 0)

{

static const unsigned long __nan[2] = {0xffffffff, 0x7fffffff};

return (*(const float *) __nan);

}

if(input.findTextNoCase("inf") >= 0)

{

static const int value = 0x7f800000;

return *(float*)&value;

}

The rest involved locating the negative / positive sign, locating any exponents (is 'e' is present), and finally converting regular numeric characters into a number.

for(int i = 0; i < inLen; i++)

{

if(input.isNumeric(input[i]))

{

valueStruct[1] = (valueStruct[1] * 10) + charToInt(input[i]);

}

}

Finally as the last step it's all added and multiplied into the resulting float.

float result = int, if there is a negative sign multiply by -1, and if there is an exponent, either keep multiplying or dividing by 10 until the necessary value is reached. Now while my method probably won't handle everything that gets thrown at it, I just need it to handle values I give it, and it seems to do that without problem, woot! 

Thats it for now! :)

Next gen star gen

After studying id's Doom3 source and libraries for a while and working on my own stuff, one thing led to another and I started working on StarGen 4, lol. Amazingly I decided to do a complete rewrite of everything I had done before and start from scratch.

One of the biggest things I've learned while writing RenLib is a good (proper?) use of classes, OOP, and functional programming. The fact that I now go back and look at StarGen 1, 2 and 3 and have a hard time figuring out just what is going on says something. And it was that same procedural code that made the previous star generators so unportable and difficult to modify. Sure version 3 was "better" in the same way you add modern car controls to a steam powered car, but it's a far cry from what version 4 is turning out to be.

OOP is also changing the whole core functionality of the program as well, and how my data is created, organized, and sent back to the user. I'm floored! I mean, I'm sure this is all common sense to a regular programmer, but I'm just a technical artist creating this stuff, so to me it's practically magic ;)

Getting back to RenLib for a second; while most of the functionality is done (for what I need to do with it at the moment), I'm proud that I managed to avoid using STL and intrinsic as much as possible. Even when it comes to math functions like square roots and logarithms. Mainly thanks to the combines knowledge of the internet, but still :)

Assembly optimization is also very fun once I see some concrete and working examples of how to do things. The only thing that still eludes me is Intel's AVX, but since I don't have a compatible processor, and it's still very new, I'll let that slide for now ;) For now it's satisfying enough to have working SSE code that doesn't cause runtime exceptions all the time.

That's it for now! StarGen4 is still a long ways away, so nothing to show yet. My hope, however, is that I am able to create something as beautiful as the Space Engine, albeit prerendered.

Learning libraries

Looking at the Doom 3 source code I found that id wrote some of their own libraries to handle data. Things like strings, lists, dictionaries, vectors, etc. And talking to a friend of mine he said that a lot of it was due to the fact that the standard template libraries, while they work as intended, are usually not well suited to tightly controlled resource management that games require.

This interested me, so I decided to write my own little library, one that wouldn't require STL at all (As much as I could get away with that is). So far it's been an interesting experience in C++. I've become so used to using regular features like lists and such in Python, but never considered using them in lower level languages. They were there, but for some reason STL's notation can be so difficult to understand.

Take strings for example, it's just a char array, but the function descriptions can be so confusing with so many namespaces and shorthand variable names. But thanks to id's source code, I now have my own personal STL free string library that mimics some Python's functionality. Not to mention some assembly optimized functions too :)

So where is this going, you may ask. I never did get to look at ray-tracing (yet), but it got me thinking about the star gen version 4 I've been planning. In the past month or so I've learned a lot more about classes, OOP, and functional programming, that it's making me realize just how I want to write the next iteration and make it even more modular than before.

As for assembly optimization, I know there are intrinsics I could use, but again that requires including external includes, and this whole exerciser is all about learning how things are done. Though MMX and SSE assembly seems much more finicky than simple scalar stuff, but it's a start :)

That's it for now! Oh and Mass Effect 3 is awesome! ;)

Star images

Here are some quick examples of the HDR starfield (The exposure goes much further than these examples show)

Dark:

Medium:

Bright:

The one thing that I really should fix is making the cloud maps tillable.

That's it for now :)

Star generator version 3, part 2

Version 3 of the star generator is more or less done, and producing good results. Naturally whenever a project like this is done I find myself looking back and planning how things can be improved. The whole layering system for example. Right now everything is defined within a text file and read from top to bottom. While this works well for stars and basic nebula blending, it doesn't behave quite like I would like it to.

One of the main reasons why I'm still not completely happy is that any subsequent layer affects the previous one, especially with blending clouds. I may attempt to write a new feature that includes actual layers which then get composited together though a final command, ultimately making it one step closer to a world-machine style star generator.

For now I think I'll leave it as is, and focus my attention elsewhere. Sure there are a few things that I would like to fix, like the whole sphere to texture coordinate mapping, and maybe star bursts for brighter stars. I'll probably save those for version 4.

Next up on my plate I'm learning about ray tracing, but not in the traditional sense, AKA rendering. More like finding object A from object B, while bouncing off walls. Think billiards, but not a game :) I won't say too much right now because I would really like to get some proof of concepts going (Maybe in C# since I'll be able to draw things much easier than in c++).

And maybe, just maybe, if I'm feeling really saucy, I'll try playing around with the Doom 3 source code and implement this new idea. On a quick side note, it's funny how the Doom3 source code is much more readable than the original Doom code. Maybe it's the whole C++ / OOP they did.

That's it for now!

Star generator version 3

I decided to do another complete rewrite of the star generator, this time using a config file to define all my parameters; config files make everything so much more easy to use.

It's quite the learning experience however since I need to think about how to get things to run, and look, properly based on an arbitrary number and arrangement of layers. Not to mention figuring out how best to store star locations and keep things separate from dust / gas layers. And then finally how to combine everything. Ultimately rendering a latlong panorama that looks correct.

I could go on and on about what tricks I'm using, but I'll just say that I've implemented some of my changes I talked about in my previous posts, and actually using a class to store stars, etc. It runs amazingly faster than version 2, and is a lot modular too :) Woot!

Of course everything is still being rendered out into a 128bit DDS file

More later!