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 $4.99 USD.
- 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 ratios 1 < ratio < 2 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.
Snayke has been released on Desura! It is available at a launch price of $3.50 USD (30% off) until Monday October 1st.
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.
- 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.
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.
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 has been added to Steam's Greenlight service. If you want to see the game available on Steam, be sure to vote!
In other news, indiegamemag has posted a quick overview of Snayke. Check it out!
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!
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.
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.
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.
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.
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.
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.
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.
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.