Space Year 2025 Comes To An End

There Is Gold In Them There Hills!

 Space Year 2025 comes to an end, and this month I have mostly been fleshing out the world of warbands. This has required some low poly rocks scattering at various intervals and a some ruins, bridges and castles. Gotta have a castle in a medieval hack and slasher.

Colourful Heather To Break Up The Monotony Of Green

 Whilst adding all these extra things help make the landscape more interesting, it also creates the more "stuff" means the more stuff for the Ai to walk into and get stuck. Behold navMesh for pathfinding!

Now it has been a good 10 years since I used recast, for Airship Dragoon, so I did need a bit of trial and error to get it to build reasonably sized grids. After a bit of pathfinding testing I determined it had a nasty tendency to fail to get to the target point on particularly long or complicated paths (bridge? What bridge?), and so ended up adding some waypoint markers which will (hopefully) act as a guide for the wonky path. However it looks like I will be having to check this manually as "we made a path but it doesn't actually go to the end point" does appear to happen some times, especially when a bridge is involved. 

Fun With Pathfinding

 

Apart from that it has been Christmas, which has required a certain amount of eat, drink and be merry ... all of which has been somewhat fatiguing and I will be glad to get back to normal service has been resumed and don't have to hear overly jolly Christmas music everytime I stop outdoors.
 

One Ruin, One Bridge, One Castle

Steam is having another NextFest at the end of February but I reckon that the time frame for getting a working demo out is too tight, never mind clearing the store and app review hurdles. I am not particularly concerned as I don't think that NextFest adds anything to discoverability and if you aren't already bringing your pre-collected audience over it's all potluck if you get a new following.

Bonfire Lit, Grace Touched, Do You Have A Permit For That Campfire, Etc

 Space Year 2025 comes to an end, and during it I made the final release of twin-stick catgirl carnage shooter Monsters Loot Swag and added NG+ ... neither of which garnered any attention and all visibility rounds expired long before they were used up. However that is just the nature of the beast now. 

So the plan from now on is smaller, faster development cycles leading to shipping every 18-24 months or so, rather than labouriously iterating on something on and off for a decade only to release and hope I make my 100 bucks steam app cost back. Knight Errant/Warband World/Whatever I am going to end up calling it, is the first test of this. Whilst Early Access did not garner any enthusiasm or bug reporting help, I am probably going to go down the Open Beta route and see if that helps gather any players, before perhaps another attempt at Early Access in the same vein as Vampire Survivors, sell it for a few bucks and then finish it off 6 months later.

Hello Space year 2026. 

Character Selection Screen

So I've knocked up a character selection screen that, currently is rather devoid of any art work. It's failry simple, uses an array which the player can flick through, each character (currently a whole 2) then display an image of the character (which is currently a placeholder) and more importantly a series of statistics relating to the character at the side. These include the basics such as speed of movement, health and energy replenishment and strength for pushing enemies aside. This is followed by the 3 types of attack and evade, and their relevant statistics, so the player can move through character selection and view the differing statistics for comparison.

I have since changed the buttons to something less awful using a bitmap array and text.

Having finally dispensed with DirectX 9.0c in favour of DX11 and OpenGL, I set about converting some of my custom shaders with ... not particular success.

Yeah, I'm pretty sure that isn't supposed to look like that ... This appears to have something to do with hardware skinning being controlled by the GPU when previously it was the CPU. As this only affects a few things I have come up with some workarounds for the fancy custom materials and will come back to this at a later date.

I've also had more of a play around with my XP-Pen display tablet and started to become familiar with the artist app Krita. I am planning on using this for the 2D art in game, and especially the selection screen for character portraits.

Drawing of an old oil painting I did some time years ago.

I also thought about reworking the artwork for Airship Dragoon, and knocked up a colour sketch idea for composition. Might not actually replace the original artwork but could use a new one for Steam's new capsule formats for updates - then again I could go the whole hog and use it for complete new rebranding.

 

I also did a whole load more stuff this month but can't actually remember what it was ...

 

Anyhow, onwards and upwards ...

My Feet Hurt, New Character And Goodbye DX9

So, apparently the new Blogger interface has been eating my images for the past 2 months ...

So expect to see a blank image leading to a 403 page soon™.

It's been the hottest day of the year here, so naturally I went out for a half marathon route march ... and now my feet hurt.

I finally finished off another playable character model, a shotgun wielding, propeller-powered catgirl, currently named "Southern Hospitality", complete with Daisy Duke hotpants. She has a short range playstyle with slow attack rate but high damage and medium manouverability. After each shot a new shell is loaded with a single handed pump-action for the obligatory "rule of cool".

And here's some video of gameplay.

