next »

[psyguy]

I've been into making web-based games recently.  It's a good fit for a lot of puzzle games, because performance is not necessarily critical.

My latest creation is this Snakes without Brakes!  You must use one or more snakes to collect all of the gems in a level, along with occasional side objectives such as "don't kill any snakes!" or "kill all the snakes!" the latter of which is pretty terrible for the snakes.

The appearance of the game is pretty simple:



The visuals are more interesting in action, with some various animation effects going on that can't show up in a screenshot.  The quality of this gif is rough, but it offers a good idea of the fundamental gameplay mechanics.

[quantumpotato]

Oh, looks neat! I like the "sliding" mechanic in puzzle games but I haven't seen one where you control multiple multi-tile entities.

[psyguy]

Now that I have created most of the levels for the game, I needed to put together a level select screen.  I needed it to also show information on whether or not you've previously completed the level along with any relevant statistics.  But, I also don't want to have a 50 column spreadsheet, can't have too many statistics!



I actually had a little fun working on building the file that populates this dialog screen, in so much as working with json files and for loops is fun. 

Individual levels in the game are saved as plain text JSON files. The format is terrifyingly straightforward: title, intro message, snakes[], gems[], you get the idea. When time came to put together a master record of levels, I created a small function buildLevelIndex() that loops through all possible levels. (This was easy enough, as the level names are 0.1.json, 0.2.json, ...) After retrieving each file via an AJAX call, I parsed out the title, difficulty, etc. and saved it into an overall list, that tracks all of the game's levels. levels.json, or something like that.

When the user requests the level select screen, a single AJAX call retrieves that master list, and then uses it to populate the dialog itself. Each level has a "record key," which is used by the population routine to query localStorage for previous completion data on that level. If the record data exists, then those columns are successfully datafied.

Each table column across each row also contains a simple rel attribute for sorting purposes. Consider the difficulty column; the text string is converted to a simple integer by a reverse lookup. The user chooses to sort via the dropdown, the dialog removes all table rows, sorts them using a custom .sort() function that compares the appropriate column's rel attribute, and then the dialog re-parents the rows in the properly sorted order.

With that job out of the way, I'm moving on to less complicated dialogs like "how to play," also known as the dialogs that no one other than the search engine spiders will ever read!

[psyguy]

This morning I sorted out the remaining issues with mobile controls. The chief demon, was that I needed to disable the ability of the user to change page scaling, it conflicts with the position: fixed that I employ for the menu and status bars at the top and bottom of the screen, disrespectfully.

Drag and drop control of the snakes themselves also needed some custom tooling here. On a desktop browser I rely on the mousedown, mouseup event to determine when you have selected and released a snake. Because I do not use the click event explicitly, you can drag the snakes in a single click, rather than clicking once to select a snake and then twice to move the snake. It is very much like working nothing but half days, in a way, which is perfect. However, a mobile device did not cooperate, did not trigger mouseup in the same way after a finger drag. (I think it might have sent the mouseup event to the original table cell clicked, but I'm not certain.)

Enter, then, the touchstart and touchend mobile events. The touchstart is the tablet equivalent of a mousedown (in my ledger, anyhow), and it behaves as expected. I attach a touchstart callback to each cell, and if you have touched a snake, then it becomes eligible for movement, either by the laborious second click, or by a drag and release. Consternably, however, the touchend event is directed to the widget on which the touchstart event occurred, without any regard to how far you have dragged before releasing.

To resolve this, I had to get a little bit dirty. I listen for the touchend event on the "snake is here currently" cell. When received, I request cell references for each non-diagonally adjacent table cell (NWSE), and I calculate the absolute screen coordinates of each of those cells. From there, I need only perform a simple collision check between the "mouse position" (in this case, the absolute screen location of the touchend event) and those 4 neighboring cells. This approach is not quite as elegant as I would like (preferably I would receive touchend event on the destination), but it's not my call.

[psyguy]

Very close to putting out some playable levels on this project, friends!  I considered rushing something out today, but better sense talked me out of it. 

I've been spritzing up the UI.  I really needed a non-generic font, I will tell you this though, misery is when you go to 1000000freefonts.com and cycle through page after page of insufferable font hell, wondering cursedly to yourself, who would ever use these, you can't even read the darned letters.  I eventually settled on one that works alright, it is not completed reviled.  I also experimented with slightly askewed elements for a little bit of flair, it gives the screen a little bit of life and personality, and I think it also makes it look more like "i am important, read me!" than a more orderly counterpart.

[psyguy]

I have been getting some helpful feedback on this game, I posted some of the levels in the playtest section.  One of the main areas of contention has been the sections of darkness, where some players might think of the dark as a dangerous thing, or something that functions differently than a wall.  It's certainly something I wanted to work on.

To make the level layout easier to figure out at a glance, the places you can and can't go to or screenwrap to, I'm working on adding explicit perimeter walls at the edge of the majority of the play area.  I've got a screenshot of the before and after of one of the levels, the addition of the various transition tiles makes it look a little cleaner, but more importantly it also makes it much more obvious as to where you can and can't go to.