Exitus v0.0.1

Over the last week I’ve been starting to convert Exitus over to libGDX & Kotlin. During the process a couple of additions have also been added.

Not just squares

The first noticeable change is that the city generation now allows non square buildings to be created. This was on the list of changes for quite a while but it’s been added in during the rebuild. You’ll have to excuse the textures, it’s still using the whole spritesheet as the centre textures for the building sections.

Walls

The other change is the appearance of buildings. The building models now have two different height walls for the internal and external views. Outside a building has full height walls but moving the camera inside the building cuts away to show the current floor. The left image shows the internal view and the right image shows the external walls (in the top left).

What’s next?

After finishing the basic structure of the building, the next step is to add neighbouring city block generation for an infinite map.

Runners v0.0.3

The main update for this version is adding an info panel for the runners and locations. It provides the player with additional actions including centring the map on the selected element, creating a task for a runner from a location and opening the runner’s inventory.

The above show what will appear when a runner is selected, the icons are an image of the selected runner, the tasks button and the inventory button. The sizing and position still needs a bit of tweaking as you may have guessed. You’ll also probably notice that the runner has a different appearance too. The core method for allowing different skins is now in place so you can easily identify which runner is which (when you can finally have more than one)

I mentioned the inventory earlier which has also been put back into place but it’s currently being scaled so the text is a little blurry

Another important addition for this version is getting the saving working again which required a complete remake for the GDX infrastructure. Like before the gdx update the camera position and the runner data is saved.

Runners v0.0.2

The most visible change made this week is another one which hadn’t been implemented in the original version and that’s background animation on the map. This is really another reason why it was decided to move over to gdx, although possible with the original version it would have been time consuming and gdx has made it a breeze to get working.

Another change which is being worked on is adding landscape orientation support. The original version was purely portrait and adding landscape was always an afterthought but being that the UI is being rebuilt anyway, it’s the perfect time to get it plumbed in.

The rest of the development has been migrating elements from the original version into the new. A slow gradual process.

Runners v0.0.1

You’re probably wondering why after the previous posts about the runners game we’ve landed at version 0.0.1, well there wasn’t any sort of versioning before and it’s being remade to a degree. The way the original version was put together made it very difficult to implement zooming on the map. Because of this, zooming was one of the first things to be put together in the new version.

It was also made with my own implementation of OpenGL which was still pretty buggy so I’ve decided to switch it over to use libGdx. Now the new map is working the way I want it to I can start merging code over from the previous version.

Runes v0.0.2

The main noticeable change this week is the introduction of animation for both the creatures and the background. Previously the creatures would instantly move to the selected location but now they follow the path changing direction and displaying an animated walk cycle. A test area of water has been added to the centre of the battlefield as a testing ground for both an animated background and to act as a blocked area for pathfinding.

Another visual change is the selected creature details box has been styled (slightly) and also works as a quick link to centre the camera on the selected creature.

Behind the scenes a major change has been made to the creature movement and action point system. Previously creatures had one movement point per round and the action point accumulated, now it’s completely custom for each creature and non creature cards now have mana and/or stamina requirements. Creature movement is his based off stamina but based off movement stamina, meaning big slow creatures with high movement stamina won’t be able to move far but can do some devastating high damage stamina based attacks.

Runes v0.0.1

Learning libGdx is something I’ve been meaning to do for some time now and I’ve finally gotten round to doing it. I decided to convert an existing project instead of creating something from scratch and spent the last week or two working on it. The previous game was purely for Android but using Gdx allows the project to also be built for desktop and iOS.

The initial idea for the game was to create something which was essentially a TCG with an additional layer of strategy by having a playfield to move characters around. Each character would have their own deck and characters of different types would have decks containing different cards.

The first version was created as just portrait for mobile but being the main structure was being remade I made the decision to cater for both portrait and landscape, especially with the option for building for desktop. Originally the battlefield was going to just be a five by eight grid with just the card icons as movable tokens but while working on the Gdx implementation I thought it would be better to use separate battlefield sprites and create an actual level with obstacles to maneuver around. In its current state the creatures gain one action point per turn and can move one space each turn but they cast as many spells they have action points for. After thinking about how this plays out I think it’s going to change in a future update

Another visible change is that I’ve decided to give a ‘demake’ effect to the card images by changing the graphics to a 16bit type appearance. They all still need to be tweaked and I need create a proper palette for them.

Currently there’s only a few different cards which were used for testing. This mainly consisted of spawning creatures and affecting them with effects. Once everything is working correctly with Gdx and I make a few changes to some of the game mechanics, I can continue to add new cards.

Runners – 2019-11-11

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

Runners – (2019-11-03)

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!

Visually

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:

OpenGL

The graphics are now being rendered with OpenGL which will help with general performance and allow some advanced graphical techniques

UI

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.

Quests

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

Exitus – Reactive pathfinding & FOV

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.

Reactive Pathfinding

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.


Original FOV


New FOV

What’s next?

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.