Apart from finally completing a second playable character I have been porting over my project to the new and shininess which is Dx11 and OpenGl 3.2 (might be 4.0 I can't remember). This meant a final farewell to the much loved DirectX9.0c which I could just about write a shader with. No such luck on Dx11/OGL with such things as of yet.

This has required me to finally defeat the spaghetti code which I had previously wrote, slimming things down in C++ and removing bloat for the porting. I have only ported to the pre-PBR branch of the engine - so really 2019 code - as a stepping stone to entering the latest shiny stuff once I know what the hell is going on. So far so good. Everything seems to run fine - except for my broken Dx9 shaders but that was to be expected.

I've also stuck my hand in my pocket and made a new, capital purchase. Only had it out of the box once for a quick test. If Google hasn't yet fubared my images, here's a quick pic below.

It's been an awfully long time since I've done any drawing.

 

I also used a 14 year old camera to get some pics of Comet Neowise.

It was my parents Golden Wedding Anniversary. 50 years! Albert Speer only got 20 years in Spandau Prison!

The Clip Show Episode Except It Isn't

It's been a hectic month. So hectic I'm going to have to make a filler blog post. But first some actually useful progress ...

I was helping someone out who was having issues getting the exported collision meshes to work whilst using the imported FBX format from Blender 2.8, to the open source Torque3D MIT Version 4; Preview Build 5.

Binaries of which are downloadable here:
http://ghc-games.com/SC/Preview4_0_bld5_win.zip http://ghc-games.com/SC/Preview4_0_bld5_lin.zip http://ghc-games.com/SC/Preview4_0_bld5_mac.zip

Or at least I thought that was what the issue was. It might have been something else. Either way, I successfully resolved this issue, real or imaginery, so I may as well take the time to share it.

 The secret is to use the same node system as you would for DAE (COLLADA).

It appears that when importing FBX format naming is more required than when just using DAE. Anyhow I had a play around with exporting FBX from Blender and here's what I found.

1: It really likes the DAE hierarchy if you want working collision meshes when exporting FBX.



2: If you import as SingleSize your object meshes require trailingNumber LOD else the collision meshes will not work. Weird right?

3: It will import working collision meshes when using DetectDTS or TrailingNumber (even when you have no trailingNumber) without trailing numbers for LOD. Did I mention trailing number in that sentence at all?

4: FBX is HUUUUUUUUUUUUUUUUUGE. Importing at scale 0.01 is the same as importing a DAE at 1.0.

So, on to the filler bit.

Headpats ...

In other news I ventured into the 21st Century and got the cheapest fibre optic available, finally allowing me to upload files 9 times faster than attaching them to the leg of a dead pigeon and sticking them in the mail box.

Here is a gameplay video which was 2 gigabytes that uploaded in 30 minutes. You still have to manually select 1080HD on YouTube or else it'll play the 480 pixel version, even if you got full screen and it lies to you about which quality version it's playing ...

So, that was the month the wasn't ...

Level Design And Level Redesign And Level Redux

Environmental level creation continues in earnest.

Level 4 is a grassland, inspired by the Asian Steppe. Originally the grass was going to be green, but the previous level was predominately green, so for variation I changed it to a more prairie yellowish-brown.

 The Steppe, home to deer-monster, Wendigo-type, thingies ...

Grasslands, by their very nature are somewhat ... well, bland. There's a lot of grass and low rolling hills with more grass and not very much else. The level is mostly wide and flat open spaces, with high, dark, rock walls to limit the playable environments outer reaches. I added a few extra rock outcrops to break up the vast expanse and created a central "hub" mountain which dominates the centre of the map to create a vaguely circular map with a lot of open space. To disrupt the near constant flow of grass I threw in a few autumn coloured bushes which help add variance to the monotony, and clumps of violet flowers for a colour deviation. The violet flowers are all clumped around the central mountain, whilst the red and yellow bushes tend to crowd towards the outer edges of the map. This helps the player orientate themselves a little to their position in the wide expanses.

Whilst planning level design I realised that as the game progressed, the levels were getting too big too quickly. I do a lot of heavy playtesting - because, well, no one else is, so it's the only way to spot issues with things. By level 3 I was getting lost quite easily in the various narrow alleyways of the canyon level.

Whilst developing the gameplay and enemies for each level, I had been using my test level with grid textures for each of the consecutive level maps. This meant that I had always been testing in the same space. When I started to create the actual individual levels I had multiplied the size.

I went back and redesigned the first three levels, first cropping them into a more square shape that would fit inside a 512 pixel heightmap rather than a long thin shape that spilled into a 1024 pixel one but didn't use up much of the available space. This saved on the amount of terrain that the engine had to render and precompile collision for, which in turn saved on the number of polygons that had to be drawn.

The original test level had later become the basis for the first level. This map has a traversable area of twelve percent. Originally I had started by doubling the size for progressive levels but this now obviously far too much. Going back, I redesigned the second and third levels with a formula to increase level size based on around 50%-70% of level 1 size. Thus level 2 now has a traversable area of >150% the size of level 1 at ~20% of the 512 pixel heightmap, and level 3 is >200% larger than level 1 with a traversable area of ~26%. By contrast level 3 has an area of  ~33% that the player can traverse.

Smaller heightmap sizes obviously reduce the amount of renderable terrain triangles and collision calls. For the first time I also used the "remove terrain tool", creating holes in the terrain in areas which the player would certainly never be able to see on-screen. This helped reduce the renderable area further.

Thick foliage.

Thinned foliage -50% polygons. Textures with less leaves show more transparency.

In the spirit of creating complex but also lean environments to reduce overhead I had another look at all my foliage. Whilst grass clearly needs all of it's polygons, I thought that I might be able to save a few on the bushes as the leaves near the undersides are not all going to be visible, obscured by those on top. I selected all the polygons that could be seen from directly above and deleted the rest. Depending on how thick the textures are with leaves, this thinned the viewable foliage somewhat, but for a saving of a whopping 50% polygons. Bushes are there to add movement in the wind and prevent the levels from looking barren, they're not there to hide the terrain beneath them so being more see-through is not a problem.

I tried the same idea with trees but the saving were so small - around 10% - that it didn't seem worth bothering with, so I left them as is.

And that, has been the month of May, 2019. Also the local internet exchange blew up and I was reduced to living a stoneage existence, devoid of memes, waifus, and all the important work related sites and indie game and engine development discord channel I rely on for day-to-day information about work.

In the meantime I rewrote various bits of code related to spawning the player in more open areas, reworked some effects and did manage to have a little play around with the (PBR) Physical Based Rendering package due for release with the next update of the engine.

PBR coming soon ... ish ...

Not entirely sure which bit of the development cycle I will tackle next. I might continue with level building as I am now 40% complete, or I might go back into 3D character modelling and finally replace that yellow placeholder cube with an actual player character.

In the meantime, have a look at some gameplay testing for level 4, The Steppe.

Tune in for next month's exciting instalment of the game development that never ends!

Goodbye Green Grid, Hello Darkness My Old Friend

I took a break from worrying about the minutiae of cat ears to do some level building. It's been a while - in fact around 4 years - of having a basic and rather blank grid for level 1. This has now been replaced with an actual level 1, containing ... you know, level 1 stuff.

 Old And Busted: Not Exactly Grey Box as Green Grid Box

New Hotness: Actual Art Assets 

This required actual models and textures and stuff, so I opened the long dormant folder of 3D models and 2D texture images which I have collected over the last nth years. One thing which I did get years and years ago was Forester Pro - a procedural tree and plant creator. Not only can you create a ton of different types of trees but create variations with a single click of a button. It automatically adds vertex paint which is then used in-game to add the shader effect for the wind. You can also add or remove elements like branches and leaves, though I did find that the save file dies horribly if you go too much off template. Never mind, just export out as DAE format that the Torque3D MIT Open Source Game Engine that I use, and of course can also be imported into Blender3D for making changes to the model more easily. Here I used the normal editor so that the foliage planes face upwards to avoid bad shadowing artifacts. I added an empty high above and had the normals aim for it using Directional mode, that way each plane gets a unified but still individual shadowing.

Wind Effect

Also good for grass 

 I have 10 levels planned, and the enemies all modelled and animated, though not the bosses. So I figured that I would need a few trees. One thing that I found was that the standard black alpha on textures didn't look very good. There is a free demasking tool which writes in colour information but instead I tried using different colours of the image to see what effect they had.

It transpires that alpha colour is important ... even though you can't see it ...

I also had a plant pack for Forester Pro and after exporting a few plants I amalgamated the textures into an Atlas texture to save on drawcalls, and created multiple plant objects to save on instancing.

Not seen here, mixed plant meshes

My next issue was lag. The first reason was some terrible maths which I had written and my code was attempting to spawn 1700 enemies all at once when it really only want 7. Yeah, that sort of thing is going to bring the computer core down to a shuddering halt. Next up was collision. I had set the size of terrain squares down to 0.25m which created a rather high 1568 collision calls per player, Ai and dynamic object. I played around with different settings and finally settled on a square size of 1, which seemed to give good definition visually to the terrain and only cost 128 collision calls which was a rather saner amount. SquareSize 2 would have only cost 32 calls but I preferred the look of 1 square per metre.

When you attempt to use ALL THE COLLISION CALLS

One thing which I had not previously thought about was the lighting and shadowing. Normally the camera looks through the environment and the shadows fade and lose clarity the further away they get. However using a top-down/isometric(ish) view meant that I could see shadow splits drawing across each other. A lot of fiddling with shadow settings later I finally got something that looked decent and transitions between shadow map splits were not really noticeable.

The joys of trial and error shadowMap creation with the helpful PSSM Cascade Visualizor debugging tool

As my first level is a graveyard featuring a very lazy mouse who is supposed to be the caretaker but rather neglects her duties in keeping the place tidy for her customers - level 1 enemy, the dead (DEEPEST LORE!) I opened up the old graveyard art pack which I bought years ago. Some of the model seem to have been rather hurriedly put together with a lot of opening faces - which is the sort of thing my OCD really doesn't like, so I spent a fair bit of time fixing them and amalgamating the textures into single Atlas textures for those big savings on drawcalls.

Blender3D's decimation tool got into the spirit of spookiness

I had noticed an issue with the terrain becoming washed out when the level reloaded. After much hunting around for bugs in the code I discovered that I had accidentally changed the file format for saving the terrain main texture to a low definition jpeg of only 90Kb. The default is a high quality DDS image so I must have been playing around, not noticed the difference in texture because it only updates on reloading the level, and then just forgot about it. Whoopsie!

Adding grass meshes that sway in the wind make the flat texture look a lot better

So, next up is furnishing and finalising the rest of the level and making it playable. The either on to the other levels or back to modelling catgirls.

Head pats!

Welcome To Space Year 2018 - Now With More Catgirls And FunBalls

We are so into the future, and it is only another 2 years until the Tokyo Olympics. I can't wait.

Soon ... (ish)

And so to the New Year, which began with great productivity (once the hangover wore off) and "Dry January" commenced. More on that later.

First up was going back over some old ground and changing things ... which to be honest, appears to be 90% of what consumes my development time. I had used a small number of open source/creative commons/CC0/CC-BY images. I ended up stripping these out and replacing them with custom imagery. The most used one was of a cat, which was changed to be a tiger.

I dropped the sole icon I was using from http://game-icons.net/ (a really useful resource) and replaced it with my own custom one. This had been for the "Tough Skin" powerup, which during playtesting I had thought was underpowered for a rare item and so doubled the amount of damage it stopped from 10 to 20 percent.

 

"Tough Skin" Rare Powerup, Now With Less Gauntlet And More Catgirl 

The overall layout of the player's interface/HUD went through another iteration, and a skull was added to the kill/gore gauge which fills up and changes colour until it completes level 4 and a Momento Mori is triggered. Upon this the player becomes invincible for 60 seconds and scoring multiplies by 8  (that's the old 4/8, death/wealth for the Far East), and all attacks now deal critical damage to enemies.

 Object which mounts to the player to signify that the Momento Mori has been activated, and they are now Shinigami, God of Death.

