It's ready.
It's a maze. Get through it. Lights are your friend.
https://dl.dropbox.com/u/22131146/1gam-january-amazingmaze.zip
* read the README.TXT file
* requires DX11 card
* requires gamepad (I suggest 360 controller)
* requires VC2012 runtimes (installer is in the .zip)
Friday, February 1, 2013
Thursday, January 31, 2013
Day 30 - finish or failure?
Wow look, it's January 30 already!
Will I finish and release something tomorrow night?
Here's a current video.
Will I finish and release something tomorrow night?
Here's a current video.
Wednesday, January 23, 2013
Day 23 - some progress!
I promised myself I would make some progress on my 1GAM a month tonight, so I did!
Nothing terribly exciting, however definitely important for productivity. I finished up my simple 'tagger' so I could tag a node in maya as an "asset root" (so everything under it gets lumped into one addressable asset), as well as being able to specify the material name for meshes in maya. Materials are completely separate from geometry, I just need to call out the name of the material resource. I also made an 'auto-export' button in Maya that just 'Does The Right Thing(tm)'
If you're curious, here's an example of a material data file:
The parameter/texture names here get bound to parameters of the same (string) name called out in whatever shader is used to render the object. This was just some test blend shader I was working on a while ago.
The material calls out the default effect name as "testeffect_col_tex" - however that's not exactly the shader. Within that effect are different shaders for different engine supported features (skinned, lightmapped, skinned+lightmapped, ...). This lets me use the exact same material resource on several different meshes, and the engine can pick the correct actual shader. Some day the different shader variants will be auto-generated, but I'm not there yet.
At some point I'd like to make a blog post just covering my material/shader system. I've iterated on the concepts several times and think I have landed on a very clean and extremely flexible architecture.
The next thing I need to do for the game is implement simple trigger volumes, and make one that triggers level completion when you bump into it.
Nothing terribly exciting, however definitely important for productivity. I finished up my simple 'tagger' so I could tag a node in maya as an "asset root" (so everything under it gets lumped into one addressable asset), as well as being able to specify the material name for meshes in maya. Materials are completely separate from geometry, I just need to call out the name of the material resource. I also made an 'auto-export' button in Maya that just 'Does The Right Thing(tm)'
If you're curious, here's an example of a material data file:
The parameter/texture names here get bound to parameters of the same (string) name called out in whatever shader is used to render the object. This was just some test blend shader I was working on a while ago.
The material calls out the default effect name as "testeffect_col_tex" - however that's not exactly the shader. Within that effect are different shaders for different engine supported features (skinned, lightmapped, skinned+lightmapped, ...). This lets me use the exact same material resource on several different meshes, and the engine can pick the correct actual shader. Some day the different shader variants will be auto-generated, but I'm not there yet.
At some point I'd like to make a blog post just covering my material/shader system. I've iterated on the concepts several times and think I have landed on a very clean and extremely flexible architecture.
The next thing I need to do for the game is implement simple trigger volumes, and make one that triggers level completion when you bump into it.
Thursday, January 17, 2013
Visual Studio and Custom Build Rules
Today I was interested in generating some code. I made an external tool that took an input file (.gen) and output a C++ header (.h) file.
Then, I wanted to make this as painless as possible to set up in VS, so that whenever you added a .gen file to the project, it would automatically know how to build it, track dependencies, etc.
My first attempt was of course the familiar "Custom Build Tool". If you add an unknown file type to a VS project and go to its Properties page, you can build the file with a "Custom Build Tool", then fill out a Command Line to run, etc.
Now, this would totally work. Except it's really tedious to maintain. It must be propagated to every configuration your project builds with. It's a giant painful error-prone way to maintain this sort of thing.
There's a better way. As I understand it, as of VS2010, VS is built on top of MSBuild. There's a set of files (a .props, a .targets, and an .xml file) to create your own "Item Type" that can be selected to build files with.
I'm going to lay out a simple example that worked for me. I don't end up using a .props file in my example as I didn't need it, but presumably you can use that to add your own properties that can be set per file for the build step.
Disclaimer: I don't know if this example is completely minimal - I was just happy to actually get it to work. The documentation for how to set this stuff up is really hard to find and dig through.
First, the .xml file (in my example, codegen.xml).
This is nifty and part of the magic. I don't exactly understand the difference between an ItemType and a ContentType, but here's the pragmatic explanation: given this, when you add a .gen file to your project, it will recognize that file as a "CodegenItem" and associate the build step with it. Which is coming next.
Here's the .targets file (codegen.targets) (because of the use of $(MSBuildThisFileName) in this file, it's important that the file name matches the .xml file, so codegen.xml + codegen.targets)
So the first order of business is to 'include' the .xml file we have above, and associate the ItemType that comes from there ("CodegenItem") to the Target we have below ("GenerateCode").
The target is the actual build step. We give it a name "GenerateCode". Next, the BeforeTargets="ClCompile" attribute says that this build step should be run before the ClCompile step (which is the name of the target of the built in C++ compiler). Because I'm generating code, I want this. Next the Inputs and Outputs ("Identity" is the name of the file the build rule is applied to, and Outputs need to be specified so that VS can understand file dependencies).
I thought the Message entry would actually get displayed when the build step as invoked, however it doesn't. I don't see it output in the Build window, but I left it there because I think it should work. It's possible it's being printed to some log file somewhere. Here is the documentation for it: http://msdn.microsoft.com/en-us/library/6yy0yx8d.aspx
Finally, the Exec task (docs here: http://msdn.microsoft.com/en-us/library/x8zx72cd.aspx) - this specifies the commandline to execute. Straightforward - I have a codegen.bat file that takes the input and output file and does its thing.
Now, I would suggest putting these files alongside your .vcxproj. To actually get this to work, open VS, right-click your project and select Build Customizations... In this window, choose Find Existing... and browse to and select your .targets file. Then check the box to enable it. Now, when you add your files to a project, it will have your custom build step associated.
So, there you have it. Now here's the questions I'm left with:
- How do I refer to the Inputs and Outputs of the Target in the command line? I'd like to say %(Inputs) and %(Outputs). Needing to repeat that is redundant and tedious.
- Why doesn't the Message print in the Build window?
- Where's all the friendly introduction docs to this feature?
Thanks to John Calsbeek for a point in the right direction!
Then, I wanted to make this as painless as possible to set up in VS, so that whenever you added a .gen file to the project, it would automatically know how to build it, track dependencies, etc.
My first attempt was of course the familiar "Custom Build Tool". If you add an unknown file type to a VS project and go to its Properties page, you can build the file with a "Custom Build Tool", then fill out a Command Line to run, etc.
Now, this would totally work. Except it's really tedious to maintain. It must be propagated to every configuration your project builds with. It's a giant painful error-prone way to maintain this sort of thing.
There's a better way. As I understand it, as of VS2010, VS is built on top of MSBuild. There's a set of files (a .props, a .targets, and an .xml file) to create your own "Item Type" that can be selected to build files with.
I'm going to lay out a simple example that worked for me. I don't end up using a .props file in my example as I didn't need it, but presumably you can use that to add your own properties that can be set per file for the build step.
Disclaimer: I don't know if this example is completely minimal - I was just happy to actually get it to work. The documentation for how to set this stuff up is really hard to find and dig through.
First, the .xml file (in my example, codegen.xml).
This is nifty and part of the magic. I don't exactly understand the difference between an ItemType and a ContentType, but here's the pragmatic explanation: given this, when you add a .gen file to your project, it will recognize that file as a "CodegenItem" and associate the build step with it. Which is coming next.
Here's the .targets file (codegen.targets) (because of the use of $(MSBuildThisFileName) in this file, it's important that the file name matches the .xml file, so codegen.xml + codegen.targets)
So the first order of business is to 'include' the .xml file we have above, and associate the ItemType that comes from there ("CodegenItem") to the Target we have below ("GenerateCode").
The target is the actual build step. We give it a name "GenerateCode". Next, the BeforeTargets="ClCompile" attribute says that this build step should be run before the ClCompile step (which is the name of the target of the built in C++ compiler). Because I'm generating code, I want this. Next the Inputs and Outputs ("Identity" is the name of the file the build rule is applied to, and Outputs need to be specified so that VS can understand file dependencies).
I thought the Message entry would actually get displayed when the build step as invoked, however it doesn't. I don't see it output in the Build window, but I left it there because I think it should work. It's possible it's being printed to some log file somewhere. Here is the documentation for it: http://msdn.microsoft.com/en-us/library/6yy0yx8d.aspx
Finally, the Exec task (docs here: http://msdn.microsoft.com/en-us/library/x8zx72cd.aspx) - this specifies the commandline to execute. Straightforward - I have a codegen.bat file that takes the input and output file and does its thing.
Now, I would suggest putting these files alongside your .vcxproj. To actually get this to work, open VS, right-click your project and select Build Customizations... In this window, choose Find Existing... and browse to and select your .targets file. Then check the box to enable it. Now, when you add your files to a project, it will have your custom build step associated.
So, there you have it. Now here's the questions I'm left with:
- How do I refer to the Inputs and Outputs of the Target in the command line? I'd like to say %(Inputs) and %(Outputs). Needing to repeat that is redundant and tedious.
- Why doesn't the Message print in the Build window?
- Where's all the friendly introduction docs to this feature?
Thanks to John Calsbeek for a point in the right direction!
Wednesday, January 16, 2013
Day 16 - I haven't abandoned you!
Yikes, no updates in about a week. I'm finding it difficult to balance work and working on my 1GAM project, so the reality is that I've made almost no progress. I have not abandoned this effort!
My current 'todo' is implementing a simple Maya tool so that I can attach custom metadata to nodes in the scene that get exported with the geometry data.
One such piece of metadata is to be able to tag a transform node as an 'asset root'. When I export a scene from Maya, I currently jumble all of the geometry into the scene into one geometry asset. This gets thrown into an asset pack file, and in the editor I can refer to assets within a pack file with/a/pathname/like/this.asset:some_asset. Tagging a node as an asset root will let me export more than one asset from the same Maya scene. I want this so I can put the physics and visual geometry of a level / object / whatever in the same Maya scene. This is a workflow issue that's just really tedious to manage currently.
The other piece of metadata is the name of the material to apply to the geometry. Currently the Maya exporter exports everything with one of a few different hacked-in materials. I've been manually fixing up the data after it comes out of Maya. Putting the material name on the node will be very helpful, so I can easily change geometry and there's nothing tedious in the way.
So, that's where I'm at. It's a bummer, for sure, but work is my priority. I think I'm only going to reasonably be able to spend time on this during weekends, and I'm not sure if I will finish something by the end of the month. I would very much like to, so that gives me 3 weekends (really only 2, but I'll cheat and say that I can spill into the weekend of Feb2+3).
So, what is the minimal 'todo' to get something playable in 3 weekends?
- get some sort of 'end level' implemented. The current level can easily be considered a maze, so let's say I'll plop down an exit trigger in the level. If you hit it, you beat that level.
- I can very easily churn out let's say 5 levels. Really, I can create a level in Maya, and get it working in game in 5 minutes.
- this COULD be all! in this state, the game is "find your way through the maze". I can package that up and call it good.
"stretch goal" (because kickstarter)
- polish the stomper hazard. In my last post I have the 'todo' to make this feel good. I'll need to implement level restarting (easy!) and then this could be a 2nd point of release. I can plop down a bunch of stompy's in the levels and call it good. Unfortunately I don't have a prefab system yet, so it'll be more than a few minutes to get these scattered in the level, since it's just a handful of components to attach to an object.
Really with the time left, I'm hesitant to reach any further than that. I'm in the home stretch now, so I need to wrap it up.
That said, there's a few different ideas for what to do for February:
- continue working on this game. Implement new hazards, polish it up better, release a v2
- start work on some brand new game idea
- spend some time doing engine tech (few things I could use immediately: prefab system, rotate+scale gizmos, undo)
My current 'todo' is implementing a simple Maya tool so that I can attach custom metadata to nodes in the scene that get exported with the geometry data.
One such piece of metadata is to be able to tag a transform node as an 'asset root'. When I export a scene from Maya, I currently jumble all of the geometry into the scene into one geometry asset. This gets thrown into an asset pack file, and in the editor I can refer to assets within a pack file with/a/pathname/like/this.asset:some_asset. Tagging a node as an asset root will let me export more than one asset from the same Maya scene. I want this so I can put the physics and visual geometry of a level / object / whatever in the same Maya scene. This is a workflow issue that's just really tedious to manage currently.
The other piece of metadata is the name of the material to apply to the geometry. Currently the Maya exporter exports everything with one of a few different hacked-in materials. I've been manually fixing up the data after it comes out of Maya. Putting the material name on the node will be very helpful, so I can easily change geometry and there's nothing tedious in the way.
So, that's where I'm at. It's a bummer, for sure, but work is my priority. I think I'm only going to reasonably be able to spend time on this during weekends, and I'm not sure if I will finish something by the end of the month. I would very much like to, so that gives me 3 weekends (really only 2, but I'll cheat and say that I can spill into the weekend of Feb2+3).
So, what is the minimal 'todo' to get something playable in 3 weekends?
- get some sort of 'end level' implemented. The current level can easily be considered a maze, so let's say I'll plop down an exit trigger in the level. If you hit it, you beat that level.
- I can very easily churn out let's say 5 levels. Really, I can create a level in Maya, and get it working in game in 5 minutes.
- this COULD be all! in this state, the game is "find your way through the maze". I can package that up and call it good.
"stretch goal" (because kickstarter)
- polish the stomper hazard. In my last post I have the 'todo' to make this feel good. I'll need to implement level restarting (easy!) and then this could be a 2nd point of release. I can plop down a bunch of stompy's in the levels and call it good. Unfortunately I don't have a prefab system yet, so it'll be more than a few minutes to get these scattered in the level, since it's just a handful of components to attach to an object.
Really with the time left, I'm hesitant to reach any further than that. I'm in the home stretch now, so I need to wrap it up.
That said, there's a few different ideas for what to do for February:
- continue working on this game. Implement new hazards, polish it up better, release a v2
- start work on some brand new game idea
- spend some time doing engine tech (few things I could use immediately: prefab system, rotate+scale gizmos, undo)
Wednesday, January 9, 2013
Day 10 - (alive || dead)
10 days already? Geez. So technically I'm 1/3 done with this game. I'd would say I'm not in terrible shape, except I know the unknowns will prove me wrong.
Tonight I made my stompy spike object deadly. I was able to attach a physics primitive that gets moved appropriately, and added collision tests to that vs the ships in the game (of which there is 1). If they collide, the ship is marked 'dead' and attached to the spikes. The idea here is to have the spikes impale the ship, and kill input so you feel helplessly stuck as your ship carcass gets smashed by spikes.
I've re-purposed the light shining down to show when the ship is alive/dead, for debugging. Green light = alive, red light = dead :)
To polish this up the physics shape on the spikes will need to be adjusted (from a sphere to a box), and the ship should be attached by projecting the ship position onto the spike plane, and raising it off by the ship radius. Then, tighten the physics geometry so there isn't a noticeable 'pop' when the transition happens. Or, even better, kill the input (so the ship is 'dead'), and don't do a rigid attachment until the spikes 'move into' the ship and the ship is a certain distance from the spike plane. This latter solution will look best - you get killed, which freezes you in place, then I can have the spikes look like they impale you until the ship reaches the bottom of the spikes, then you get stuck to it.
Additionally, the far extent of the spikes should be limited to the ship's radius so you don't intersect the opposing wall. To polish this up, keep the current behavior (so it penetrates the wall as it does now) - *unless* there is a ship attached, in which case don't penetrate the wall all the way. That will make it look super slick.
Also, I think the camera will need a little bit of jiggle in this state - being attached to the spikes gives a pretty jarring camera movement - if the camera is a little looser/springy, that can make it feel better.
I'm hesitating to show it to you without the slickness implemented, but in the interest of fully documenting my progress and possibly teaching someone out there something, I'll show what it looks like right now (horrible) so maybe you can appreciate the work game devs do to make games awesome :)
Tonight I made my stompy spike object deadly. I was able to attach a physics primitive that gets moved appropriately, and added collision tests to that vs the ships in the game (of which there is 1). If they collide, the ship is marked 'dead' and attached to the spikes. The idea here is to have the spikes impale the ship, and kill input so you feel helplessly stuck as your ship carcass gets smashed by spikes.
I've re-purposed the light shining down to show when the ship is alive/dead, for debugging. Green light = alive, red light = dead :)
To polish this up the physics shape on the spikes will need to be adjusted (from a sphere to a box), and the ship should be attached by projecting the ship position onto the spike plane, and raising it off by the ship radius. Then, tighten the physics geometry so there isn't a noticeable 'pop' when the transition happens. Or, even better, kill the input (so the ship is 'dead'), and don't do a rigid attachment until the spikes 'move into' the ship and the ship is a certain distance from the spike plane. This latter solution will look best - you get killed, which freezes you in place, then I can have the spikes look like they impale you until the ship reaches the bottom of the spikes, then you get stuck to it.
Additionally, the far extent of the spikes should be limited to the ship's radius so you don't intersect the opposing wall. To polish this up, keep the current behavior (so it penetrates the wall as it does now) - *unless* there is a ship attached, in which case don't penetrate the wall all the way. That will make it look super slick.
Also, I think the camera will need a little bit of jiggle in this state - being attached to the spikes gives a pretty jarring camera movement - if the camera is a little looser/springy, that can make it feel better.
I'm hesitating to show it to you without the slickness implemented, but in the interest of fully documenting my progress and possibly teaching someone out there something, I'll show what it looks like right now (horrible) so maybe you can appreciate the work game devs do to make games awesome :)
Tuesday, January 8, 2013
Day 9 - break
No progress today, took a break from all the coding :)
Next to do is to make stompy lethal, so attaching some physics to him that can kill the player.
Subscribe to:
Posts (Atom)