Showing posts with label isometric. Show all posts
Showing posts with label isometric. Show all posts

Friday, 12 February 2016

World Building Test And The Secret Of Grass

Onwards to world building. I had decided to dispense with the stock terrain and foliage systems, and instead thought of constructing each level out of custom meshes.
With the game's perspective being topdown/high-isometric, I had decided that polycount would not be much of an issue for the whole thing to run smoothly, as not too much of the game world would ever be visible at any one time. I intend to tonemap all of the world geometry with third-party app pureLight, though I've also used Blender to do this previously, and then set the in-game lighting to incorporate lightmaps, so that the diffuse/albedo map is influenced by the tonemap but the normal/specular maps are altered by the dynamic lighting.

Before I could getting cracking on world building, there was the small issue of coming up with a functioning work process, as well as load testing, and the awkward issue of how to get grass to animate without using the forestObject's moving foliage shaders. Players love stuff on screen, and if there's one thing they love more than stuff on screen it's moving stuff on screen.


How do I into grass?

First up, basic construction testing. I decided on a 10x10 mesh with multiple textures of grass, dirt, and rock - 1 drawcall per material. I was not particularly bothered about polycount for testing so there's a lot more geometry than needed. I wanted to create a few islands of grass and rock to make it look more interesting. Specular was initially somewhat overkill and really needed toning down to almost off, but just enough to create some very slight highlights. I modeled the mesh for some physical depth, raising grass and rock layers.



Not bad for a start but the edges of the grass and dirt were a little hard. Of course in real life, grass and dirt don't just fade into one another, but in video games things look odd without blending. I tried various levels of blends but found that just 2 worked fine for what I wanted. Spreading the blend over a metre seemed enough distance  to break up the harshness of the change from dirt to grass.



Satisfied with how modeling was going I moved on to grass and immediately hit problems. I found a grass image to use as a placeholder and covered the grass terrain texture in a couple of thousand planes for testing. With the game's high viewpoint, having straight polys looked bad, so I set about dividing the meshes and bending them over at an angle so everything leaned and tilted. Polys facing directly away from the main lightsource had some strange and frankly annoying blackness to their planes. Using an emissive material solved this - but then everything looked like a uniformed colour and became just an amorphous mass. Adding subscattering to the shadows helped to ease the harsh blackness of the polys but it still didn't appear as though they were being properly illuminated.



So off I went on an intrepid quest to find out what the hell was going wrong via insert-your-favourite-internet-search-engine-here. Normals were the problem. Foliage normals apparently need to point up to receive proper lighting. But alas the ancient 2.44 version of Blender from 2007 which I still use - because ... convenience - cannot into normal editing - however the new 2.76 version can. Luckily most of the hotkeys seem to be the same so it wasn't too difficult to pick up, and normal editing itself is just a modifier.

Goodbye horrible black stuff ruining the aesthetics of my foliage

I had decided that making an animated texture for moving grass would give the look I desired with very low overhead. I had created a huge level with over 9000 meshes for load testing, and just to see how bad it would be,  I used bone animation to move the grass polys and the framerate immdiately died to around 20 fps. So, just as expected then, back to animated textures.