Kinda like this guy but you have to make your own atatatatatatatata sound

I also altered the textures for the Gradius style followers which can be picked up and upgraded via powerups, giving them each a little sheen which passes over them. They are little weapon platforms which follow the player around and increase firepower. I spent a while in the depths of C++ changing their start/stop movement to make them move much smoother than they had before.

I am most proud about getting this gif to loop seamlessly :P

One thing I noticed about collecting offensive and defensive powerups is that there could be a disconnect between the information displayed to the player and what the actual effect is. This is because special attack and defend abilities are triggered using an RNG. The more abilities the player has, the greater chance of an activation. However this doesn't mean that the last powerup will trigger next, so I changed that so that it always triggers on the next attack or defence - thus giving the player a clear idea of the ability of the object which they just picked up.

Collect "Magic Bullet" offensive powerup, immediately see it used on your next attack

And so onto FUNBALLS. If the esoteric words "RoR, /v/, Git Gud and Host When?" mean anything to you, then this should give an inclining as to what comes next.

This is a FunBall. You can tell it's a FunBall due to the word "FUN" written on it and it's murderous grin 

FunBalls are fun - okay, they're not really, they're bombs which some enemies will drop. I also intend to create an unlockable challenge mode when everything will drop FunBalls upon death.

I am using a slightly basic collision and physics system (hello rigidBody) for speed and convenience. FunBalls didn't look very good as standard objects due to sudden rotation changes when they bounced. To combat this I made the object a billboard so that it always faces the camera and used a scrolling texture to give the illusion of smooth, spinning movement. I then created four variations, leaving one central and rotating the others (off-left, off-right and upside down) so that when a number of FunBalls burst from a deceased enemy, they have plenty of variation but the player can always see the grin at some angle.

FunBalls in action! Audio has since been changed.

And upon all of this, there have been numerous little tweaks and changes to how things work, as well as much planning on the data of enemy types as the levels progress (though everyone is still a placeholder cube right now).

Did I mention "Dry January"? My performance at darts really suffered so halfway through the month this kinda happened ... 

Next up, more sorting out data and attack types for enemies, and some considerable reading up on this new fangled thing called PBR.