So... it's been almost a year since I've updated this. Wow.
As I'm wont to do, picking too many projects to work on at once in my fabled "free time" has sorted itself out in letting things fall through the gaping cracks in the floor. Cryamore is going strong, lots of development and talent behind it, and that's where I've been devoting any available development time that I might scrounge up from life.
I've been working with Unity extensively over the past year, and have learned a lot of nice practices that I want to incorporate into the design of this game's framework. To that end I've been peeking back into the repository here to re-familiarize myself with my own code, and thankfully I think the only real changes I want to make are in the portions of the renderer that aren't yet built.
As free time won't be any more available in the near future than it already is, Hazard Pay will probably sit in limbo while I try and meet the milestones for Cryamore's development track. I still love the ideas behind this game, and may just reach a point where I'm more interested in getting the game out there than writing everything myself, so when Cryamore goes gold I'll have to assess if I'd rather flex Unity or UDK to make the vision a reality, or keep on with the low-level work.
Thanks for reading, apologies for the silence.
An indie FPS/RTS in development
Friday, March 14, 2014
Friday, April 26, 2013
Long time, no post, let's do something about that...
The major downside to having this as a personal hobby project is that just about everything else comes first priority-wise, leading to some long breaks in the action if the perfect storm of life events and daily workload hits. Blah. Here's the latest:
Resource packages can now contain shader objects as well as geometry data, so now I'm one step closer to a fully-featured material system being in place. That'll make materials themselves very lightweight objects, basically named references to individual shaders, textures, and tune-able values. The renderer is prepped to use a material-based sorting process for minimizing changes to the render pipeline, so the sooner I finish up with the material system's pre-reqs, the happier I'll be with the graphics side (which currently just draws everything out in a linear fashion, oblivious to shared material properties). Not a lot of impact on the current system right now because the asset count is so low, but it'll be mandatory with a full scene of objects, players, and effects.
I've escaped from the jungles of dynamic mesh topology algorithms with a fairly efficient means for rebuilding local mesh patches on the fly (to respond to new intersection events), which came about as part of the process for getting the automatic Navigational Mesh generator tool up and running in my level editor. The idea there is that anyone building a level won't have to custom-paint their own navmesh polygons, because the editor will be able to analyze the geometry of the entire terrain and build a navmesh with minimal polygons as part of the "compile" process for the map. It really deserves its own post soon, I had a lot of fun (and learned a lot) getting it working. The next step is going to be hooking the patch re-triangulation portion up to the in-game world manager so that the mesh gets rebuilt as players drop in structures or walls get destroyed, etc.
Also, work is progressing well on Cryamore, if anyone was able to check out the demo at GDC last month, here's hoping you enjoyed it!
Resource packages can now contain shader objects as well as geometry data, so now I'm one step closer to a fully-featured material system being in place. That'll make materials themselves very lightweight objects, basically named references to individual shaders, textures, and tune-able values. The renderer is prepped to use a material-based sorting process for minimizing changes to the render pipeline, so the sooner I finish up with the material system's pre-reqs, the happier I'll be with the graphics side (which currently just draws everything out in a linear fashion, oblivious to shared material properties). Not a lot of impact on the current system right now because the asset count is so low, but it'll be mandatory with a full scene of objects, players, and effects.
I've escaped from the jungles of dynamic mesh topology algorithms with a fairly efficient means for rebuilding local mesh patches on the fly (to respond to new intersection events), which came about as part of the process for getting the automatic Navigational Mesh generator tool up and running in my level editor. The idea there is that anyone building a level won't have to custom-paint their own navmesh polygons, because the editor will be able to analyze the geometry of the entire terrain and build a navmesh with minimal polygons as part of the "compile" process for the map. It really deserves its own post soon, I had a lot of fun (and learned a lot) getting it working. The next step is going to be hooking the patch re-triangulation portion up to the in-game world manager so that the mesh gets rebuilt as players drop in structures or walls get destroyed, etc.
Also, work is progressing well on Cryamore, if anyone was able to check out the demo at GDC last month, here's hoping you enjoyed it!
Friday, February 15, 2013
Behind the Scenes :: Critter Exploration
Life's been...well...life, as is often the case, but I have managed to put in a little time recently for some concept development. Thought it might be fun to share, so here we go.
I've had a running idea in my head of the various kinds of bugs that will assail the player(s) as they try and reap the rewards of the planet's mineralogy, but none of the concepts were very fine-tuned. I'm sure of the behaviors I want them to express, but their actual appearance is in that "perfect in my head, undefined on paper" kind of state.
The following, therefore, is what my visual exploration and refinement process looks like for one of the first bug types the player will meet.
I knew that I wanted a pack-critter, something that roamed in small-to-large groups and harassed the players due to their speed and melee preference. I had initially thought to try and model the bug off a dog's anatomy, but those all channeled a little too much Skagg (of Borderlands fame) so I kept digging. The end result was more of a rabbit-insect hybrid, and I've been happy with how that's coming out.
As these are all roughs, I'll put up a "final pass" of this fella in a more formal spotlighting post, much like our heroes and any supporting cast. I'll make sure to save the bigger/rarer creatures' reveal for the game itself, but these guys will be roaming around on the intro level, so guilt-free: it's not much of a spoiler. :)
I've had a running idea in my head of the various kinds of bugs that will assail the player(s) as they try and reap the rewards of the planet's mineralogy, but none of the concepts were very fine-tuned. I'm sure of the behaviors I want them to express, but their actual appearance is in that "perfect in my head, undefined on paper" kind of state.
The following, therefore, is what my visual exploration and refinement process looks like for one of the first bug types the player will meet.
 |
