I've been neglecting my blog for too long - we have big news all around. Our game was picked up by the University for showing at GDC so 7 members of Tripleslash (including myself) attended. The experience was amazing - it was great to have so many geeks under one roof! Nintendo's news of Web Framework was especially interesting for me. They seem to be posed to take Microsoft's place as the most indie-friendly of the three at the moment depending on what Microsoft and Sony may have up their sleeves.
The upcoming Havok Vision also looks REALLY cool. They will be fighting against the already entrenched Unity engine for market share but there are definitely many things going for them. Their state machine based animation system is fantastic and they obviously have a very high-end physics engine. Free deployment for mobile platforms also seems like a great move.
In GDC Play there were a few highlights for me. 'Forced' was a very fun 4-player coop game, basically Gauntlet meets Magicka. 'Super Motherload' looks like ridiculous party fun but I worry about being able to find 3 other people to play with. While it works with fewer players it would probably lose a lot of its charm. Even so, I'll be watching this one! Hawken looked amazing - that's probably why it was being used at the Oculus Rift booth.
Our game had a very positive reception from everybody who stopped by the booth. It seemed like somebody was constantly playing Magnetic By Nature at the University of Utah booth and I saw a number of people coming back time and again to see how far they could make it. We will be cutting all of the rougher levels and likely combining all of the really difficult levels into a 'Bonus' section.
Thanks to the University of Utah, the Utah Chamber of Commerce and everyone who made our trip possible.
Sunday, March 31, 2013
Sunday, February 10, 2013
Prefabs
This has been an incredible week for Magnetic By Nature. On Thursday we brought in a bunch of students and faculty to play through our games and provide feedback. Based on their feedback we have revamped the control scheme, rethought the way we handle the robot head, and made several changes that take our game to the next level. DING!
On Friday I interviewed with a great local company - SmartBomb Interactive. They're probably best known for their incredibly successful browser-based kid-friendly MMO Animal Jam. They've got another upcoming title for a more mature audience - Sky Legends. The developers there really seem to know their stuff - here's hoping I made a good enough impression to warrant a second interview!
Over the weekend I've been working on some much-needed enhancements to the way in which we handle 'special objects'. Our editor has always supported grabbing an item from a toolbox and dropping it into the world, allowing us to easily bundle together functionality for spikes, magnets and so forth. Once our team got into really building levels a major flaw with this philosophy reared it's ugly head - the difficulty of applying a change globally.
For instance, when we needed to tweak the size of our magnets to accommodate some changes to the art work we had to use some regex tricks, manually editing XML, and in the process we broke some things. I have taken a page out of Unity's book now by linking the objects back to the original template/prefab. In other words, we can make a change in one place and have it applied globally.
A nice bonus was that this enables us to reuse a single instance of each component on ALL instances of that object type, saving some memory. The new system is versatile enough to allow overrides on a level-by-level basis, too.
On Friday I interviewed with a great local company - SmartBomb Interactive. They're probably best known for their incredibly successful browser-based kid-friendly MMO Animal Jam. They've got another upcoming title for a more mature audience - Sky Legends. The developers there really seem to know their stuff - here's hoping I made a good enough impression to warrant a second interview!
Over the weekend I've been working on some much-needed enhancements to the way in which we handle 'special objects'. Our editor has always supported grabbing an item from a toolbox and dropping it into the world, allowing us to easily bundle together functionality for spikes, magnets and so forth. Once our team got into really building levels a major flaw with this philosophy reared it's ugly head - the difficulty of applying a change globally.
For instance, when we needed to tweak the size of our magnets to accommodate some changes to the art work we had to use some regex tricks, manually editing XML, and in the process we broke some things. I have taken a page out of Unity's book now by linking the objects back to the original template/prefab. In other words, we can make a change in one place and have it applied globally.
A nice bonus was that this enables us to reuse a single instance of each component on ALL instances of that object type, saving some memory. The new system is versatile enough to allow overrides on a level-by-level basis, too.
Thursday, January 31, 2013
Hybrid 2d/3d
All of this time we have been referring to our game by it's codename - Attraction. I am now pleased to announce the official title of the game - Magnetic by Nature! Not only does this get around an unfortunate amount of SSO issues (Google is convinced anybody googling 'attraction' wants dating sites, for some reason) - it's also a nod to the story behind the game. The robot is thrust into this dead world with only small bits of life. These act as checkpoints and guide the player through the game.
I have also been busy dealing with an unexpected issue. We originally settled on spritesheet animations with the expectation that they would be smaller, more expressive, and simpler to deal with. After looking at the HUGE number of animations that would be needed for the main player alone it became apparent that we needed to make a change.
Our choices were to either switch to keyframe-based sprite animation (found in most flash games) or render the main character in 3d. Because our artists are all more familiar with Maya than Flash we chose the latter. For the past several weeks I've been struggling through the content pipeline, differences in how XNA renders sprites and models, and animation issues.
One of the first problems I ran into is that the FBX importer is frustratingly undocumented. Models must have a single root joint with all other joints under that hierarchy. This hierarchy cannot include any groups (or the import fails). For about a week I worked with Kyle, our main rigger & 3d modeler, to get all of the issues fixed and the model importing & rendering properly.
Once that was done I had to figure out a way to animate it. While the FBX format supports exporting multiple animations in a single file neither Maya nor XNA seems to like working with the result. To work around this I modified the Skinned Model Extensions sample to merge animations from a subfolder as part of the pipeline. For instance, I can place a 'player.fbx' file in my Models folder, then place all of the animations (player_walk.fbx, player_jump.fbx, etc) in a subfolder named player.
Unfortunately in the process I discovered an issue with the sample code. If you set the scale of your model to anything other than 1 the animations become distorted. What is probably happening is that the mesh is being scaled by the keyframes are not - or maybe they're being scaled improperly. To work around this I either have the artists scale the model before generating the FBX or I set a constant scale within our engine.
I hope to post my modifications to the pipeline as a github project for future projects that have similar needs. If you have any suggestions or requests for additional features feel free to post them in the comments!
I have also been busy dealing with an unexpected issue. We originally settled on spritesheet animations with the expectation that they would be smaller, more expressive, and simpler to deal with. After looking at the HUGE number of animations that would be needed for the main player alone it became apparent that we needed to make a change.
Our choices were to either switch to keyframe-based sprite animation (found in most flash games) or render the main character in 3d. Because our artists are all more familiar with Maya than Flash we chose the latter. For the past several weeks I've been struggling through the content pipeline, differences in how XNA renders sprites and models, and animation issues.
One of the first problems I ran into is that the FBX importer is frustratingly undocumented. Models must have a single root joint with all other joints under that hierarchy. This hierarchy cannot include any groups (or the import fails). For about a week I worked with Kyle, our main rigger & 3d modeler, to get all of the issues fixed and the model importing & rendering properly.
Once that was done I had to figure out a way to animate it. While the FBX format supports exporting multiple animations in a single file neither Maya nor XNA seems to like working with the result. To work around this I modified the Skinned Model Extensions sample to merge animations from a subfolder as part of the pipeline. For instance, I can place a 'player.fbx' file in my Models folder, then place all of the animations (player_walk.fbx, player_jump.fbx, etc) in a subfolder named player.
Unfortunately in the process I discovered an issue with the sample code. If you set the scale of your model to anything other than 1 the animations become distorted. What is probably happening is that the mesh is being scaled by the keyframes are not - or maybe they're being scaled improperly. To work around this I either have the artists scale the model before generating the FBX or I set a constant scale within our engine.
I hope to post my modifications to the pipeline as a github project for future projects that have similar needs. If you have any suggestions or requests for additional features feel free to post them in the comments!
Friday, January 4, 2013
New Beginnings
Happy New Year, everyone! The break has been incredibly restful (and productive) for me. Performance was a big focus I had - between the various optimizations I was able to put in place, the game is now running flawlessly on the XBox 360. HUZZAH!
I'm looking forward to this next semester - I can see great things in our future! Watch this space for more details!
I'm looking forward to this next semester - I can see great things in our future! Watch this space for more details!
Friday, December 7, 2012
Postmortem
Time for a deep breath, a short respite from slave driver professors (no offense :) and a look back on the past semester. It's hard to believe that about 9 weeks ago Tripleslash was formed and we started work on Attraction. In that time we have taken a fun concept from prototype to a very solid alpha. Kudos, all around!
One of the best decisions (in my opinion) was to go with an Entity/Component system to handle the game logic. Because of this early choice we have been able to build a wide variety of objects in the game from less than a dozen separate components. Because it was my idea I was tasked with converting the early prototype into an Entity system and given an ambitious time frame - about a week - in which to have it done.
Since that time my team has done an incredible job of expanding on that original work to provide a fun game experience. I have been focusing my efforts on building an AMAZING level editor that will let us iterate on level, puzzle, and art concepts quickly. Early functionality was fairly basic - there was a lot of digging deep into object properties in order to make fairly basic changes.
Once the basic functionality was there I set to work on making everything work WELL. The past few weeks I have documented some specifics of how I've done this - standardizing the keyboard interface, using a brush & paint type system to 'paint' in the contents of the level and using the FileSystemWatcher class in Windows to reload files when needed.
I recently made it possible to easily add new items to the editor toolbox by using the editor itself. You can get an object set up just how you like it, then save it into the toolbox for future reuse. All of this means that we can fire up the editor to build a puzzle from mock-up art, hit F5 to try it in-game, tweak some settings and repeat very easily. Once we have the puzzle functioning well we can hand it off to the artists.
They can load up the editor to see it with the mocked up artwork, edit the textures in Photoshop and switch over to see the changes reflected immediately in the editor (which uses the same rendering system as the actual game). Once they think everything looks good they can hit F5 to try it out in the game to spot any graphical glitches, seams, or odd parallax behavior.
Where do we go from here? Well - I would really like to make editing even more intuitive and powerful. What if, for instance, we had a Boss with two arms that he uses, similar to the player. In order to beat him, the player has to throw something at him (so that he magnetizes his arm) then magnetically rip his arm off. Everything needed to do this (other than a few small bits of NPC behavior) are already written.
What if we had entire magnetic walls that had to be manipulated in a certain order in order to make it through a maze?
How far can we push the fun 'faith leap' mechanic? Can we build an entire level centered around pushing yourself down ramps, across chasms, etc?
Flying spikes. 'Nuff said.
There is SO much potential for future puzzles - I am really incredibly excited to try some of the ideas out.
One of the best decisions (in my opinion) was to go with an Entity/Component system to handle the game logic. Because of this early choice we have been able to build a wide variety of objects in the game from less than a dozen separate components. Because it was my idea I was tasked with converting the early prototype into an Entity system and given an ambitious time frame - about a week - in which to have it done.
Since that time my team has done an incredible job of expanding on that original work to provide a fun game experience. I have been focusing my efforts on building an AMAZING level editor that will let us iterate on level, puzzle, and art concepts quickly. Early functionality was fairly basic - there was a lot of digging deep into object properties in order to make fairly basic changes.
Once the basic functionality was there I set to work on making everything work WELL. The past few weeks I have documented some specifics of how I've done this - standardizing the keyboard interface, using a brush & paint type system to 'paint' in the contents of the level and using the FileSystemWatcher class in Windows to reload files when needed.
I recently made it possible to easily add new items to the editor toolbox by using the editor itself. You can get an object set up just how you like it, then save it into the toolbox for future reuse. All of this means that we can fire up the editor to build a puzzle from mock-up art, hit F5 to try it in-game, tweak some settings and repeat very easily. Once we have the puzzle functioning well we can hand it off to the artists.
They can load up the editor to see it with the mocked up artwork, edit the textures in Photoshop and switch over to see the changes reflected immediately in the editor (which uses the same rendering system as the actual game). Once they think everything looks good they can hit F5 to try it out in the game to spot any graphical glitches, seams, or odd parallax behavior.
Where do we go from here? Well - I would really like to make editing even more intuitive and powerful. What if, for instance, we had a Boss with two arms that he uses, similar to the player. In order to beat him, the player has to throw something at him (so that he magnetizes his arm) then magnetically rip his arm off. Everything needed to do this (other than a few small bits of NPC behavior) are already written.
What if we had entire magnetic walls that had to be manipulated in a certain order in order to make it through a maze?
How far can we push the fun 'faith leap' mechanic? Can we build an entire level centered around pushing yourself down ramps, across chasms, etc?
Flying spikes. 'Nuff said.
There is SO much potential for future puzzles - I am really incredibly excited to try some of the ideas out.
Saturday, November 24, 2012
Thanksgiving
To jump on the seasonal bandwagon, I am thankful for an awesome team that can work together to accomplish amazing things. Over the course of the past few months we have gone from a fun conceptual prototype into a nearly feature-complete alpha, and I've retained (most of) my sanity in the process!
Now, down to business. Last time I talked about how UI conventions can be used to your benefit. This time I would like to discuss how NOT to build an editor. These are the hard-learned lessons I have picked up in my brief experience. I would love to hear from any readers (anybody out there?) with other suggestions, since there's an increasing likelihood that tools and infrastructure will end up being my focus.
Games, and editors in particular, require tender loving care. When you set out to write your first few lines of code you will be tempted to just throw things together quickly - after all, Agile is supposed to be all about diving straight into the code, right? WRONG! Agile is about quickly adding on features, iterating on a design, and integrating feedback as quickly as possible. If you screw up the overall structure of your editor in the first sprint it will become increasingly difficult to accomplish what you need to.
For example, take a relatively simple user story: A user selects an object and edits the properties of any attached components. Reading this you decide that in the MouseClick event of your form you will set a SelectedItem property somewhere and update the UI. Fantastic! You now have a functional editor!
You start working on the next item: A user updates an object's position by dragging it. Hmm - okay, so we need to keep track of where the user first clicked, then in the MouseMove event we check for a drag and handle that. Still not too bad, and we're still in Sprint 1!
Work progresses like this for a few weeks - new functionality usually requires a few extra variables and some extra logic. Eventually you end up with the MouseDown, MouseUp, MouseClick and MouseMove events being full of duplicated logic that seems to require an increasing amount of maintenance. Where did we go wrong? Well - to answer that let's look at how we COULD have handled these requirements.
What if we thought of our user interactions as a finite state machine (FSM)? Under this model, we just have to define the state changes. Well-written user stories often lend themselves well to a state machine. Given the above two, for instance, we can say that the default state is IDLE. If the user clicks on an object we know that they want to select it. We also know that, after dragging, an object should be selected. Putting these two together we can say that when the mouse button is pressed and the cursor is over an object, we select that object and change the state to DRAGGING.
One of the big advantages I have found in thinking of a UI as a FSM is that it gives you an automatic framework to consider what states there are, under what conditions one state can change to another, and it basically forces you to explicitly name the states. You also get access to all of the tools built around designing state machines - diagrams, simplification and a common language to speak with any engineers you might work with.
This is by no means a new concept - I'm sure this has been discovered and rediscovered time and again by upstart designers much like myself. Then again, if you come from an object-oriented background or you've never worked directly with state machines it probably wouldn't be your first inclination. Maybe you prefer to have a series of loosely coupled classes using databinding and viewmodels to represent granular data of what is happening in your UI. Even then, I feel it is helpful sometimes to take a step back and realize that what you're really doing is building the same state machine, just at a different level of granularity and abstraction.
Now, down to business. Last time I talked about how UI conventions can be used to your benefit. This time I would like to discuss how NOT to build an editor. These are the hard-learned lessons I have picked up in my brief experience. I would love to hear from any readers (anybody out there?) with other suggestions, since there's an increasing likelihood that tools and infrastructure will end up being my focus.
Games, and editors in particular, require tender loving care. When you set out to write your first few lines of code you will be tempted to just throw things together quickly - after all, Agile is supposed to be all about diving straight into the code, right? WRONG! Agile is about quickly adding on features, iterating on a design, and integrating feedback as quickly as possible. If you screw up the overall structure of your editor in the first sprint it will become increasingly difficult to accomplish what you need to.
For example, take a relatively simple user story: A user selects an object and edits the properties of any attached components. Reading this you decide that in the MouseClick event of your form you will set a SelectedItem property somewhere and update the UI. Fantastic! You now have a functional editor!
You start working on the next item: A user updates an object's position by dragging it. Hmm - okay, so we need to keep track of where the user first clicked, then in the MouseMove event we check for a drag and handle that. Still not too bad, and we're still in Sprint 1!
Work progresses like this for a few weeks - new functionality usually requires a few extra variables and some extra logic. Eventually you end up with the MouseDown, MouseUp, MouseClick and MouseMove events being full of duplicated logic that seems to require an increasing amount of maintenance. Where did we go wrong? Well - to answer that let's look at how we COULD have handled these requirements.
What if we thought of our user interactions as a finite state machine (FSM)? Under this model, we just have to define the state changes. Well-written user stories often lend themselves well to a state machine. Given the above two, for instance, we can say that the default state is IDLE. If the user clicks on an object we know that they want to select it. We also know that, after dragging, an object should be selected. Putting these two together we can say that when the mouse button is pressed and the cursor is over an object, we select that object and change the state to DRAGGING.
One of the big advantages I have found in thinking of a UI as a FSM is that it gives you an automatic framework to consider what states there are, under what conditions one state can change to another, and it basically forces you to explicitly name the states. You also get access to all of the tools built around designing state machines - diagrams, simplification and a common language to speak with any engineers you might work with.
This is by no means a new concept - I'm sure this has been discovered and rediscovered time and again by upstart designers much like myself. Then again, if you come from an object-oriented background or you've never worked directly with state machines it probably wouldn't be your first inclination. Maybe you prefer to have a series of loosely coupled classes using databinding and viewmodels to represent granular data of what is happening in your UI. Even then, I feel it is helpful sometimes to take a step back and realize that what you're really doing is building the same state machine, just at a different level of granularity and abstraction.
Tuesday, November 13, 2012
Some notes on UI design
The editor continues to evolve. After sitting down with Becky (the Art Lead) I was able to implement some valuable feedback into the editor. I thought that some of the feedback might be useful for others who may find themselves building an editor in the future.
Toolboxes are your friends!
Coming from a development background I originally envisioned level design as involving a lot of manually tweaking objects, maybe adding them to a toolbox, then repeating over and over again. I am accustomed to manually tweaking the settings on a blank object then copy/pasting it where needed, so this seemed like a perfectly reasonable work flow. After turning the tool over to an artist I quickly saw the problem with this - as an artist, they simply want to pick a brush and paint with it. Photoshop, Inkscape, Adobe Illustrator - pretty much every artist tool known to man - focuses on placing a large palette within easy reach. Do yourself (and your artists) a favor and follow the UI conventions already established.
To deal with this feedback I instead focused on automatically building palettes that contain every possible prop they might want to drop into the game. I have the luxury of working with experienced artists who are very understanding of the realities of development. Even so, it's better to make your tool smart than to require that your users are.
Borrow conventions from other great tools
This one goes with the note on toolboxes above. When I use an IDE, I tend to expect some sort of code completion functionality. I find myself pressing Ctrl+E,D in an attempt to clean up my code. If I can't remember the complete name of a method, I want to type a dot and have the IDE tell me about what's available. Regardless of personal IDE preference, my point is that interactions with tools are learned. Don't fight this - use it to your ADVANTAGE!
If your editor needs to be able to place straight lines, use shift+click to draw a line from the last point. Use the mouse wheel to pan up/down and ctrl+wheel to zoom. If you support panning in your editor, use space+drag as a shortcut for pan. In short, find the shortcuts that your customer is used to and reuse those.
Who needs Undo/Redo anyway?
When I first sat down with Becky I was feeling pretty good about the state of the editor. Shortly after addressing the above issues she started to paint terrain. She was dragging new terrain, erasing a few pieces and having a grand old time. Then she made a mistake and asked why she couldn't simply undo. Hmm - good point! One mark of a good editor (or software of almost any kind) is that you should never feel trapped. If you make a mistake, you should be able to fix it. I have decided that when I am manipulating the level in ANY way, it is best to use whatever Undo/Redo solution you have chosen to implement. Better to have too much undo history than too little!
Timely preview is irreplaceable
So you've built yourself a WYSIWYG editor that renders content exactly as it will be seen in game. Everything is working flawlessly and using your editor for the first time feels like trying on an old pair of shoes. Fantastic! Now - how about taking that level for a test drive? No matter how good your level design team is they'll inevitably need to make changes. At a minimum your editor should allow the user to immediately (and at any time) load the currently open level into your game. Even better, if you can update the level design in the editor and have the changes synced to your game window you'll have a team of VERY happy level designers on your hands!
For our purposes I suspect simply having an easy preview will suffice, but I would love to explore how some of the more advanced options might work in the future.
Give them what they want
Everything above can be summarized here. My mission statement for this project is to make sure we never have to say no to a puzzle/level concept because of inefficient or insufficient tools. For indie games especially a strong central concept polished and iterated to perfection is FAR superior to a derivative or generic concept reskinned. In future posts I will address a few of these concepts in closer detail with code examples where useful. For now, though? Back to the code!
Subscribe to:
Posts (Atom)