Introducing: PATOU! Since this year we are working on a new game about family, nostalgia and a big dog that helps you digging out mysterious ruins.
PATOU is a narrative adventure with puzzle elements. Our focus is on exploring surreal dreamscapes and understanding your fluff companion. In the upcoming months we want to share development news and other stories on Patou's own blog.
The game is funded by EFRE and the MDM.
By the way - if you're wondering what happened to the stealth game we were planning last year, don't give your hopes up yet!
(TL;DR) We’re working on a Thief-inspired stealth game and want people to fill out a survey!
We already talked on this blog about how we put Behind Stars and Under Hills on ice (with a big sad sigh), and that our next game project will be a Thief-like (1998 Thief, not 2014 Thief), but we didn’t get into much detail here. Instead we did a livestream about the current state of our new project, so have a look if you want to catch up. Now, the sandbox demo we showed in the video is finally available to selected testers!
While the difference to the version from the stream isn’t that vast, the playground level now has an individually created mission (with simple quests like “Steal 700 loot”) and offers a few coherent gameplay elements and situations. The geometry overall is super simple, with a lot of placeholder textures and models. Especially the enemy is still the skeleton from the Asset Store, which Friedrich has been using for nearly a year now, just because it’s so nice to look at and has a lot of personality. The level was built quickly with RealtimeCSG, a tool we will also use for the final missions, as it keeps the level creation inside Unity (in TRI, we made all the levels in 3dsmax) and its limitations work well with our chosen settings. Also, the lighting is all real-time for now (which results in a pretty high number of draw calls), as the pipeline for baking and integrating lightmaps is not ready yet.
For us it was important to create a level that demonstrates the “game feel”, and of course the basic gameplay. The sandbox-y nature is clear from the beginning as each room has more than one entrance and the mission does not enforce to do things in a certain order. Of course the whole level is pretty weird. Most jarring: the buildings were put on a big floating block. And the rooms don’t make much sense in their architecture. But we hope this also creates its own atmosphere; and at least with this demo, we put gameplay far before realism anyway.
While the AI will be “under construction” until the beta or even the final version of the game, the enemies already are dangerous and behave in sometimes unexpected ways, which is the heart of a stealth game: it only works well as a game if the danger is big (and preferably constant), but always manageable. Thanks to the players’ powers to hide inside shadows and use various tools (like projectiles or a hacking device) the latter should already be the case in our playground demo.
As we’re still trying to find out if the character controller’s programming is going the right direction and if the AI actually feels natural in its reactions towards the players, we decided against doing a full vertical slice. Which mostly means we’re trying to make sure we appeal to stealth fans for now, and not to publishers. This is obvious in how many things are missing, with the graphics assets already mentioned. But also the sounds are much too sparse for now, with a skeleton only generating footstep sounds, and sometimes a scream that should alarm other enemies. And we’re working on the plot and story in parallel to graphics and tech, but are still not satisfied with those yet, so they are also not part of the playground demo (only hinted a bit).
It goes without saying that a lot of the game’s gameplay mechanics are not yet implemented or even planned. For this and other reasons we created a questionnaire that we’d like to have filled out by stealth enthusiasts and gamers in general, mostly to see how other people see the genre and how important certain elements are. So please, dear reader, fill out the surveyand maybe even forward it to others. And if you’re even more interested, you might want to become a part of our Discord server! See you soon!
I like blocky graphics. Pixels, voxels, square tiles, grid-based walls - keep them coming! I guess this originates from my Lego-heavy childhood, and also from old computer games, where you could clearly see the tiles the game’s world was made of. And while I never was into Wolfenstein3D, I recently created my own grid-based ray-caster just because I do adore the aesthetics.
The same with Minecraft - it’s a game that is an inspiration even though I didn’t play it much. The blockiness makes the virtual world instantly more organized; it’s like you can play around with its pure atoms. Blockiness empowers - not only is it fun to be creative there (because the interactivity is rewarded with reactions from the game’s systems) but as a game creator myself I instantly “get it” and - leaving out the grindy details - want to try my own variation of the structure functionality.
This is why I wanted to go with block-based levels for Behind Stars And Under Hills. For me it also fit with the premise of the game - an Ultima-Underworld-inspired dungeon crawler should have visible floor and wall segments, and pixels too. So I created my own in-game level editor for Behind Stars - because, maybe, other people want to make worlds with this too...
Of course trapping a level editor inside a game that is never released makes the endeavour less than pointless. So last year I went and put some time into changing the code to work inside Unity itself, as a plugin, which was for some parts easy thanks to the extensibility of Unity’s editor, and for other parts hard because of nasty serialization issues. Nonetheless, bloed - short for “bloxel-based level editor” or simply “block-based editor” as “bloxel” probably won’t catch on - slowly came to be and is now available on itch.io. I wanted to use it for a Thief-like game, working title “Demon Thief”, and for that it worked quite well. (Though I scrapped Demon Thief in favour of our next game project.)
I nicknamed the blocks in the editor bloxels because originally, in Behind Stars, I called them voxels and that didn’t quite fit. I use complete meshes for the blocks (made with Blender), and they can have any shape actually, as long as it fits inside 1x1x1 units. It’s also possible to do some more creative texturing by having UVs smaller than 1.0, which means they can span over several bloxels, to break up noticeable tiling and add more variation. It’s also possible to assign each side of a bloxel another texture (inspired by David Pittman’s NEON STRUCT dev blog). Naturally you still can manipulate the bloxels during runtime, so it’s possible to have something like destructible environment.
All my “additions” to the voxel formula makes the bloxels rather unfit to optimize though. Of course I segment the created geometry into chunks, and the textures are merged into texture atlasses. Still, draw calls are high and need to be reduced with optimizations like static and dynamic batching, occlusion culling, baked light maps and so on. Downsides aside, I am proud bloed supports arbitrary transforms and prefabs, and the optional noise factor can look nice too. These are things the ingame-only Behind Stars bloxels didn’t have.
Will the development continue? I hope so - especially if a few more people are interested in it (i.e. buy it) and post their creations made with bloed. Right now I don’t use bloed for a personal project, although I have some ideas and plans for that. So its future might be a bit hazy, but in general bloed is usable already, and I certainly will react to any bug reports. If you want to talk about bloed, you can also do it in our Discord!