September 3, 2014

Triangular Pixels announces Smash Hit Plunder for Oculus & Samsung Gear VR

Filed under: Games — Katie @ 1:15 pm

On the announcement of Samsung's Gear VR device, Triangular Pixels would like to announce that their VR title, Smash Hit Plunder, is to be released on Gear VR.

Smash Hit Plunder lets players explore and wreck a dungeon, looking for as much treasure as possible. Rediscover the joy of smashing things, making a mess, and finding money down the back of your sofa, all without the job of cleaning up afterwards.

Designed from the ground up for the Gear, we’ve been working with Oculus and taking our prototypes on the road for user testing at VR events for a while now. Our initial DK1 build has had a great reception, and we’re excited to be able to finally show it off on the hardware it was made for.

We passionately believe in accessible VR, with a low barrier to entry and a solid, engaging experience. The Gear VR is a truly brilliant device. The touchpad is familiar and easily understandable, and the wireless design allows Smash Hit Plunder players to explore the 3D nature of VR without cables restricting them.

We hope to have a final commercial launch date soon, but for now we are working to a demo which will be released when Gear VR reaches the UK. Keep an eye on to see where we will be showing next!

Follow Us on Twitter;

Developer Talk and Smash Hit Plunder at Bossa’s September VR Meetup

Filed under: Games — Katie @ 12:43 pm

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.
I decided to give a talk about developers responsibilities, which seemed to go down well. Hopefully I’ll be available to give more designer talks in the future.

Here’s some photos from last night.

More will be added and video uploaded soon!

August 17, 2014

Virtual Reality posts published on Develop

Filed under: Games — Katie @ 3:53 pm

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.

So far we have;
Virtual reality with purpose shows just some of the many ways VR can be used beyond games.

In Maintaining presence - Virtual reality developers' responsibilities I discuss the issues the player has while being so absorbed in VR.

As we continue developing Smash Hit Plunder, I'm sure there will be plenty more lessons learnt!

August 4, 2014

Smash Hit Plunder at VR in a Bar

Filed under: Games — Katie @ 1:13 pm

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.

What was new for this build;

  • Walking line was changed from a green line, to little pulsing feet so to remind the player that their movement is linked to this line
  • Hands! Left hand automatically grabbing loot and right hand showing what the player is grabbing hold of
  • Watch Timer - just look down to check the time left, rather than having to look up on a wall
  • Fixed bookcases, so it's now a lot easier to remove books and make more mess
  • New pretties, such as pixelated particles for items smashing and flames, fog, smoke
  • Lots of invisible fixes! For example, there were a fair few collision problems due to Unity automatically giving scale to newly imported items

What we learnt;

  • Fortunately still no one strangled, though taller people are a struggle for me
  • Mouse still isn't the best input, people assume it's a motion controller - but the simple control scheme and approachable gameplay & graphics are really helping a lot of newbie players try out and enjoy the game
  • An awesome bug where if you double click on the start game button, it loads the level twice... breaks the frame rate, but can function.. even with double the props
  • The Watch Timer on the hand the player doesn't control means that it disappears often when the player is trying to view it, will suit the right hand more

Whats coming soon;

  • A gameplay trailer!
  • Touched up artwork!
  • Finally getting this website updated! (Just waiting to fill out content on the new one)
  • Dungeon & different modes design - it's exciting!

July 19, 2014

Smash Hit Plunder revealed at LadyCADE

Filed under: Games — Katie @ 4:49 pm

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.

Our VR "tear-it-up" was revealed to the general public at LadyCADE, Loading Bar, London. We had a lot of keen players, both new to VR and otherwise, who kindly gave plenty of feedback which we will be moving forward with. Otherwise, people loved it!

We will be hoping to attend VR in a Bar on 28th July 2014, and Bossa's VR Meetup 2nd Sepetember.

The page has been updated with some new screenshots and photos from the night!

Otherwise, an amusing quote from the night;

"It's like Super Minecraft!"

See the games page here!

July 10, 2009

Digital test cards for games

Filed under: Development, Graphics — JC @ 8:06 pm

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

TV test cards are a rare sight on broadcasts these days, with most digital channels choosing to just have a blank screen when a channel is off air, but pretty much everyone in the uk will have the famous Test Card F burnt into their retina at some point. Test card design is rather facinating, as all the various elements (blocks of colour, diagonal stripes, etc.) are designed to allow particular elements of a broadcast or tv configuration to be tested and tweeked.

Most of them aren't relevent to games though, since we don't have to worry about scan amplitudes and all that mumbo jumbo. Mostly we're concerned about getting binary data off disk and accurately displaying that on the screen (dealing with file formats, endianness, and display surface formats in the process). So while Test Card F is nice and iconic, it's not really suitable for our use.

Here's a couple of my old (crude) test images:

They're not bad, but by todays standards they're a little small, the nicer Tails one is an awkward 48x48 and neither of them are good when you're trying to debug file format, image pitch or similar issues since the borders and colours aren't terribly helpful.

With those issues in mind, here's my new test card:

This breaks down as:
1. Well defined an unique border pixels make it easy to see if you're displaying the whole image or if you've sliced off an edge accidentally.
2. The main circle shows is for judging aspect ratio, and making sure you've not accidentally streched or squashed it.
3. The checkered edge markings are every 8 pixels, so you can line things up easily.
4. Various pixel patterns in the corners for checking 1:1 pixel drawing.
5. Colour and greyscale bars and gradients for general colour/gamma correction and to highlight colour precision issues.
6. Ticks mark the center of each edge for alignment.
7. Tails is always cool. [grin] Replace with your own favorite character as you see fit. The image and the text make sure you're displaying it at the correct orientation and not flipping or mirroring it.
8. The empty box at the bottom is left blank for you own logo or text.

