Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Nov 2004
Offline Last Active Mar 08 2016 02:51 PM

Posts I've Made

In Topic: When is it okay for a player to get "stuck"?

28 December 2014 - 04:18 PM

Thanks for all the useful information, I hadn't thought about some this!


I think much of the responses have been in favor of allowing players to get "stuck" as long as 1) this is a part of the game design and is taken into account with the appropriate level design, and 2) the player is well aware of this mechanic, is given useful information about such mechanics, and is given useful information about when they have reached a point where they can not make any new useful moves and must restart somehow OR this information is conveyed natural through good level design.




(4) Another option is put in the one-way doors and similar irreversables, but also allow infinite undo. (Like, say, Sokobond.) You can always get out of whatever mess you're in, but the logical structure of the puzzle is still such that there's a "one-way" door.

(5) A further option, midway between suicide and undo, is checkpoints. Overt ones, like in a precision platformer (VVVVVV, YHTWTG, etc.). I can't think of a puzzler that does exactly this, but it'd be kind of interesting. So have squares that "save your progress" such that you can always return to them at the touch of a button, like a less-granular "undo".



(6) Iterating back through the player's moves and deducing at which point in the past the level *was* solvable, then, upon suicide/death, rewinding time to that point. I don't know of any game that does this, but it's an interesting idea. It ends up being a hint, of course, because once the player realizes what's happening, they understand at what point in time they made their fatal move. But depending on the game that might be an entirely appropriate kind of hint.

I like the idea of being able to "undo" certain moves.  Unfortunately for my game, encapsulating "moves" is a bit difficult because the gameplay is a mixture of "continuous motion" movements (moving around the level), and discrete "level reconfiguration actions".  I think the latter type of mechanics would allow for undos, but trying to convey to the player what exactly constitutes a "move" and how to undo it for continous motion is a bit difficult in my situation.  I know there are some games that have done this before, but for my game I don't think it would nessesarily work well.  Implementation probably wouldn't be too bad, but I'm a bit limited in user interface (it's mobile) and would like to leave the complexity in the user interface this would make out of the game.  It's something I will probably explore in future games though.  Also the game I have in mind should be an entire level on one screen, so checkpoints might not be easily designed.



For the one-way door, what if instead it was a door that isn't always accessible? To even reach the door, the player need to reconfigure the local area of the level sufficiently to allow access to the door.


Cool I like this concept.  I'm not sure it would work in my game, but I think this would work in a lot of cases (I remember dungeons in Zelda applying this design).




Add a 'teleport pad' or something beyond the 1 way door, which carries the user back to the initial part of the level, and clearly tells them that the task has been reset.


Thanks, I'm not sure it would work in my specific case, but I might experiment with this idea.




You don't want to simply hold the player's hand and make things a cake walk, but do make the process of moving through puzzle sections as streamlined as you can. Give them clear methods to reset or revert easily if they need it, and make cause and effect fairly obvious. (Don't have a button in a 3 stage puzzle that has a 'random' effect for example on the last room, but can only be pressed in the first.)


Ya, I think finding a balance between "too hard" and "hand holding" is key.  I like the idea of the player required to perform a specific set of actions in a certain order, but this needs to be clearly communicated to the player, and the player needs to know when they've gone past the point of no return.  As long as that is communicated clearly, then in the absense of a notification of failure, the player will continue to try under the assumption that they haven't messed up yet.  If that is not communicated and the player keeps trying despite this unconveyed information, I could see the player getting very frustrated in the wrong way.

In Topic: Game a Week

10 April 2014 - 01:19 PM

I like this video on an 11 day level design


This video is really nice.  This gives me another idea.  I usually focus on programming, game component design, and visualizing the games during the game a week, but this makes my skills kind of one-dimensional. Instead it would be interesting to focus on a completely different sub-craft of game development, like level design or asset creation (art, music, other?) for a week, and then do a write-up on what's learned as well as the results (no actual game, just whatever content is iterated on or created).  This will help to understand the other sub-crafts of game development deeper for when I work in teams with artists/musicians, etc.  It will also be a good way to become familiar with those pipelines and tools in those fields.

In Topic: Game a Week

09 April 2014 - 10:48 AM

Hey man, Mondongorongo here; i noticed you linked my blog up there, thanks for that. 


Hey, no problem, event though I can't read spanish well it's still nice to see your games.  I also added your name in the list :-)  Thanks for your input!!


you have to understand your limitations and know that you can't aspire to build the WoW killer in thosae 7 days


I think this is really important.  I've been a programmer for a while, and I still find I underestimate the amount of work required for things.  I think that for aspiring game developers (indie or not), it's important to be able to predict the amount of time it will take to work on something, whether it be contract work or reporting to your manager how much time you think a task will take.  This is a skill, and it takes practice to improve that skill in time-estimation.  Writing more and more games means that you can start seeing what is realistic to accomplish in a certain amount of time versus what is unrealistic, and this is always helpful for any project that's taken up.


the only ones still making money are the quick one game a week apps that I did over a year ago whilst the ones I spent months working on with paid for assets are making nothing


Wow, this is really interesting.  Can you think of anything that you can attribute to this?

In Topic: Game a Week

08 April 2014 - 08:06 PM

I've never heard of a game a week or every two weeks. I've only heard of jams and the one game a month ( http://onegameamonth.com/ ). I'd think that the failures you get with one game a week or two would be the same as the month long one, but would likely run the risk of you getting burned out faster than most programmers.

Yea, there have been some recent blogs and ideas for one game a week floating around.  The goal is for people to start writing games, and start small so that it's not as easy to fall into the big ideas trap (have a great idea, a small team...3 months later realize it can't be done with the resources, and there is still nothing to show for it).  The idea is that if you design for small week projects ,you will get your creativity out, start prototyping your ideas, and hopefully gain experience in writing games/programs.  There are other benefits, but those are just some.  Thanks for the link, I think I have heard of it but I forgot all about the onegameamonth.


Awesome, will take a look.  I looked at it a little bit and he has some great things to read in there.  Thanks!


Thanks for the links, I'll edit them in the original post to keep track.

In Topic: Voxel Theory & Practice

12 August 2012 - 11:04 AM

Wouldn't it be faster to start from the bottom

I don't remember how the Laine paper reconstructs it, but I do believe the Crassin paper does construct bottom-up. They treat the fragments produced from the graphics pipeline as leafe nodes of an octree, and then build the tree up from these leaf nodes in parallel (I think on the compute shader). Essentially the idea you mentioned.

IMHO, building bottom-up or top-down depends on a few things: 1) you use the right construction that makes sense for your application, 2) the construction method you pick is not overly-complicated for your problem 3) parallelize node construction as much as possible. (important if your on the GPU, perhaps not so much if you're on CPU, and perhaps not important at all if it is done as a preprocessing step and you don't have dynamic objects).

Obviously when using the pipeline, it is faster to construct bottom-up since you have the leaf nodes after the fragment shader (all in parallel), but if you're on a CPU or something, you may just want to construct the tree top-down since that way is generally easier.