Our current game project PATOU is now on Steam, of course still Coming Soon™. But it's a milestone we'd like to share here. Apologies for not updating this blog more than once per year - we're writing small articles over at the Patou blog from time to time, and experimented with video devlogs and dev streaming.
Be sure to put PATOU on your wishlist, because that helps us with promoting the game!
(YouTube videos try to set cookies and contact Third Party servers!)
In other news we attended the A MAZE 2023 two weeks ago, and we had a blast to meet old and new friends, play extremely creative games, and watch some very cool performances. The new location (a repurposed crematory) was both vast and stylish, and thankfully the weather was great too.
We took the opportunity to showcase PATOU at the Open Screens for a few hours and gathered valuable feedback. In the end the game was positively received, even though most areas can be improved of course. Overall it was a great experience for us because we only saw the demo coming together just one or two days before the A MAZE - sharing it in this state was an emotional rollercoster.
If you want to discuss the game or anything else really, visit our Discord!
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.
rc-test, a ray-casting engine
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.
Wunderworld, a game/editor I made for Ludum Dare some years ago
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...
An early version of Behind Stars, made with bloxels
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.)
A level from Demon Thief
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!
A decade ago we were students of multimedia design at the Burg Giebichenstein, an art school in Halle, Germany. Probably our most memorable time there was when Peter Hann, who was part of the Sacred 2 development team, was brought in by Professor Bernd Hanisch and became our tutor for a semester. He gave lectures in game creation, and we could prototype our very own game ideas (Fascinated By Evil by me, and Mummenschanz by Jana). It was an inspiration to be able to talk to a game designer from the industry, who is also a very good technical artist.
Last semester, years later, we finally had the chance to do something very similar, but of course with our own "twist". Jonas Hansen, professor at the very same degree programme we were part of back then, invited us to be tutors for a semester project (“Kreatives Gestalten” - usually a free project where students can decide the focus themselves). We would think of a theme for the applicants to follow, and then support our students with advice and suggestions, and finally grade their results. An interesting opportunity indeed, and of course we said yes.
After a few sessions of thinking and discussing we decided for the topic “memories”. The title “Play Your Self” would emphasize that our course is about creating a game that tells of a personal experience, so it was narrower than the usual semester project proposals. 13 students applied. We were thrilled.
When the semester started, we asked each student to draw their portrait on a piece of paper, which already served a purpose of finding out how everybody saw him-/herself. We also had a much easier time remembering names and faces later on. Right after this introductory routine we did a play session - everybody had to do a short “Let’s Play” of one of 13 personal indie games we selected beforehand, and talk about it while playing. This would tell us how experienced our students were with indie games and art games.
The next week we made it personal. We tasked the students to bring along an object connected with a strong memory; ideally something small-ish and unique (both in terms of the object and the memory). They had to talk about it in front of the class, and then try to create a rough, short game concept for it. It would prepare everybody, us included, theoretically of what was about to be expected of this semester.
On the practical side we thought of a ‘game jam’ for the week after this. On Monday we presented a text by Christian Morgenstern, Der Zwölf-Elf, a very linguistical poem with twelve verses. We assigned each student one of the lines (the 13th got the title) with the task to create a room that conveys an interpretation of that verse. The room should tell a small story by revealing the line in the end, and allow the player to leave it. Amazingly, on Wednesday all the students could present a result, even though some of them didn’t know the engine well, or weren’t comfortable with 3D modeling. Interesting enough, a lot of the created rooms actually were open spaces (usually with forests).
We had to be pretty rigid in regard to the limitations of this jam: the room had to be 3D, first-person, and made with Unity. This way, we could mash all of them together into a single Unity project, in order to ultimately create a “hotel” with a lobby and 13 rooms. The final Zwölf-Elf game can be downloaded on itch.io.
(YouTube videos try to set cookies and contact Third Party servers!)
These sessions concluded the preparation part - from now on every student had to think about the memory they wanted to translate into an interactive game, and how they would like to achieve their goal. Some memories were very specific in time and place, others concentrated on a place only from the student’s general past, others on a person who is dear to them. Some games became 3D, others 2D. Two of the students tried Unreal more or less for the first time and yet succeeded - kudos! A highly interesting (and entertaining) mix indeed.
After the idea and concept phase we demanded timetables and weekly status reports - which sounds more strict than it was. We just wanted to make sure nobody was out of the loop, and everybody would be serious about their personal, emotional experience. That’s why we also set up a public blog, for everyone to post progress updates and musings.
At one point we assigned groups of three to four students who would then play-test the current state of their projects; which was something we already did with the Zwölf-Elf rooms. We felt this could have been done more often, but then again we are aware most semester projects are only playable shortly before the final presentation. It also didn’t help much that the pandemic was still going on, and after the first few weeks we had to move all consultations to Jitsi. Even though chats (e.g. via Discord) were available all the time, a presence at a real location would have been better for bonding and interim test sessions.
The final presentation at the end of the semester was held online too, and this time the other professors (which also were our professors back then) of the degree programme would watch. The presentation went smooth, because together with Professor Hansen we decided that our students should make presentation videos beforehand, instead of doing live presentations. This was because of the often wonky internet connections, and Jitsi’s subpar screen-sharing abilities.
(YouTube videos try to set cookies and contact Third Party servers!)
We liked all of the results; nearly everybody stuck to the idea from the beginning and could showcase a polished prototype representing their memory, and their abilities as designers, very well. We are super proud.
Would we like to be tutors again? Very much so! Alas, we also learned something: it’s a lot of work. Consultations with our students happened only once every week, but preparation work, discussions and other things made the job a lot more time-consuming, even though it was always fun of course. (Un)fortunately we have a new game project currently, and we need to do our own timetables and status reports for the next foreseeable months.
Hopefully we can show more of our project soon. From time to time we stream our development process, which currently consists of researching stealth games. And of course there's still our Discord!
