Over the years I’ve created quite a few code examples which were pretty much just proof of concept projects. The polymesh navigation was one of these.

Another one was to create a php socket server and html client and yet another was the city generation script. These were all stand alone examples which I think could all work well together in one project.

Therefore I have started piecing together a basic start for an MMO type game. I’ve started with the existing polymesh navigation and have implemented the socket server into it. So far all players can see each other move around the screen using the polymesh.

The next stage is to get enemies on stage and get the city generation put in place.

Like the original polymesh navigation example, this project is going to be open source and is on github

So a couple of years ago I created a simple polymesh navigation example in ActionScript and I started thinking about expanding it. To start with I thought I’d convert it to JavaScript and make it open source. The initial stage can be seen here and for those interested in the code, it’s on GitHub

So very simple, there’s a few polygons which are to represent rooms and joining doors. First click sets the starting point, second click defines the destination.

The main idea is to create a simplistic version of how Valve does the bot pathfinding in games like CounterStrike. Currently it simple works out the path from the polygon edges but only uses the centre points, in the future I’d need to make the path more natural and fluid in design.

Not much game development has occurred over the last month or two, this is mainly down to trying to get an ongoing site live.

Introducing Projectily, a project management site which has been in development (on & off) for the last year. It’s still nowhere near finished but has been made live as an alpha release. This means you can create an account but there’s a whole load of features yet to be added and quite possibly some bugs left to squish.

You may be wondering why a site would be made live in such an early stage, it’s because this way there’s reason to prioritize development on it as it’s publically accessible. It also allows people to help shape the future of the site, if there’s any features you’d like to see on the site you can send a suggestion and it will be considered.

It’s typical that as soon as I commit to start doing device captured videos, my phone breaks preventing me from doing them. It’s been replaced but unfortunately the update to lollipop hasn’t been pushed to it yet so the screen recorder doesn’t work.

The device shadow issue on the previous video is due to the shadows overlapping. This is because each shadow is being ray-casted from each shadow object and the semi transparency is building up on the overlapping shadows. Ideally the shadows should build up one mesh to keep all the shadow elements on the same layer.

No more work has been done on the space side of things, mainly planning and coming up with ideas. A few changes have been made to the level parts. Player movement has been added along with direction swapping and the wall tiles have been corrected. There’s are few odd tiles in place but they’re just placeholders for elements still in development.

I thought the game needed a name so came up with ‘Pixelnaut’ (pixel as it’s using 16bit sprites and naut as in astronaut), not completely sold on it but it’ll do for now.

It’s been a busy start to the new year so far, breathing life into the new project. Currently created a very rough space level holder consisting of the player’s ship and a planet. The player can select the planet and the ship will navigate to it. The functionality took longer to implement than planned due to the new scaling but it’s working well now. Once the ship reaches the planet then the dungeon style level is loaded in.

The majority of the dungeon level functionality can be migrated from the previous dungeon game but there’s a few issues which still need resolving. So far only the bare minimum has been migrated across so there’ll be more to come.

Overall it’s been a slow but steady start of getting core chunks of code in place.

On another note, with the recent release of Lollipop for Android, Google have opened up the API for screen recording so now progress recordings can be taken directly from the device.

As you can see there are some rendering issues with the shadows on the device which will need to be looked into but it shows the progress made.

The Gift
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.

The Resolution
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.

The realization
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
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.

Affects
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.