it took a while, but keox is now out on Google Play!

https://play.google.com/store/apps/details?id=com.stefankernjak.keox

I don’t have that much experience with Android (and devices). But as long as your GPU supports Vertex Texture Fetch, it should work (I also added an option to lower the internal resolution, if the game isn’t keeping the 60 fps on your device).

Hey there, once again it’s been a while. But…

…you can now buy the game on the App Store!

Changes

Before the release I also made some changes to the game

• removed TouchKit for touch input and replaced it with Unity UI. To get the input data I replaced the replaced the previous script and added IBeginDragHandler, IDragHandler, IEndDragHandler,
  IPointerDownHandler, IPointerUpHandler
• triggering the bonus sound too quickly caused weird audio, so now the rate is limited
• added a share button with Everyplay, so people can now easily share their scores and replays with everyone

Past Events

Since the last post I showed my game at a bunch of local events

Vienna Gamedev Meetup #14
Austrian Games Night 2016
Radius Festival Vienna 2016

The feedback, especially on the graphics, was always really great and some people really got into it :D

Upcoming Events

If you’re in Graz, keox will also be at

Game Dev Days Graz 2016

Hey there, it’s been a while. In November I started working fulltime as a web front-end developer, which has seriously cut into the time awailable for keox.

But there is good news (and some progress).

track now works correctly on iPhone 6S and 6S Plus

Over christmas I got a new phone and therefore was finally able to properly debug the problem. After checking and modifying the shaders in XCode, I figured out that the newest iPhones just don’t like 2 pixel wide textures. Sampling them returns either 0.0 or random Garbage, depending on the color channel. Which is kinda weird and I couldn’t find any mentions of this online.\

To fix this, on those devices, the texture is now 4 pixels wide.

As an aside, you might ask yourself what 2 pixel wide textures could possibly be useful for. Well, data. This one is storing track x and y, rotation and a random value for more interesting landscapes/enviroments.

GameCenter

During one of the later Unity3d releases the GameCenter function, which gets you the display names of users, stopped working. And again I couldn’t find any mentions of this problem online (I guess most people don’t use the build in stuff or don’t do custom leaderboards or don’t need display names ¯\_(ツ)_/¯). So I filed a bug report and in the recent patch release it got fixed (as far as I can gather from the changelog there was a problem with network deadlocks or something).

finished track, camera, ui update

The new system is working properly now (as far as I can tell). Track smoothing is back on (except when the angle is going from 360° to 0°). A similar bug was also causing the track to jump wildly around.

difficulty

After showing the game to a few people, it was pretty clear, that the difficulty I find interesting, isn’t really playable for most people. So the amount of blocks in the beginnig (and on average) is now lower. Additionally there probably will be a limit on the number of randomly spawned blocks for each chunk of the track.

Release

Since the game now runs properly now on the latest iPhones, all GameCenter things works again and the track rewrite is complete, the plan now is to release the game within the next month (or two). So I’ll try to be more active on social media, in the hopes of getting some buzz going.

So, yeah, let’s see how that works out (and hopefully there wont be another 4 months between updates).

Since the last update I’ve been going down a serious rabbit hole, just trying to get one simple thing working…

It started when I decided to implement a track challenge similar to an aileron roll/full loop. I send the shader the angle values and it looked like a very jerky, broken staircase and not like a smooth loop. Previously I computed the rotation sine and cosine on the CPU and the shader unpacked and applied the data. But, since I’m sending the sine and cosine in two bytes, the resolution was pretty limited, which led to the ugly steps.

So I started to just store the angle in a single byte and computed the sine and cosine on the GPU. But, once again, there wasn’t enough resolution. So for now the angle get’s stored in two bytes (one holds 0 - negative Pi and the other one 0 to positive Pi). Once I had also updated all the shaders that read the track curve data (I think I actually managed to even remove a few texture lookups in the vertex shader :D), the next problem came up. 

Pretty much all the code that uses the the track curve to position things (ui, bike, camera etc.) wasn’t set up to deal with the new track orientations, turns out you can cheat quite a bit if everything just has to kinda point up. So I had to redo another large chunk of code to get that working (some things were/are still kinda sensitive to quick track curve changes). 

After the game was once again, more or less, working, I wanted a system to trigger/execute in some predetermined fashion different track curve types and quicker, additive track curve challenges. Which took quite a long time, but

• now there are several managers in place that divide the responsibilities to get that working (along with a bunch of xml serialization tags and corresponding classes)
• adding new track curve types and challenges should be pretty easy and only requires changing single files
  
• the track curve sequence can be controlled by xml documents 

After that, the next thing needed to actually be able to play the game properly once more, was the camera. It worked for the most part, but the position smoothing and rapid changes in the track layout (mostly due to bugs in the track curve code, but the bike should still be visible at all times) lead to the camera to places, where the bike isn’t necessarily always visible (that sometimes happened even before that). 

So right now I’m finishing up a game camera rewrite. It’s based on the Procedural Cinematography in Homeworld Shipbreakers. Right now it supports the hard and soft boundaries, setting minimum, goal and maximum distance, setting the view angle  and keeping the camera above the track. 

After that I’ll fix any remaining bugs in the track curve system and add a few more track curves (besides straight, straight_wobble and loop) and track curve challenges (quick twist). 

If you want to help with the development of keox and own an iOS device you can sign up for the beta here. 

It just might take a bit for the beta to be accepted into TestFlight.

The last two weeks featured more background work and gameplay improvements. 

