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.
Friday, December 7, 2012
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!
Saturday, November 10, 2012
Editor is ALPHA READY!
YES! So, with a coding frenzy and some help from my fellow coders-in-arms Brendan, David, and Paige the editor is now Alpha-Ready! Dave had a great thought of how to handle layers in the game, which also lended itself to a handy implementation in the editor. He also got the Magic Ground Finder (codename: MGF) working, which picks out what sort of tile you have placed where and builds an optimized hull from that.
I modified the editor to use the naming convention to automatically find all tile sheets and make them available in the editor. I'm using a sort of modified MVVM model to handle going from UI to actual data and it seems to work remarkably well. The ViewModel for the editor, for instance, exposes a 'SelectedBrush' object. This can be set to anything. When the user clicks within the actual editor window a small chunk of code decides what to do with the current brush (if it's a sprite, set the cell in the CurrentLayer; if it's a template, build a new object to place in the level).
This also made it very easy to add extra items that can be added such as the player spawn point or your trusty robot head sidekick. It also provides an easy way to handle future expansion - WIN!
I feel pretty comfortable handing the editor to our artists to start trying. I'm sure they'll find plenty of improvements they would like to make, and that's a good thing! I can't wait to see how this tool evolves over the course of the next few months.
I modified the editor to use the naming convention to automatically find all tile sheets and make them available in the editor. I'm using a sort of modified MVVM model to handle going from UI to actual data and it seems to work remarkably well. The ViewModel for the editor, for instance, exposes a 'SelectedBrush' object. This can be set to anything. When the user clicks within the actual editor window a small chunk of code decides what to do with the current brush (if it's a sprite, set the cell in the CurrentLayer; if it's a template, build a new object to place in the level).
This also made it very easy to add extra items that can be added such as the player spawn point or your trusty robot head sidekick. It also provides an easy way to handle future expansion - WIN!
I feel pretty comfortable handing the editor to our artists to start trying. I'm sure they'll find plenty of improvements they would like to make, and that's a good thing! I can't wait to see how this tool evolves over the course of the next few months.
Tuesday, October 30, 2012
More Editor
This week was again quite productive. I took the level editor from a rough concept to a fully functional alpha. Today I showed Becky the progress and she had some excellent feedback - she wants to be able to 'paint' a texture over a large area and have the editor automatically infer the ground mesh from the tiles placed.
This means I'll need some way to take each individual tile's bounding box (which might be square, rectangular, triangular or some other shape) and merge all of the adjacent vertices. I'm thinking I may use the algorithm here to handle simplifying all of the individual squares into larger sections.
Other small tasks for this week are cut, copy, paste, and duplicate support (to easily make many copies of a single object) and a toolbox (which will be needed for the 'paint' support above). I believe layers are something we'll need to handle in a future sprint.
This means I'll need some way to take each individual tile's bounding box (which might be square, rectangular, triangular or some other shape) and merge all of the adjacent vertices. I'm thinking I may use the algorithm here to handle simplifying all of the individual squares into larger sections.
Other small tasks for this week are cut, copy, paste, and duplicate support (to easily make many copies of a single object) and a toolbox (which will be needed for the 'paint' support above). I believe layers are something we'll need to handle in a future sprint.
Friday, October 26, 2012
Making Progress
The editor is progressing nicely! I have managed to get about 95% of the base functionality in thus far and what it does works pretty darn well. Hooking up loading and saving was a piece of cake thanks to Dave's work on the (de)serization code. Next up is adding horizontal and vertical scrollbars to move around the level, building the Sprite Manager control (would be nice to be able to add new sprites and change existing ones) and fixing the remaining camera issues.
Tuesday, October 23, 2012
Level Editor
Over the weekend I put together a basic level editor to help churn out content for Attraction. It's a Windows Forms app that uses the XNA rendering panel sample (http://xbox.create.msdn.com/en-US/education/catalog/sample/winforms_series_1) for the live level preview. The UI absolutely sucks currently, but it is functionally near-complete. I'm running into some frustrations dealing with PropertyGrid - I miss the DataTemplate functionality from WPF! I suppose I COULD switch to a WPF app but I'm not sure if it would be worth what I would gain.
Over the next week my job is to get the editor to the point that it is usable by the artists on our team. This means a LOT of polish on my part but I'm sure I can get it done. The other engineers are doing their part to get the rest of the game in order and the artists are slaving away on design - I feel lucky to work with such an incredible group of talent.
Over the next week my job is to get the editor to the point that it is usable by the artists on our team. This means a LOT of polish on my part but I'm sure I can get it done. The other engineers are doing their part to get the rest of the game in order and the artists are slaving away on design - I feel lucky to work with such an incredible group of talent.
Saturday, October 20, 2012
A basic editor
Huzzah! I have a (VERY) basic level editor put together using WinForms and the XNA+WinForms sample code. It supports clicking to select and drag-drop operations within the editor pane on the right. Next up is adding a context menu or other method of managing what components are added to a given entity. I'm considering a PropertyGrid - it would give a relatively straightforward way to modify all of the attributes of the existing components and should be easily extensible.
My first priority after getting the basic editor working is a ground editor. We've decided to store the collision box for the ground separately, so I need to have support to somehow edit this collision mesh. Down the road I also want support for templates, a comprehensive Redo/Undo system (which should be one of the easier things to build), changing grid attributes (on/off, snap on/off, color, spacing, etc).
Thursday, October 18, 2012
Back from the Break
That was a refreshing fall break! Over the past week I re-factored the existing code into the Artemis entity system (which I'm still loving). It was fun to see all of the pieces coming together! I was able to take the pre-existing project (with about a dozen classes) and distill it down to 5 systems and 7 components. That's a significant improvement! Plus, we can now mix/match those 7 components into (potentially) 128 distinct types of objects without involving the coders. I'm sure we'll add more systems and components as we go (fixed magnets are one thing currently missing) but this is COOL!
On Tuesday I committed the code to our git repository and the other engineers have taken it and run with it. I understand that there are a few cool Components in the works. Next up - I need to get moving on the level editor. My first attempt tried to open a Windows Form from the XNA app to add, alter, remove etc entities at run-time. I found that XNA prevents the focus events from firing properly which interferes with a number of controls (notably PropertyGrid). My next attempt will use a Windows Forms application with an XNA rendering window (as described in most tutorials on the subject).
On Tuesday I committed the code to our git repository and the other engineers have taken it and run with it. I understand that there are a few cool Components in the works. Next up - I need to get moving on the level editor. My first attempt tried to open a Windows Form from the XNA app to add, alter, remove etc entities at run-time. I found that XNA prevents the focus events from firing properly which interferes with a number of controls (notably PropertyGrid). My next attempt will use a Windows Forms application with an XNA rendering window (as described in most tutorials on the subject).
Sunday, October 7, 2012
And then, there were 3
The final 3 have been decided! Time Jump didn't quite make the cut - the panel had some good feedback for us. They felt that the concept would require twice as much art work, level design, and iteration due to the dual nature. They also felt that we didn't differentiate the alternate time - why not just do the same thing in a single time stream? They didn't feel we adequately addressed how the past could affect the future.
I can't be too sad/upset about not being chosen though, because instead I get to work on another awesome game! Attraction is a game about a robot (seriously, what's up with robots?) with a magnetic arm. You can pull toward or push away from magnets in the environment. This simple mechanic can be used to build a wide variety of situations - I really am excited for the possibilities! The game in prototype form is already fun to play through and you already get a feel for where the game might eventually go.
One common piece of feedback from the panel was that none of our concepts felt Indie Enough. Everything seemed fairly mainstream, and there was no mechanic, aesthetic or theme that was far out enough to be indie. We're meeting today to discuss the overall direction for the game. With such an awesome team I'm sure we can come up with some ways to make this work.
I've already volunteered to focus on the tools for the game - I really find the process of acting as a facilitator incredibly gratifying. It's great to be able to build a tool that multiplies the effectiveness of everybody else on the team when it comes to iterating and trying new/different designs.
I can't be too sad/upset about not being chosen though, because instead I get to work on another awesome game! Attraction is a game about a robot (seriously, what's up with robots?) with a magnetic arm. You can pull toward or push away from magnets in the environment. This simple mechanic can be used to build a wide variety of situations - I really am excited for the possibilities! The game in prototype form is already fun to play through and you already get a feel for where the game might eventually go.
One common piece of feedback from the panel was that none of our concepts felt Indie Enough. Everything seemed fairly mainstream, and there was no mechanic, aesthetic or theme that was far out enough to be indie. We're meeting today to discuss the overall direction for the game. With such an awesome team I'm sure we can come up with some ways to make this work.
I've already volunteered to focus on the tools for the game - I really find the process of acting as a facilitator incredibly gratifying. It's great to be able to build a tool that multiplies the effectiveness of everybody else on the team when it comes to iterating and trying new/different designs.
Tuesday, October 2, 2012
Final Pitch
Wow - that was a surprisingly frightening experience! You put a month of your life into a game and it all boils down to a 7-minute pitch. How did we do? Pretty damned well, I think. For the first time since the semester started I don't think I'll be going home and writing code. We have to turn in our 4 top pitches tonight. I will have to really think about this - all 8 ideas were solid, and all had a lot going for them.
Sunday, September 23, 2012
Crunch Weekend
This has been a CRAZY weekend! Built a Camera class to allow panning around the level, got the grappling hook working (although there's still some odd Box2D/Farseer related behavior), got some of the control systems working better, hooked up the camera so that it follows the player around the level, fixed some of the level loading code, and got the grappling hook 'rope' rendering. Oh, and I hand-crafted the XML for 2 separate level concepts since we don't have a level editor. WHEW!
I don't think I'll worry about building out any code for 'death' since it's not something we'll be featuring in our trailer - let's leave that for after the prototype. Textures are what is lovingly referred to as 'programmer art'. Becky and Diana are doing their artist magic and coming up with concept art this weekend. I've decided it must be magic, because nothing else could explain the transformation from something as vague as 'a time traveling robot' into the sort of awesomeness these two produce.
Now I think it's time to sit down and play some games for an hour or so to break out of the coder's block (it's a real thing - I swear!) I'm currently in.
I don't think I'll worry about building out any code for 'death' since it's not something we'll be featuring in our trailer - let's leave that for after the prototype. Textures are what is lovingly referred to as 'programmer art'. Becky and Diana are doing their artist magic and coming up with concept art this weekend. I've decided it must be magic, because nothing else could explain the transformation from something as vague as 'a time traveling robot' into the sort of awesomeness these two produce.
Now I think it's time to sit down and play some games for an hour or so to break out of the coder's block (it's a real thing - I swear!) I'm currently in.
Friday, September 21, 2012
Grappling Hook Woes
Fairly early on we struck on the idea that, as an elderly robot, our protagonist might have developed a grappling hook to help get around, pick up things, and in general continue to be useful. This sounded like a great idea - who doesn't love a grappling hook?
Then we (Ramnage and I) started looking at how, exactly, you build a grappling hook in code. As it turns out, it's not easy. You have to detect where the hook was fired. You've got to potentially do some auto-aiming if the player can only grapple certain areas. You have to take care of swinging, retracting, extending, and slamming into walls. Grappling hooks, like all worthwhile things, are TOUGH!
We decided to divide and conquer - Christian will take care of the grappling hook and I'll work on finishing everything else. We have to get everything working together by Tuesday to allow for 2 days of insane iteration so that we can cut together a trailer for our presentation on October 2nd. It's going to be a busy week, but I'm excited to show off what we've gotten done in such a short time!
Then we (Ramnage and I) started looking at how, exactly, you build a grappling hook in code. As it turns out, it's not easy. You have to detect where the hook was fired. You've got to potentially do some auto-aiming if the player can only grapple certain areas. You have to take care of swinging, retracting, extending, and slamming into walls. Grappling hooks, like all worthwhile things, are TOUGH!
We decided to divide and conquer - Christian will take care of the grappling hook and I'll work on finishing everything else. We have to get everything working together by Tuesday to allow for 2 days of insane iteration so that we can cut together a trailer for our presentation on October 2nd. It's going to be a busy week, but I'm excited to show off what we've gotten done in such a short time!
Sunday, September 16, 2012
Progress
I think everybody in the group agreed that the parallel universe idea was interesting, but didn't really fit with the overall feel we were going for. I'd love to go back and revisit this concept sometime - I think it has possibilities, just not in this context.
I've started integrating the code between myself and Christian/Ramnage (the other programmer). I liked the feel of the jump he built - it basically makes the player jump upward at a fixed speed, then gravity abruptly kicks back in at the peak. There was another concept for a more jetpack-like jump, but I think his first concept felt better. He's working on the grappling hook system now - I can't wait to see what he comes up with there!
I got level loading from XML tossed together. It works reasonably well, and would enable us to build out a level editor without TOO much effort. I need to look into how we might consolidate the sprite and physics logic in these - right now, each block of the level redefines the graphic to display, the physics model (in its entirety) and everything else. It would be much more convenient to build and edit levels if template blocks could be defined, then referenced repeatedly. This complicates saving/loading but improves flexibility. I can also see that we'll need to be able to rotate blocks at some point. This might be able to wait until after our prototype.
Still having a bit of trouble trying to find puzzle scenarios that require either the old or young robot specifically. Maybe the old robot has the grappling hook and can swing from it, but when detaching he doesn't get an extra boost - his momentum is just conserved. Then again, maybe it would be cool if we did a portal-style trial mode where the player has to complete each level using ONLY the old or young version? Would be REALLY cool if we could implement achievements...
Monday, September 10, 2012
Rough Prototype, Ahoy!
Progress! I have parallel universes rendering, simulating physics, and accepting input. is, of course, INCREDIBLY rough. Jumping is a hack. The 'levels' are a hack - everything is in code. The physics simulation of movement is a hack - directly applying an impulse to the player. The physics body of the player is even a hack - he's a square. Even so, I can't help but feel an incredible sense of accomplishment for what I've gotten done this weekend between homework for other courses, working, and playing a lot of games.
If the parallel universe concept doesn't pan out it's easy enough to strip that part out of the code - I remove a couple of Systems (which are just duplicated for the two worlds) and it's done. I can't say this enough - I LOVE ENTITY/COMPONENT SYSTEMS!
Saturday, September 8, 2012
Finding the fun
I ended up on a project to build a game featuring a time traveling robot. We've had some trouble 'finding the fun' in the concept - puzzle design ca be tough in 2 dimensions, let alone multi-layered 2D! We're all spending the weekend playing games, coming up with ideas on how to make the game fun.
One idea that sounds intriguing is a platformer version of double maze. Maybe instead of traveling through time, the robot is stuck in multiple times/dimensions simultaneously. Everything he does in one is reflected in the other. In each level the goal is to reach the exit in both dimensions at the same time - you have to simultaneously play two platformer games, basically. I can see a lot of fun puzzles you could do with this basic mechanic, from the really easy to the incredibly challenging. You could also mix things up in some levels - maybe some dimensions/times are backwards, so left is right and right is left. Maybe have some levels with other control or environment switches - no jumping, in one dimension you can only move left - that sort of thing.
I've got a REALLY basic engine thrown together, borrowing from some recent work I did to build an Entity System from scratch. Thank goodness I don't throw away code! I'm having some trouble integrating the Farseer Physics engine - I think it might stem from unit differences between the two. I hope to have a REALLY rough prototype together by Tuesday to play with my group to try out the concept.
UPDATE: Success! Farseer is now behaving - it was, indeed, an issue with how I was converting between screen and world coordinates. Next up: how to build two worlds?
I'm continuing the hunt for other concepts in case this one doesn't pan out. Some inspiration:
Layer Maze - http://pipkingames.com/flash/13592/
A maze in a 3d cube, where you can see only a single layer at a time
Neon Layers - http://armorgames.com/play/1778/neon-layers
Switch between 3 sets of neon lights to reach the exit
UPDATE: Success! Farseer is now behaving - it was, indeed, an issue with how I was converting between screen and world coordinates. Next up: how to build two worlds?
I'm continuing the hunt for other concepts in case this one doesn't pan out. Some inspiration:
Layer Maze - http://pipkingames.com/flash/13592/
A maze in a 3d cube, where you can see only a single layer at a time
Neon Layers - http://armorgames.com/play/1778/neon-layers
Switch between 3 sets of neon lights to reach the exit
Tuesday, September 4, 2012
Of Time Traveling Robots
Well, my pitch didn't make the cut. I'm okay with that though, because I'm going to be working on a game that features a time traveling robot! Sweet! Right now we're considering some strong influences of Braid, maybe a smidge of Quantum Conundrum and just a pinch of Chronotron.
We've got a skilled team of 4 - 2 code monkeys and 2 artists. One of the artists has already shipped a title (sweet) which was fairly successful on XBLIG (even better). We only have 3-4 weeks to throw together a prototype to pitch to an industry panel. I can see many sleep-deprived days ahead of me.
We've got a skilled team of 4 - 2 code monkeys and 2 artists. One of the artists has already shipped a title (sweet) which was fairly successful on XBLIG (even better). We only have 3-4 weeks to throw together a prototype to pitch to an industry panel. I can see many sleep-deprived days ahead of me.
Monday, August 27, 2012
Pitch Prep
Tomorrow is pitch day, and I'm getting pretty pumped for it! I think I've got a solid concept but who knows what the other students have planned? Somewhere in Utah, right now, there may be somebody sketching out the next Minecraft. You just never know!
It's going to be another week of no programming work on the game simply because, as of right now, there IS no game. I've got other programming projects for work (more custom report development? Goody) but I really can't wait to get into the guts of this course. After doing my presentation I'm hoping to post the pitch document here, but I want to clear that with Bob & Roger first.
It's going to be another week of no programming work on the game simply because, as of right now, there IS no game. I've got other programming projects for work (more custom report development? Goody) but I really can't wait to get into the guts of this course. After doing my presentation I'm hoping to post the pitch document here, but I want to clear that with Bob & Roger first.
Thursday, August 23, 2012
Hello, World!
Hello, world!
I can't think of a more appropriate first post for a dev blog, can you? My goal for this week is to flesh out an idea for a game pitch for the EAE capstone at the University of Utah. Excellent program, by the way - it's more fun than an Island of Monkeys. I think I've got a winner - I don't want to jump the gun too much, but it involves orcs, heroes, and cotton candy. Intrigued? So am I - here's hoping it's chosen as one of the game ideas to build into a prototype!
No development work this week. It looks like there's a LOT of talent in the program this year from both Film and CS departments. I can't wait to get started!
I can't think of a more appropriate first post for a dev blog, can you? My goal for this week is to flesh out an idea for a game pitch for the EAE capstone at the University of Utah. Excellent program, by the way - it's more fun than an Island of Monkeys. I think I've got a winner - I don't want to jump the gun too much, but it involves orcs, heroes, and cotton candy. Intrigued? So am I - here's hoping it's chosen as one of the game ideas to build into a prototype!
No development work this week. It looks like there's a LOT of talent in the program this year from both Film and CS departments. I can't wait to get started!
Subscribe to:
Posts (Atom)