One nice "feature" is the very outer border, here's a close up of the top left corner:

The start of the scanline starts with easily identifiable red, green and blue pixels (which show up as nice round non-zero, non-FF, hex numbers in a debugger's memory window) which are similar to a text file's byte-order mark. Just after that the desaturated colours spell out (again, when viewed in a debugger's memory view) "RedGreenBlue TestCardA 256x256". Of course if you're actually loading from a BGR image format that'll just be a row of junk characters, so directly after that the message is repeated (this time "BlueGreenRed TestCardA 256x256). This allows you to easily identify if you've actually calculated the start position of the image header from your image file and that you're reading it in in the right format and endianness - if you can read "BlueGreenRed" when you were trying to load a RGB image, you know you've messed something up somewhere. :)

The top right has a similar terminating series of characters:

This time it's a slightly different hex pattern for the numbers so you can distinguish the start of one scanline from the next. Similarly the rest of the image has two distinct colours all the way down the edges. These are particularly useful when debugging misaligned image data or pitch issues. The bottom row contains the same encoded messages for those crazy image formats which are stored bottom up rather than top down.

So there you go. Use it, modify it, abuse it however you see fit. If I get chance I think I'm going to produce a few variants for lower resolutions (maybe 128x128 and 64x64) plus RGBA versions for testing alpha channels. And suggestions for improvements or tweeks are welcome.

Licensed under Creative Commons 2.0.

May 7, 2009

GET ‘/ RescueSquad2 / RenderStats’ 1.1

Filed under: Development, Rescue Squad 2 — JC @ 12:07 am

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:

Yes, I embedded a web server inside of Rescue Squad and as well as static content (like the images) it can serve up live render stats direct from the game engine. I'm pleasantly surprised how easy it was, it only took about an hour to grab NanoHttpd, integrate it and slightly tweak it to also serve a (semi)hardcoded stats page.

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. :)

April 27, 2009

Renderer Optimisations Part 1

Filed under: Development, Graphics, Rescue Squad 2 — JC @ 5:30 pm

After I upgraded to a 720p display format (rather than just 800x600) 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 512x512 to 1024x1024 and then 2048x2048. 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 512x512.

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 260x260 it meant that only one could fit onto a sheet and would leave lots of wasted space. Trimming them down to 250x250 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...

April 15, 2009

HD Rendering Is The New Black

Filed under: Development, Rescue Squad 2 — JC @ 11:55 pm

I decided that the searching aspects of the gameplay are largely ruined by showing a larger area of the map at larger resolutions, so I've ruled that out as a possible way of dealing with multiple resolutions. Instead I've decided to pinch a trick from console games - the game world will internally always be rendered to a "720p" texture, and then that'll be streched over the full screen to upscale or downscale to the native resolution as appropriate.

I say "720p" because (similar to how tvs do things) there isn't a single fixed resolution, instead it'll always be 720 lines vertically, and the number of horizontal pixels will vary depending on the aspect ratio. So someone with a 16:9 screen will have a virtual resolution of 1280x720, whereas those on 4:3 displays will have 960x720. In windowed mode the virtual resolution always matches the physical window size, so you still get nice 1:1 graphics when viewed like this. For fullscreen the streching may mean you'll get some loss of sharpness but doing it manually in-game gives much better quality than letting the user's TFT do the scaling.

The menus are also drawn over the top with a 720p virtual resolution, but without the render-to-texture step (they're just scaled using the projection matrices). The HUD is the exception to the rule in that it's always rendered over the top at the native resolution instead of the virtual resolution. This is possible since the components are all relatively positioned according to the screen edges.

Different aspect ratios are also handled tv-style in that anything less that 16:9 has bits of the edges chopped off. That's not a problem as it'll just make those with 4:3 displays a little more blinkered. And to avoid having to have scalable menus or multiple menu layouts I just need to keep the important stuff inside the center 4:3 area, which is easy enough now I've got red guidelines to mark off the areas for different aspect ratios.

I think it all works out quite nicely - the code stays (largely) simple because it's all dealing with a single virtual resolution, the whole game looks better because it's natively at somethingx720 instead of 800x600, windowed mode still looks nice and crisp with 1:1 sprites and everyone gets the game in the correct aspect ratio - even in fullscreen.

April 13, 2009

Ooo, pretty…

Filed under: Development, Rescue Squad 2 — JC @ 12:32 am

So I was screwing around with some random bits of polish in the game and realised that I havn't tried fullscreen since I got my shiny new widescreen monitor a few months back. Unfortunately since the game is always rendered at 800x600 (and therefore a 4:3 aspect ratio) it looks a bit rubish when streched over a 16:10 display.

An hour of hacky tinering and it's running at the native res and aspect ratio, and the results are rather pretty I think:

(click for full size version)

I was surprised to find that only a few things were resolution-dependant. The HUD was the most obvious, since it used hard-coded positional values, so it now uses relative offsets from the screen edges. The menus are all borked too, since they're hardcoded to 800x600 so end up huddled in the bottom corner, I'll worry about them later.

The problem is that I think it breaks the gameplay - searching and exploring the map is a large part of the fun and challenge, and you don't get that when you can see half or a third of it on screen at a time. In fact it makes some maps laughably easy. But visually it looks so good I'm not sure I want to let it go.

Decisions decisions...

Newer Posts »