more track bonus displays

Previously, when you collected bonus, the game would only show one at a time. When you collected two bonuses in quick succession, the first one would just disappear, causing you to miss it.
Now the game can show up to 4 of them at once, which makes you notice them more and having them stack up at the bottom of the screen looks pretty cool as well :)

extended track objects and curve storage

First a little technical background, all the objects on the track (blocks, jumps etc.) and the track curve sway were stored in the color channels of a 4 pixel wide texture. Which got read by the shaders and if the channel of the pixel assigned to a piece of the track was correct, a block or jump would show up. That means there is pretty much no difference in performance between an empty straight track and a curvy track filled with objects. Once an object is added to the texture moving it along the track just requires a little shift of the texture coordinates in the shader.
So that has changed. Track objects and track curve are now stored in two separate 8 pixel and 2 pixel wide textures. So there’s a lot more space to add new track objects and challenges. As a side benefit, meshes, that just need the track curve, actually just get the track curve texture.

better difficulty curve

Before this change, the difficulty during the game increased pretty rapidly and then just kinda stayed there. Now there is a difficulty manager that produces a difficulty curve similar to the one featured during the Pacing episode of Extra Credits. It works by having a single “step” per bump in the curve. Each step has a start and end difficulty, duration and a peak. The peak is defined by half a sine curve, where the peak can be shifted either to the beginning or the end of the step.
These steps can then be collected into a set and either be played through once or looped. The steps in a set can then be used to trigger events and control spawning.
The sets are stored in xml files to easy editing and one set can be run multiple times in parallel, to control different parts of the game.

more object oriented hit detection

Previously, the hit detection was pretty much just one big file with an ever growing Update function, as every track objects hit detection was implemented separately. This worked well for testing and three track objects. But now I want to add more objects. Now there is one hit detection object class and each object gets a separate one. Which makes it easier to add new objects and try out different detection behaviors (hit, near miss, near hit, pass, flyover etc. ).

new track object

Pretty much all these changes were in service to this one. Coins.
They appear in chains and give you extra points when you drive through them. And thanks to the previous changes, I had them up and running in pretty much a single day. 

other improvements

Other changes include speeding up the tutorial, increasing the screenshake, increasing the speed of the track, small optimizations to the way some of the meshes get generated and improved handling of Unity3d splash screen at startup.

Wow, it’s been a while! There were quite a few things happening on my end and the changes I wanted to make took (a lot) longer than I wanted to.
Anyway, let’s get started with the update.

At the end of August I met up with a local gamedev (@PhilippSeifried, check out his game http://www.aceferrara.com/). I needed guidance on how to proceed, so he gave me a lot of feedback and helped figuring out what the focus of the game should be going forward. 

Among the changes was dropping the idea of different levels (for the time being), since they lessen the focus on the main endless racing, split the attention of player and they also add a lot of work and testing.

The big thing is adding online high score syncing via Game Center. This took longer than expected, since I wanted to keep a custom solution for viewing the scores (and Unity3d’s Social API isn’t that well documented as far as I am concerned). So now there now is a sorta infinite looping circle of scores :)

Yes, this isn’t the most exciting screenshot, but it still was a lot of work getting it to this state and dummy data isn’t really something the Unity3d Social API or Game Center do.

Along with the online high scores, you now also see how close you are to beating the next best score of your friends, right under you own score. 

The game should also feel better now, by making the camera turning tighter, increasing the visibility of the bonus highlighter and making the bike be a bit more responsive. (I have more feed back concerning this, so there will be a bunch more changes in the same vein).

Following along with the theme of background work, the custom font now supports German specific letters and the game has a first version of a German translation (even as a native speaker, this was harder than expected).

As for the beta, it’s going to take a little bit longer, sorry. There is one backend change I’d still like to get in before and the online syncing took me longer than expected.

Game Properties from XML

The game properties (like track speed, points, block spawn rate, challenge spawn rate etc. ) is now being read from multiple XML files. There are still a few parameters missing, this will should make it possible to make all kinds of different levels and challenges in the future and more quickly test out different values.
Before this can be actually used by players there are still a lot of front- and backend things that need to be changed, but this is still the first step to a bit more content.

Faster Startup

Since the loading of the XML files added a second to the startup, some procedures were moved off the first frame and into Coroutines. On my Macbook this means the game hits 60FPS a bit earlier (I’ll have to see how much of a difference this makes on the actual devices).

Double Speed Environments

The track border and environments now move at twice the speed of the track. Giving you a sense of moving through the world even faster :)

Beta

Since the game properties handling was the last major big thing I planned to have in the game, I plan to start a beta pretty soon. If you have an iOS device that runs iOS 8 and  want to be part of that, just follow this blog or @thisothergames

Fixed environment color changes popping

Since the colors texture only stored the current and next colors, sometimes an environment hadn’t fully transitioned to the next color and the colors would change instantly, somewhere. So the texture now stores 4 colors sets (three previous ones and the next one). This gives the environments ample time to transition.

Animations update

The track and bike fade in/out animations had collected some crud and had some randomness, that sometimes looked good and sometimes didn’t work at all. So I cleaned up the code and improved the animations a bit. This also means the bike lane changes are less instant now and feel quite a bit smoother.

Track Deco Updates

The track side marks now fade in using an extrude vector in the vertex shader (this also means one less mesh that uses alpha blending). The track border should now be a little bit more performant, by calculating the forward movement once on the CPU instead of once per vertex in the vertex shader.