Happy holidays to all!
I was fortunate enough to be given a new sprite set of a sci-fi theme. Originally the idea was to use it in a completely different game but it’s since occurred that it could be used to enhance the dungeon crawler game which was already in development.
It’s probably going to be more efficient to start afresh and merge the existing code into the new. This sort of rolls neatly onto the next section.
This blog has been somewhat neglected for a while now so being that the new year is just around the corner, the new year’s resolution is to keep this blog up to date. This will coincide nicely with the game refresh as all game provide will help keep the site current.
It’s been on the cards for a while to allow zooming functionality within the games but it was pushed back to the queue as a future addition.
It’s now been realized that this is also tied in with how scaling will work which is essential for mobile devices. If scaling isn’t implemented then the sprites will be the same pixel size on all devices. The problem with this is that on devices with a high DPI will display a much smaller looking version of the image than on others. This also means that this would allow much more to be seen on screens of a higher resolution than those devices with a lower one.
The solution is pretty simple, we create a scale based on the devices DPI along with a manually adjusted scale and the height of the camera is adjusted based on this value. This means that no matter the device, the camera position will always be positioned to show around the same amount of the display.
This has caused a few issues which needed to be cleaned up. The positioning of elements needed to be shifted so point 0,0 goes from the top left to the centre of the stage. This keeps everything in the correct place no matter the height of the camera. This in turn meant that the hit testing of elements needed to be updated to match the new positions of the sprites as well the scale.
Over the last few weeks I’ve been trying my hand at rigging up a basic navigation mesh for path finding. Using a navigation mesh should allow a more natural feel and responsiveness to character movement while moving through the map.
The general theory is quite straight forward, polygons are created on the walkable areas of the map and are linked together if they’re direct neighbors. The pathfinder then uses the edges of each polygon to navigate through the mesh.
The initial implementation of this is quite basic and only uses the centre points of each edge so the paths used still look like they’re on rails but I plan to update it so the whole area of the polygon is used.
The red lines in the examples below are the paths generated from the start to the end points, not elegant but a good start
Well it turns out that there was a major issue with the new shadows where they didn’t maintain the correct positions if the parent was moved. It was visible in the previous video as the parent was situated at 0,0.
A little annoying but glad it reared it’s ugly head sooner rather than later.
Onwards with pathfinding, currently working on a navigation mesh for path finding.
Its been a few months since any sort of update, mainly due to other commitments but I was also struggling with getting my head around how to tackle randomised building generation. At this point my plan of action is…. I don’t. I can get away with having a few different variations of each building which will do for now. In the future I could always create an algorithm to make it completely random but that’ll be saved for another day.
A couple of days ago I began writing a separate prototype for the buildings which includes a new method for handling shadows. The new shadows can now work with any polygon which should work nicely with the effect I’ve got in mind for the game’s atmosphere.
Below shows the prototype in action, it achieves the effect I was after and only uses 162 triangles but this will likely multiply five fold once the textures are sorted out and extra elements like furniture are added.
I know the textures are ropey but it’s just a quick prototype to demo the progress. It’s also a good testbed for building related feature development.
Over the last month I’ve been working on a new project. Usually I’d try to resist starting a new project as long as possible but feel that this could be a rather quick game to create.
It originally started off with trying to think of other ways I could reuse my city generator and I came up with a city where enemies come in from all exits and your squads have to fend them off. There will also be survivors in the city which can be rescued for cash. If I were to give it a genre it’d have to be an action strategy with hints of an unconventional tower defence.
Progress is coming along quite well, although there’s not a whole lot to show at this point. Units are controllable with pathfinding and enemies will wander around until they see a unit and attack.
There’s still a lot to get done but its a good start, I should have something to show shortly.
I’ve been taking a look at the game and thinking about pieces which dramatically increase development time and not really essential to the game. The key piece is the 3D side of things which although is a rather nice feature, is somewhat expendable.
Looking at games like Hotline Miami and Teleglitch, we can see that they’re still amazing games even though they’re of a top down 2D perspective.
With this decision in mind I started looking into the Starling 2D framework which integrates the 3D stage to utilise the GPU in 2D rendering.
After getting Starling setup its really quick to start working with as it uses the same variable and function naming convention as core AS3. Unfortunately it became apparent too quickly that my intentions for the framework were more than the intended use. Once the city generator was implemented, the performance went down to half which was seen using the core 3D previously. I’m not saying Starling isn’t good, for most projects its ideal, but unfortunately its not cut out for this project.
This has resulted in me creating my own version of it. It’ll conform to the AS3 functions to behave in a similar manner to using the inbuilt 2D engine but for it to easily extend the standard model to easily create complex sprites.
So at the end of the last year I entered the Oryx Trial with a somewhat poor entry and unsurprisingly didn’t win. I didn’t expect to but the point of entering was to push myself into writing some classes which would be used in my other game. I must say it’s also inspired me to get back into the game development side of things.
Since the new year I’ve made a big push and managed to get the random city pretty much sorted and integrated with the 3D stage. Now although this is pretty much regurgitating previous posts, a lot of work went into rewriting big ol’ chunks of code for it to work more accurately and quicker.
Now the main thing that’s up with this example is that there’s a delay when you hit the edge of the city block, this shouldn’t be a huge issue as I’ve purposely scaled the map down to down to show this. The map is really ten times the size so by the time the player reaches the edge of the map, the neighbouring block would have already loaded (in theory =P) The way the map works is on a 9×9 grid, when the player reaches half way through a block it starts loading in neighbours. The delay is present as threading in AS3 is still in beta so I’m currently daisy-chaining the processing off the main frame rending. When the player moves to a new block, the loaded blocks shift over so only new blocks have to be loaded. This now does mean that you can walk infinitely in one direction and the city will keep generating buildings around you.
There is a minor issue where some buildings don’t get loaded which I shall have to look into but I’m happy with the progress at this point. There are still a few pieces which can be optimised at this stage but I thinking I’ll work on a different piece of the game for now. I’m really hoping to have something fresh for the next post as this is yet another post which contains the same as previous entries but with minor updates.
Well I submitted by game last night but have mixed feelings about it.
I’m pleased with the amount I got sorted with the limited time available but I’m not happy with the quality, especially towards the end as I was having to cut a few corners in order to get core functionality in place.
For example, the inventory & UI in general was very slapdash, levelling and experience of the player and items was somewhat unfinished & untested and there were still quite a few noticeable bugs in place.
The main bug is still the shadows, they still allow defogging of tiles behind walls and there’s a weird ghosting issue where you can see ghostly enemies on the fogged tiles but they’re not there when you get to the tile.
Since the last update I’ve added in enemy AI, they’ll intercept you when they see you and go to attack. If they lose sight of you for too long they’ll lose interest and stop chasing. I quickly added in food to heal the player.
Anyway, for anyone wanting to see what was submitted, you can download it here
Progress of the roguelike has been slow but steady, not really had a huge amount of time to spend on it but happy with what I have managed to do.
I thought I’d post as a slight milestone has been hit and that’s shadows & fog of war. I remember spending many hours before trying to get a good 2D shadow algorithm created and failed due to heavy resource usage but I’ve come up with a new method which works quite well.
It still needs a little tidying up but it’s a start.