I’ve decided to release the editor I developed to create 3D models for Substream…
“Heditor” is a very basic modelling program which outputs models as a C header file (.h), which means you can include model data directly into any program without having to write any supporting code.
Since I originally wrote this program in the belief that I’d be the only one to use it, Heditor only has the modelling features I knew I'd need to develop Substream. So although the program has a nice smoothing algorithm which automatically creates higher LODs of very simple models, it doesn’t have materials or texture mapping.
However simplicity was the goal, and it’s best and most unique feature is that it outputs model data as a header file. If you’re a C, C++ or Objective-C developer working on a game prototype or tech demo, you can get models into a project incredibly easily, without thinking about file converters, asset directories or model loading code. Heditor's interface is very easy to learn as all the keys are listed on-screen in a context sensitive fashion.
You can get more details or download it here.
I should probably point out that this doesn’t mean you will be able to make new enemies for Substream, sorry! I’ve released the editor for people to use in their own gamedev projects.
Lately I’ve also been working on the very last part of what I’d consider to be the game engine: collisions with the terrain. By no coincidence, this last feature has been the part I’ve really not been looking forward to working on. Actually I’d attempted it twice in the past only to be driven crazy by it.
The reason this has been so difficult is this: the position of Substream’s terrain is calculated on the graphics card’s processor using shaders, it’s rendered, and then the graphics card throws it away. Some data about the terrain is generated on the CPU, but it’s final position is only ever known by the graphics card. So although you can see it as clear as day, the game code can’t actually access the position of the ground to work out whether something has collided with it!
I’ve considered a few ways to get around this. In the end the best way has been to run through the shader’s code again on the CPU (just for the small area of terrain directly below the player or other objects) using a DirectX function called ProcessVertices. Basically this is a strange and seldom used function, and there is very little in the way of documentation or tutorials on the net, plus as a lone indie developer there are no expert programmers on-site to help me. This has been a problem where I’ve had to just go at it with no idea how long it would take me to figure out.
I was very close to giving up, and was starting to think of ways to redesign the game and some of the levels so you couldn’t physically fly near the terrain. Luckily I’ve cracked it, and I’m now working on collision response (how the player’s ship physically reacts when it takes a hit against the ground). This is very good news; it means being able to scrape close to the ground to avoid enemy fire, flying around and through obstacles, and potentially having to dodge the terrain as it morphs in front of you.
