1. Interface changes

So, I decided to start a weekly devlog for this puzzle game I’m working on (presently called Taiji or Tai-ji). I’ve already been working on the game for a few months and it has a couple hours of gameplay.

I’m not sure how much I should go into explaining the mechanics of the game, but I’ll go ahead and give a basic overview: It’s a top-down 2D game where you explore a mysterious world and solve the puzzles you find there. The game has a core puzzle mechanic, which is these grids of tiles that can be toggled on or off.

image
Here’s a basic example.

Keep in mind the art and everything is very much work in progress. But generally the way the game works at the moment is you walk up to one of these start tiles and then press a button to go into a mode where you are interacting with the panels using a cursor. The cursor is similar to Tetris Attack or any other block based puzzle game.

Okay enough explaining of the basics.

This past week I put together a build and sent it out to some friends (William Chyr, Casey Muratori, Martin Cohen, Brian Moriarty), and got some feedback. Casey was pretty appalled by the control scheme and user interface I have going on at the moment. I did try out a new control scheme this week that mapped entering and exiting the panels to the same key, which was probably a bad idea. Worse still I never really swapped the buttons around on the controller, so there was sort of a backwards feeling where you press B to toggle tiles and A to exit the panel.

Besides my misguided control changes, there were also just a bunch of interface issues which Casey readily pointed out. Some of those can be fixed with feedback, but others perhaps not.

A very interesting solution posed by Casey to the interface nastiness would be to change the interaction method to always consist of the “player as cursor” model. “You always want to move a dude around,” says Casey, and I can’t argue that the abstracted cursor interface of the panels is somewhat unsatisfying to interact with to say the least.

So the plan is to implement that input style pretty soon, but in the meantime I have added some better visual polish and cues go the current interaction model so that I can give the new one a more fair comparison. After all, there really had not been much consideration for how the panels felt to interact with beyond the bare minimum.

So I added some interpolation on cursor movement as well as a bit of a bump when you try to move the cursor onto a tile which you cannot because it was already filled or what have you. I also made it to where the panel flashes repeatedly when it is in a solved state but you are still in interact mode. I think this probably helps somewhat with an issue that the panels had before where you would sometimes solve the panel and then expect the stick to move your avatar instead of the cursor. Differentiating between different states is probably more important than I had expected and I should have done a some of this baseline polish work sooner. As Casey said, it’s the primary thing that you are doing in the game, so it had better feel pretty damn good.

Anyway, besides that I have just been thinking about some of the issues that the player as cursor model will create which must be solved. For the toggle type panels , there really are not that many issues. It should be a straightforward implementation process for those, but the snake ones require some more thought.

One of the issues is in dealing with how you can force the player to start the panels at specified positions. I could still have start tiles that the player stands on and hits a button, but the major issue really comes when we start talking about panels that the player is literally walking around on and not some ghostly version on a panel on the wall. In this situation, normally the player can start wherever. Which is fine, but if we are always considering the player to be a cursor, then the panels on the wall would seem odd if they start automatically and the ones on the world do not. In other words it’s a bit of a consistency issue more than anything.

So the current solution that I’m looking at is adding a tile type which is sort of a “clearly this is a tile, but you cannot start drawing here” type. I thought for a while about what the symbology for this type of tile should be: whether it should have some special symbol on it, or maybe the starting tiles themselves should have a symbol, and what I settled on is that the instantaneous tiles will have broken line versions of the normal tile squares that I have had since the beginning. It’s a bit of a toss-up as to how they will be depicted exactly, but here are a couple possibilities I’m considering:

imageimage

 

 

 

 

 

 

 

There’s a bunch of other stuff that I got done in the past week or so, but I think I’ll cut this off for now, as there will be plenty of time to talk about more in the future.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s