| (click to enlarge) |
I knew that I wanted a pack-critter, something that roamed in small-to-large groups and harassed the players due to their speed and melee preference. I had initially thought to try and model the bug off a dog's anatomy, but those all channeled a little too much Skagg (of Borderlands fame) so I kept digging. The end result was more of a rabbit-insect hybrid, and I've been happy with how that's coming out.
As these are all roughs, I'll put up a "final pass" of this fella in a more formal spotlighting post, much like our heroes and any supporting cast. I'll make sure to save the bigger/rarer creatures' reveal for the game itself, but these guys will be roaming around on the intro level, so guilt-free: it's not much of a spoiler. :)
Sunday, January 27, 2013
Other rumblings in the indie development scene
I've been picked up as a programmer for an old-school action RPG that some of you may have heard of, it's been pitched around various twitter/tumblr feeds for the last few months:
The team has some awesome talent involved, check out the trailer through the link for more!
(Work will still continue on this project, no worries)
The team has some awesome talent involved, check out the trailer through the link for more!
(Work will still continue on this project, no worries)
Thursday, January 24, 2013
Meet the Cast: Episode 1
What she's wearing is part of the standard-issue gear for all new employees of the RATE (Resource Acquisition & Territorial Expansion) program, the meal ticket that brings both of our heroes to the shores of the game's home planet. If you're familiar with US history, it's similar to the deals handed out to homesteaders that pushed westward from the Mississippi, only...in space.
Stay tuned for Episode 2, where we meet her cavalier red-headed team mate, and learn more about what waits for players in this backwoods corner of the galaxy!
Tuesday, January 8, 2013
New year, new focus
Not much to add, just throwing a quick post up that says the project is still in progress, albeit recovering from the slowdown that the holidays bring. All christmanewyears revelry being finished, and with life attempting to resume its normal, 10%-less-hectic pace, I've picked back up on getting this game to a playable, demo-able state.
I think 2013 is going to be a good, fun year.
I think 2013 is going to be a good, fun year.
Tuesday, November 27, 2012
Once more unto the chopping block
So some great news for me, the SharpDX Toolkit was released at the end of October, providing a clean high-level interface with DirectX11 similar to the XNA model, only not reliant on XNA support. I'm especially excited because it allows me to fall back on what is most assuredly a better-structured library than what I cobbled together while learning how to program a DirectX pipeline.
While this doesn't break my current code, it does give me a great foundation to make one final sweeping overhaul to the main engine/library to focus on a data-centric model. My existing code wraps a lot of data objects with personality and functions that really should just belong to an authoritative "Renderer" object, so I've started moving towards a design that simplifies my camera classes, effect libraries, and other infrastructure entities and makes them components of a primary Renderer. That renderer will work with a single source of world data and state data to render the entire scene (from world geometry to actors, UI, etc) appropriately for the gamestate.
The other impetus for cleaning up and officializing (is that a word?) my data components is interoperability with other sub-systems. My physics and AI managers are going to need to access subsets of the world data to do things like calculate navigation meshes and collision hulls based on a dynamic worldspace, as the players will be creating (and destroying) walls, buildings, nests, resources, and so on. Moving data management and world change responses into a singular "world manager" that can handle manipulation and access to a geometry and materials heirarchy will keep that organized and clean behind some simple interface calls.
So aside from the (I promised myself, final) design overhaul, I've been off in right-brain land honing my art chops before I start cranking out assets I actually want to use in the game. I'm pleased with the practice and progress, and should have some character sheets of the main characters (in their designer-blessed officialdome) available shortly, with environment shots to follow. Everybody loves some good concept art.
While this doesn't break my current code, it does give me a great foundation to make one final sweeping overhaul to the main engine/library to focus on a data-centric model. My existing code wraps a lot of data objects with personality and functions that really should just belong to an authoritative "Renderer" object, so I've started moving towards a design that simplifies my camera classes, effect libraries, and other infrastructure entities and makes them components of a primary Renderer. That renderer will work with a single source of world data and state data to render the entire scene (from world geometry to actors, UI, etc) appropriately for the gamestate.
The other impetus for cleaning up and officializing (is that a word?) my data components is interoperability with other sub-systems. My physics and AI managers are going to need to access subsets of the world data to do things like calculate navigation meshes and collision hulls based on a dynamic worldspace, as the players will be creating (and destroying) walls, buildings, nests, resources, and so on. Moving data management and world change responses into a singular "world manager" that can handle manipulation and access to a geometry and materials heirarchy will keep that organized and clean behind some simple interface calls.
So aside from the (I promised myself, final) design overhaul, I've been off in right-brain land honing my art chops before I start cranking out assets I actually want to use in the game. I'm pleased with the practice and progress, and should have some character sheets of the main characters (in their designer-blessed officialdome) available shortly, with environment shots to follow. Everybody loves some good concept art.
Subscribe to:
Posts (Atom)