The bulk of the progress made this week is with the UI. I’ve completely remade it all to use a base display to keep it consistent for each view. I’m not too happy with the buttons and there’s a little bit of a stretching issue but the new changes will make updating this in the future much easier.
Other updates include creating a dialogue handling system for displaying multiple strips of text which will be used for the tutorial and quest information. Hopefully this will be finished next week
Over the last month I’ve been revisiting the Runners game and quite a lot has changed since the last post a couple of years ago!
The first big change you’ll notice is the tile set has been swapped out for a brand new one. The new tiles blend together better than the old ones and will allow more interesting environments, they generally look a bit better than the last as well.
Under the hood
Now this is where the majority of the recent changes are so I’m gonna break it down a bit:
The graphics are now being rendered with OpenGL which will help with general performance and allow some advanced graphical techniques
The UI originally was a mash up of Android components layered on top of the map canvas which was a pretty nasty way to do it. It’s now been completely redone within OpenGL to make it more fluid.
The quest system has been completely rewritten to allow different types of objectives to be part of a quest and to give prerequisites to each objective if required
The last week has been mostly spent working on two core mechanics. Although both could still do with some tidying up, they’re both functional.
The idea behind reactive pathfinding is that the character will keep checking their path as they progress down it to see if the route can be optimized. The result will therefore be a shorter path and hopefully one which looks more natural.
Field of View
Field of view is a key mechanic so the characters can see enemies and know how to remain hidden. The method was completely changed from the original. Instead of doing a periodic check along an angle like what was originally used, it now uses a line intersection check to see where the ray hits a wall. This will give a smoother line next to walls.
Well now the field of view is in place the next step is to add in the mechanics of what to do once something is seen. This will be the beginnings of adding in some sort of simple behaviour to the characters.
It’s been a while since working on Exitus but it started playing on my mind over Christmas as to why it was abandoned. The main reason was due to the time to take fixing bugs and not progressing, these bugs were mainly due to trying to build something too quickly and the structure becoming difficult to maintain.
It was therefore decided to reign back some of the features for now and rework them. It also allowed me to familiarize myself with something I had been interested in for a while, WebGL.
After building up the core groundwork for WebGL I began incorporating previous pieces back into the new version.
So far the city generation is in place but limited to just one block, there’s also no internal structure which was one of the pieces which needed the most fixing. The path finding is also in place but being worked on again to give it some well needed improvements, the main being implementing reactive path finding to make it look more natural.
After spending a fair amount of time on the perimeter buildings and not getting it to work nicely I’ve stashed it for now to work on other pieces.
I’ve added some basic characters, enemy and player. Currently they’re just coloured circles with a code showing their field of vision. If a player goes into an enemy’s FOV then the player will turn white. Just so we know they’ve been seen, in the future they’ll start chasing the player.
Players are black and can be selected, once selected they can have a path created by clicking on the map. Enemies will just move randomly around the map.
I’ve spent a little time working on a project to learn ECMA6 and the process of transpiling it down to ECMA6. The project is essentially rewriting a collection of code I’ve previously written in other languages and merging them together to play nicely. I’m now considering developing it further into a survival game.
So far I’ve put together the bulk of the city generation and the polygon path finding. The polygon mesh currently consists of the roads and a very basic algorithm for building layout. In the image the polygons are only visible for the current city block you’re currently in. This is only temporary so you can see the room layout as there’s no building textures yet.
I had originally thought that having procedurally generated building layouts would be good but I’m now thinking that having preset layouts would be a better idea.
There’s some lag while moving around the world which I’ve got to address and I’ve still to combine the perimeter buildings as they’re currently split by the city block edges. I’m also eager to get some sort of gameplay added in.
A working example can be viewed here and the code is available on github
Update v0.0.3 has just been released adding another 30 new icons.
Verge is now an open Alpha release and can be found on the Google Play store here. If you’re interested in checking it out then send an email to request a promo code
I’ve just released an icon pack for android, it’s still in alpha while I try to increased the quantity of icons. It’s just a simple flat theme icon pack which currently consists of 140 icons.
I’m starting on v0.0.2 as I’ve just created an additional 83 icons in the last couple of weeks. The app itself can scan your installed apps and send me the IDs so I can see the apps people are using and create any missing icons.
The map outline has now been completed so I can finally start concentrating on the actual layout and finer details of the map itself.
I've also finished the import from Pyxel Edit into the game and the video shows a quick device recording so apologies for the jerky movements. You’ll also have to excuse the black right border, it’ll be covered by UI so it didn’t need to go to the edge of the screen
One minor issue which is going to annoy me is there's a small line between each tile. This is a pixel or so from the Java bitmap selection functionality I'm using to get part of the tileset onto a Sprite. Not a huge issue, it's just going to bug me til it's sorted.
Up til now I’ve just been developing on a testbed 20×20 tile grid. This has been fine for testing but I wasn’t sure how well it’d run with the real map size of 254×212.
Method #1 – one big canvas
The original method was using one big canvas and drawing each tile to it which was fine for the small number of tiles used for testing. For the final number of tiles however resulted in instant failure due to bitmap size restrictions. I had considered using multiple smaller bitmaps but went on to trying the next method
Method #2 – individual tiles
The second method was using a separate sprite for each individual tile instead of one giant one. This had marginal success as in it didn’t fall over instantly. Instead it was just horrifically slow and made the game unusable. I spent quite a bit of time diagnosing bottlenecks and trying to speed things up. The main idea was to stop rendering all the tiles which were off screen but there was still the overhead of the tiles existing in the first place. This led me to come up with the final method
Method #3 – reusable tiles
The final method came from the idea: what if I didn’t need all the tiles created at once, all I need is enough tiles to cover the screen then reuse them when they’re out of sight. So now if a tile moves too far to the left and off the screen, it redraws and repositions itself to be the next tile on the right.
In this example, there’s only ever 80 tiles (8×10) yet I’m able to create a map of all 53,848 tiles with minimal overhead.