Blog


v1.1 update and soundtrack release

Snayke version 1.1 has been released. There are no new major feature additions, however many bugs and other issues have been addressed. As always, you can download the demo here or buy the game on Desura for $2.99 USD.


level 3 small


Full changelog:

  • Added bombs to random powerup spawns when powerup setting is enabled in classic multiplayer mode
  • Added graphics workaround for systems which don't support subtractive blend mode
  • Changed bots in classic multiplayer to wait a short time (based on bot difficulty) before acquiring a new destination when the current one is invalidated
  • Changed game settings to default to windowed mode
  • Changed resolution detection to only allow fullscreen resolutions with standard aspect ratios and sizes below 3000x2000
  • Fixed classic multiplayer matches waiting for key input after the first round
  • Fixed intro accidentally being enabled when shaders aren't supported
  • Fixed 'Open Folder' buttons not opening the correct subfolder in windows
  • Fixed replay save button in game over menus being enabled when exiting level which hasn't started yet
  • Fixed self-replenishing blocks in replays
  • Fixed rare sorting error in classic multiplayer mode with bots
  • Fixed transition from menu to ingame when using the Restart button after a classic multiplayer match
  • Optimized drawing blocks which have no links
  • Optimized level restart code
  • Tweaked level auto-restart fade time
  • Tweaked level order in section 5
  • Tweaked spawn rate of powerups in classic mode when powerup setting is enabled
  • Tweaked some default level completion times


Anton Riehl, the game's composer, has recently released the full soundtrack for Snayke on his website. Cover art is included as playable in-game levels! Check it out.



Release

Snayke has been released on Desura! It is available at a launch price of $3.50 USD (30% off) until Monday October 1st.

Demo update

The demo has been updated with some changes which hopefully make it less frustrating to die. A few levels have also been updated or replaced, and the ordering is slightly different.

Full changelog:

  • updated levels, tweaked order
  • countdown on game start is 1 second instead of 3
  • levels auto-restart on failure
  • minor game speed tweaks
  • ties are displayed properly in classic multiplayer games at round-end
  • deleted unused sounds
  • changed default player names
  • potentially fixed cursor hiding issues

You can download the updated demo here.


Demo release

The demo version of Snayke is out! Get it here.

It contains 20 levels, classic singleplayer, and 2-player classic multiplayer. The game's Desura page will have the demo as well, as soon as it's approved.

Feedback is welcome, although keep in mind that the full game will have slightly different pacing since the demo includes 1-2 levels from each section.

Release Date

As mentioned in a short Rock Paper Shotgun article about Snayke, the game will be released on September 28th. Mark your calendars! You will be able to purchase the game from Desura at a reduced price (normally $4.99) at launch.

A demo of the game will be available to download later this week. It will contain portions of all of Snayke's main gameplay features, although the replay system and level editor will not be included.

Snayke on Steam Greenlight

Snayke has been added to Steam's Greenlight service. If you want to see the game available on Steam, be sure to vote!

screenshot 1346531444

In other news, indiegamemag has posted a quick overview of Snayke. Check it out!

Gameplay trailer

As seen on the home page, I have made a new gameplay trailer for Snayke. It shows off Classic mode as well as many of the mechanics of Level mode. Here it is!



Smooth movement

Out of the many grid-based Snake and Tron style games I have played, almost all have noticeably jerky player movement. The usual reason for this is that the game uses tile-based graphics and wants to constrain player location to coordinates on the grid, however I consider smooth visualizations essential to the aesthetic of Snayke.

Here is a recording of Snayke with its smooth movement disabled.


And here is the same gameplay with smooth movement enabled.


It's easy to see how much smooth movement adds to a grid-based game, especially when things move at slower speeds. There are a few different ways to accomplish this depending on the visual style of the game.

In Snayke's case, each snake is represented by an individual tile image for each position the snake occupies on the grid. Smooth movement is achieved by doing a scissor cut-out of the front and back tiles of the snake, where the size of the visible area of the scissored tiles are determined by the time left until the snake's head reaches its next grid position.

While Snayke's visual movement appears smooth, snakes still move in discrete ticks under the hood. Collision detection and direction changes are calculated every time a snake advances to a new position on the grid, rather than continuously. This entails a slight amount of lag between the player pressing buttons and the game reacting, but no more than what would be there if smooth movement were disabled.

