As we’re developing Double Destruction, we will be uploading blog posts as frequently as we can so you can keep track of what it’s like to VR Jam! Today’s development post is about how we came up with the concept and what our influences are.
25th February was the first ever SouthWest VR conference down in Bristol. We took along Smash Hit Plunder and our Gear VR’s down with two new comfort modes, new book UI, and a new game mode.
I also did a talk “Allow them to believe:Lessons learnt creating dynamic VR gameplay”, which I’ll attempt to go through now!
Categories
The “Shared Screen”
Demoing a VR game can be a weird experience. If you’re not careful you end up with someone blindly waving their head around, while a group of onlookers watches in bemusement. To turn this into a much better event for everyone we needed a second, shared screen to bring the whole experience together.
On Tuesday 2nd September we went to Bossa’s VR Meetup . Had a great time meeting some new people as they played Smash Hit Plunder. Scores were a lot higher this time around guessing as everyone was VR pro’s. What we did find was that everyone just loves the concept of the game, and that it was inherently fun! Thanks everyone.
So last week I had another post up on Develop in relation to the experiences I’ve had while developing in VR for Project Morpheus while I was at Sony, training games at Preloaded, and of course the work on Smash Hit Plunder.
Categories
Smash Hit Plunder at VR in a Bar
On Monday 28th July we showed off a much improved build of Smash Hit Plunder. It went down so incredibly well!
Gamesbeacon has a write up and gameplay footage.
Y Lle for S4C Welsh TV were there filming, and had a right laugh with our game. Nick nicely saying that our game was the best there, thanks! I’m sure Radial G will be awesome too.
Categories
Smash Hit Plunder revealed at LadyCADE
Friday 18th July was a big day for us. We crunched for 3 weeks to get from a paper design to a functional prototype that can give a snapshot of what Smash Hit Plunder will eventually be.
Categories
Digital test cards for games
Don’t you hate it when you’re writing some new image loading or texture drawing code but don’t have any suitable test images? I always waste lots of time looking for a “nice” image to test with, and often end up drawing something with distict pixel values so I can pinpoint where any given image loading bug is. With that in mind I’ve spent a few evenings working on a proper “test card”.
Sometimes you get an idea that’s a little bit oddball but for some reason you can’t get out of your head and just have to run with it. This has been bouncing around my head for the last couple of days and has just been translated into code:
I plan to extend this somewhat to make it more useful, like having multiple (cross linked) pages of stats, a logging page containing trace messages, and possibly a resource/texture/rendertarget viewer as well. Any suggestions as to what else to (ab)use http for are welcome. 🙂
After I upgraded to a 720p display format (rather than just 800×600) the framerate took a little bit of a dip on my slower machine. Understandable really as it’s drawing quite a few more pixels – 921k rather than 480k in the worst case, ignoring overdraw. I’ve spent the last few days optimising the renderer to see how much of the performance I could get back.
Firstly, you’ve got to have some numbers to see what’s working and what isn’t, so I added a debug overlay which displays all kind of renderer stats:
The top four boxes show stats for the four separate sprite groups – main sprites are visible ones like the helicopters and landscape, lightmap sprites contains lights and shadows, sonar sprites are used for sonar drawing, and hud sprites are those that make up the gui and other hud elements like the health and fuel bars. The final box at the bottom shows per-frame stats such as the total number of sprites drawn and the framerate.
Most suprising is the “average batch size” for the whole frame – at only 4.1 that means that I’m only drawing about four sprites per draw call, which is quite bad. (Although I call them sprites there’s actually a whole range of “drawables” in the scene, water ripples for example are made of RingGeometry which is a ring made up of many individual triangles, but it’s easier to call them all sprites).
Individual sprite images (such as a building or a person) are packed into sprite sheets at compile time. In theory that means that you can draw lots of different sprites in the same batch because they’re all from the same texture. If however you’re drawing a building but then need to draw a person and the person is on a different sheet, then the batch is “broken” and it’s got to start a new one.
To test this out I increased the sprite sheet size from 512×512 to 1024×1024 and then 2048×2048. For the main sprites (which is the one I’m focusing on) this pushed the average batch count up from 5.3 to 5.6 and then 16.2. Obviously the texture switching was hurting my batch count – 16 would be a much more respectable figure. Unfortunately not everyone’s graphics card can load textures that big, which is why I’d been sticking to a nice safe 512×512.
However further investigation found that the sprite sheets weren’t being packed terribly efficiently – in fact packing would give up when one sprite wouldn’t fit and a new sheet would be started. This would mean that most sheets were only about half full – fixing the bug means that almost all of the sheet is now used. Below you can see one of the fixed sheets, with almost all the space used up.
Along with this I split my sheets into three groups – one for the landscape sprites (the grass and coast line), one for world sprites (helicopters and people) and one for gui sprites. Since these are drawn in distinct layers it makes sense to keep them all together on the same sheets rather than randomly intermingling them.
One last tweak was to shave off a few dead pixels on some of the larger sprites – since they were 260×260 it meant that only one could fit onto a sheet and would leave lots of wasted space. Trimming them down to 250×250 fits four in a single sheet and is much more efficient.
Overall these upped the batch count for main sprites up to a much more healthy 9.2, reducing the number of batches from ~280 to ~130.
Good, but there’s still optimisations left to be done…