I created a high poly grass mesh in Blender based on this little gem found on the internet (http://forums.torque3d.org/viewtopic.php?f=18&t=18#p53), and then animated it using multiple bones, and rendered out the frames. I tried various frame numbers and speeds, and it shouldn't be too much of a surprise that the more frames an animation has, the better it looks, so I settled on 32 frames. I found that the grass didn't really need much movement in the animation, and in fact looked better with less, rather than wildly thrashing about with higher movement. The renders also scaled nicely. Originally taken at 256 pixels, it gave a rather terrifying size of 8192 pixels, way more than older GPUs would want to cope with. It could be reduced via "nearest neighbour" to prevent blurring to 64x2048 and still look good.



One thing which I had noticed was an annoying uniformity of movement in the animation which gave an unpleasant  "swelling" effect. Setting different planes to different parts of the UV map meant that they played different parts of the animation and helped break up the regularity. I also decided to create multiple animations based on differing meshes and combine them all into a single atlas/mega texture. I ended up with 1 thick grass render with lots of grass stalks, a thinner medium one, and 2 thin small ones. I then combined the 2 small ones to be anew  medium one, and finally added the other medium to create a new thick mesh. All in all, this gave meanimations for 6 different sized grass clumps to help combat the sameness of just one animated texture. Combined together on a single 2048 pixel image, there was plenty of space for further cosmetic variations such as colour, lightness/darkness, saturation changes and the sort.
I had a little play around with alpha reference to see the difference have thick to thin grass made.


Quite happy with conquering the secrets of grass I moved on to load bearing. I had previously created a 1 kilometre level, filling it 10,300 copies of the mesh. Viewed in it's totality it was 119 million polys, 124,000 drawcalls and a mspf of 666.667 - which gave me a sudden urge to play Iron Maiden's greatest hits. However, even close in the result was 40 million polys and 5 fps. A quick check of culling revealed ... well, not as much culling as I had hoped. With the camera set back and angled a lot more was rendering in the fustrum than was actually visible. Of course during these tests I had no "Level Of Detail" for my 10K meshes. I made multiple levels of LOD and set up the options preferences so that they reduced polys and materials the lower you set it, but also LODed hard outside of the immediate camera view. In the end I had things down to show the highest LOD on screen all at once with 70 fps, 665K polys with 913 drawcalls and half of that is shadowing which won't feature as much once I start using lightmaps and the diffuse material filters the main dynamic light source.

I also tested less instances of meshes, combining 9 of them into a single object. This reduced the total number of meshes from 10,300 to a mere 1,160. Polys went up slightly to 772K, drawcalls fell dramatically to just 235 - a third of which was shadows, and fps rose to a thrilling 100+ fps. All of which was somewhat to be expected.

So here's what that all looks like with the additions of screen spaced ambient occlusion and a vignette shader around the edges. I think having the grass bent over a little more might help aesthetically, but I'm quite pleased with the result and the performance.



Tuesday, 2 February 2016

Swag Em Up - 100 Collectable Power-Ups

It took some doing, but I managed to design and code, a full 100 collectable power-ups. Most of the artwork is still placeholder but all bonuses, attributes, special attacks, etc work in practice.

They come in 6 flavours:
  • ATTACK - bonus event on striking an enemy. eg: critical damage, exploding attack
  • DEFEND - bonus event on being hit. eg: shield stops damage, retribution attack against enemy
  • TEMPORARY - boost to attributes for x seconds. eg: for 8 seconds speed x2, increased healing
  • PERMANENT - attribute increments. eg: increment health, speed, healing
  • PASSIVE - works passively. eg: cause damage on touch, enemies drop more loot
  • ITEM - Items are single use and player can use any item that they have collected when they wish. Can be good for getting out of trouble when your back is to the wall.
So here's some pics and videos of a few of more of them being tested. See last blog for previous ones.


 Bonus offensive machine-gun and grenade spam attacks.




Super Orbital Laser (anyone guessing the source of the name wins a free internet)



The Zone of Brass Monkies - slows all enemy who enter it.


Napalm Strike (need to work on those particles, not entirely satisfied with those flames)


And a quick test of shields in various colours.

I also spent some time reading through the code (this is why it's important to leave comments people!) and found a few things I didn't previously know about explosions - such as you can tie animated meshes to them. This help save a bit of overhead on things as in Airship Dragoon I had spawned "concussion blast spheres" seperately. So I decided to make the basic impact attack a little more interesting.


With the swag collectables coded if not modeled, next up is to test my ideas on how to actually model the environment and levels. And it looks something a little bit like this:



Thursday, 26 February 2015

Swag Em Up

New project: Swag 'Em Up.

I had been umming and ahhing about what to do as my next project. I had toyed with the idea of another strategy game, albiet less niche hardcore and more casual, but fancied putting my skills to the test elsewhere with something a bit more fast and furious with an infinitely shorter development period. Hence the Swag 'Em Up was born.

 Boxxy placeholder with ribbon trails

Swag 'Em Up as a gameplay genre revolves around rushing about, blasting enemies, and unlocking items and collecting powerups and upgrades which form the swag question. Rogue-like or possibly rogue-lite seems a good basis for this as randomizing items, placement and enemies should lead to varied challenges and unique replayability with new unlockables being available dependant on how previous play-throughs went.

Initially I'd toyed with the idea of a top down view but immediately found it rather boring visually, so I switched to a rather high isometric view of around 70 degrees. This showed off models better and gave more depth to the scene. Here's a quick visual explanation of the differences.



After deciding on my camera system I created a screen relative movement system. When input says up and right, the player's avatar moves up and right relative to the camera/screen. This works especially well with gamepad controllers which can increment the rotation of the control stick.

I coded a new cooldown system for weapons and sprinting So that abilities take a few seconds to recharge. My thoughts for player abilities were thus, light attack with no cooldown, heavy attack, evade (in this case sprint) and special object use. I created a few new systems to allow for permanent upgrades as well as temporary time based ones and a whole experience gain and leveling system which adds health and regen bonuses. Originally I had considered a cash system alongside score and XP to buy unlockable items but instead have opted for trading experience for them. This method involves the player deciding whether they'd like to spend their hard earned experience on powerups or let it accumulate for leveling, which grants upgrades of it's own.

And here's a little demonstration of what I've got after a month of coding featuring our very own cube placeholders. Camera relative control system, light attack, heavy attack, evade, cooldowns, experience gathering and leveling.

 Now it turns out that there is a minor issue with the control system - it's bloody difficult to shoot at anything accurately. This is not really helped by being a placeholder cube with no obvious centre of facing. I might add some sort of laser aiming object to help alleviate this, or I might split movement and direction into two seperate states, like in a twin-stick shooter.

In the meantime, there it is, the start of my new project: "Action Rpg Mecha Musume Catgirl Rogue-like Swag 'Em Up".

Monday, 10 March 2014

Progress 7DRL Challenge 2014 Update 1

Progress! There has been progress! ...
.. or alternatively I've gone mad and am halucinating it ...
... which could be possible, there was a reason that I'd never done a gamejam thingymajig before and that was for the exact reasons I've encountered.

Too much to do in too little time and everything going wrong ... so ... just like normal indie dev then! ;)

First up I created a new control system ... and it promptly died on me. This put me way back on my schedule - and that's without annoying IRL to also contend with. Creating an isometric camera system with zoom in/out went easier though, as did knocking up 3 classes of player for stealth, fighter and tank.

Having just pushed the v1.4 release of Airship Dragoon out of the door, I hadn't had any prep time for #7DRL and #proceduralDeathJam so it was very much going in from scratch. Procedurally generating a world/labryinth turned out to be a right old pain le derrière. This was mostly due to getting orphaned sections. Eventually it all came good.


Then there was a few minor problems with my models. Performance was terrible so I LODed it right back ... maybe I just should have LODed it at the start ... and then it's not like they'll all be visible anyhow but hey ... 

After a bit of tweaking and realigning pathways I had a 3D representation of the procedurally generated 2D map. It had taken the whole day when I was hoping for MUCH less, but at least it's now done.

If you really squint you can see the tiny player front and centre.


So, next up ... I might go back and spend more time trying to fix or just recode the isometric control system ... or I might just wade on with objects, items and Ai, next. Unfortunately I'm busy tomorrow so aren't expecting to get much done.