Sunday, 30 June 2019

Assimp Does Magic Stuff And I Get Distracted

This was a bit of a surprise.

 That says Blend file that does

Whilst playing around and looking for bugs in the latest beta of open sourced Torque3D game engine, I accidentally imported a BLEND file from free open source(ish) Blender3D modelling program. Obviously this by accident, because I would never have thought that it would work.

I had found some ripped game models and other sculpts (see Tifa above) and was looking at them in Blender3D for modelling reference. I had experimented with various export options and was loading them into the engine when I accidentally double clicked the Blend file rather than the exported DAE file. Et voila, it actually loaded with all materials correctly mapped.

This is due to the new Assimp importer which appears to be able to read pretty much anything and import it because magic.

Literally my understand of how Assimp works ...

Assimp also comes with a metric ton of options - none of which I really understand so I just kept using the defaults except for maybe rotating the up axis to Z when needed - and it kept importing models fine as long as I had multiple mesh objects set to be read as a single sized LOD.

When the Beat-Em Up waifus are extra thicc

I had tried various other model formats and found FBX and BLEND to be the easiest at automagically loading the corrects textures into the material slots. Amusingly - or not as the case may be - the original DAE importer was the worst and created the most hassle. Not all the models I had found on the internets had their textures setup for a standard PBR material, hence the rather off colour Chunners.


I had also seen someone using the normals editing tool in Blender in a way that I had not thought of before. For foliage and tree leaves they had placed the mesh inside of a huge sphere object and then targeted it. This made the leaf faces orient outwards to the nearest sphere point. For my current project all leaf and foliage mesh faces are orientated nearly vertically upwards, targeting a node high above, because that's pretty much where the player's camera is for a top-down perspective.

No normal editing target->Vertical target->Spherical target

Did I mention distraction? Yes I did. I had been harassed by "The Idea Fairy" and suddenly had the urge to make a Dieselpunk Ace Combat style game. I ended up writing up a design document and fairly in depth statistics of how the whole thing would play, utilising real world 1930s and 1940s aircraft. I imagined it would play rather like the old Freespace space combat simulator, only in high altitude clouds rather than space. Aircraft would ... well, aircraft, and airships would make up an equivalent of a real world navy. I also ended up playing through Freespace 2 and the original Freespace mod for it. For the first time ever, I have a state of the art gaming PC and use it for playing 20 year old games.

This thing needs keeping on a short leash ...

So that was the distraction that stymied this month's progress. I did however get some work done on the current project, the one that I am supposed to be working on, by transferring some heavily used scripts for targeting to C++ code to take a bit of weight off the processor when they are called so often. I also added went mad for statistics and added rankings for player performance on to the already percentaged data. I went for the Japanese obsession with S which may or may not mean SPECIAL, so the highest rank is SSS, SS, S before getting into a more standard alphabetical descent, and it goes down all the way to F for FAILED MISERABLY.

Yo Dawg I heard you like Statistics ...

Of course the real reason I did all of this stuff was simply to avoid having to model 3D hair because it's boring. Yep, that was it. An entire month of obfuscation to not doing something that is time consuming and dull. I also got poisoned with a chemical gas leak for two weeks having had an engineer out to investigate a gas leak, then getting a methane detector thinking that it was a gas buildup in the drains before eventually finding the source leaking out of a vat, and I was also immobilised with a back injury for another week, which was caused by just bending over the sink. So not a great month in general.

Next month, getting back to what I should have been doing this month ... allegedly ...

Friday, 31 May 2019

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!

Monday, 29 April 2019

Placeholder Game Level Finally Replaced With The Real Thing

Well, it's been long enough, and in fact seems like forever, that my blank, grid box test level has been on show - but no more! We now have actual game play in actual game play levels!

We also still have Placeholder Player Cube ... but, one thing at a time ...

Starting with level 1 the environment is a dark and rather neglected graveyard, where the dead sleep peacefully ... at least until the player turns up and annoys the hell out of them all (DEEPEST LORE).

And here is a rather long video of the whole thing in action, save for the obviously missing parts of an actual player character and level boss, both of which are currently still placeholder cubes.

But now that we are actually into level design, I am moving quite fast and this month have managed to produce a whole 3 finalised levels.

Behold level 2, The Primordial Forest at dawn, home to ancient plants and even more ancient and decidedly angry velociraptors ... so angry some of them shoot fricken laser beams out of their fricken heads.

And here's a slightly shorter 7 minute video of the level in action. I noticed afterwards that my dinosaurs where not exploding properly and should have been throwing more splatters about. However I had a wrongly named datablock and so the extra gore was not showing up. This has since been fixed.

And finally we have level 3; which I based loosely off pictures of Wulingyuan canyon in China, where the canyon has steep sides of light coloured rock with darker, green vegetation hanging on to every conceivable flat area.

And here is a slightly more reasonable 2 and a half minutes of game play.

In the more cramped confines of the canyon level, I noticed that the enemy spawning often grouped up together at one end of the screen. To create a more even distribution of enemy starting points, I wrote a little algorithm to target the player with the least nearby enemies and then find which cardinal direction (north, east, south, west) had the least enemies and spawn new ones there. This helps to prevent the enemy all starting to one side of the player and spreads the distribution of new enemies out more evenly.

So, their we go. Indie game development is painfully slow, especially for the One Man Army, but once ready to start on creating the actual environments, I have managed to complete 3 levels in one month. That's 30% of the levels done.

Next up, more environments to complete before seeing about replacing the placeholder cubes of the player and boss characters.