Here is the gameplay recording with collision visualizations enabled, showing collision detection acting in descrete ticks compared to the snake's smooth visual movement.


Block types

There are several types of tile blocks in Snayke, each serving a different purpose. They all use the same tile graphic, but their colors are unique enough to still easily distinguish them.


Obstacle blocks

The first is the 'obstacle' block. Running into one will kill you as surely as running into your tail will. They're slighly translucent, which helps make them look like they're part of the scene rather than just holes in the background.


Food block

The food block is a staple for any game in the Snake genre. Consuming (running into) it will increase the length of a snake's tail by 4 blocks. The only way to beat a level is to destroy (consume) all of the food blocks. In classic mode, consuming food will increase your score and create a new block at a random location.


Portal blocks

Portal blocks will teleport a snake from one end to the other, destroying the portals in the process. Portal connections are indicated by a line and a moving block between each end.


Bomb block

When touched, bombs destroy every non-snake block in a 5x5 tile square around them. While useful for getting rid of obstacles or "consuming" food without increasing the size of your snake, accidentally destroying certain blocks at the wrong time might make it more difficult or even impossible to complete a level.


Slow block

The 'slow' block slows down the entire game for several seconds, making it easier to navigate through tricky situations. I think it has the least utility out of the current block types, but it can still create interesting situations.


Reverse block

The reverse block will completely flip the direction of the snake which touched it. On its own it's not very interesting, but combined with obstacles and other gameplay mechanics it can create pretty unique ways to complete levels.. or accidentally kill yourself. :)


I have had a few other ideas for block types, but most have significant overlap with the current blocks and I want to try to keep the functionality of every block as separate as possible.

Implementing bloom in Snayke

Many games utilize bloom to enhance the sense of brightness of lights and increase realism, but in Snayke it's purely an aesthetic choice, although often fairly subtle. Bloom describes situations where the colors of very bright things appear to bleed onto their surroundings. To achieve this in a computer program, the bright parts of the screen need to be extracted, blurred, and added back onto the final product to be displayed to the user.


Screen with no bloom

Initial scene with no bloom

As with all post-processing effects, Snayke's bloom needs to be able to access the entire screen each frame. In order to do that, the game renders almost everything to an off-screen framebuffer rather than the main screen. 

Because it was operating on the entire game scene, my initial implementation would apply bloom to the background tiles as well if they were bright enough. This ended up making the scene look a little muddy, so in order for the game to only bloom objects I want, it re-draws just those things to a second fullscreen framebuffer.

Once that is done, it draws the second framebuffer to a much smaller one (1/4th the size of the screen in Snayke), using a shader which determines the luminance of each pixel and discards those which aren't bright enough. The size of the framebuffer is dependent on the game, because in many situations the loss of quality due to downscaling can be very noticeable, especially in less grid-like environments than Snayke's.


screenshot


The next step is to apply blur to the small "cut-out" of what we want bloomed, so that it will appear to bleed onto the rest of the scene later. Snayke's implementation uses a version of the shaders described here, which make clever use of the linear sampling used by GPUs. 2D gaussian blur can be done in one pass, but it's generally more efficient to separate it into individual vertical and horizontal passes.

To apply the blur, the previous cut-out framebuffer is drawn to a new framebuffer of the same size using the horizontal blur shader, and then that framebuffer is drawn to another one using the vertical shader. The end result is a nicely blurred image of the bright parts of our scene.


Horizontal blur

Horizontal blur pass

Vertical blur

Vertical blur pass


The final step is to draw the original full-size framebuffer of the scene, using a shader which upscales and adds the color of the quarter-size blurred framebuffer to the color of the original scene. Using a smaller framebuffer for the blurring process both improves performance and increases the blurriness of the end product by taking advantage of linear filtering when it's scaled.

In order to prevent the bloomed parts of the scene from becoming overly bright or washed out, Snayke's combine shader multiplies the color of the original framebuffer by 1 - bloomcolor before adding the bloom color to the original color.


Final scene

Final scene with bloom applied

On my Macbook Pro running Snayke at 720p, the render time of each frame while using bloom increases by ~1.1ms using my AMD Radeon 6750m video card, and ~2.3ms with my integrated Intel HD 3000. I could probably find ways to optimize it more, but the game has no performance issues even though bloom is the main bottleneck, so I don't think I really need to fiddle with anything at this point.



© Alex Szpakowski 2013 | ContactTwitter