SEEN / PLAN / DONE / contract work not included
- UPBGE is a game engine for Blender. Might be worth a look, even though it uses Python - unfortunately the documentation isn’t finished, and I’m really not a fan of that.
- I watched a video about the level design of It Takes Two, and it was pretty interesting. While I’m on the fence if I like the game or not, I can’t say it isn’t well made.
- During a productive meeting with voxel we assessed the current state of the 7dfps project (still no real title) and also defined the features we want to do for the next milestone. We now reached the MVP as I added quite a few sounds for the player, the enemy and the loot items. I used oceanaudio mostly for this, and it is nice, but absolutely underpowered - having several tracks and being able to combine them is such an essential feature for me. So I checked some other audio software and in the end came back to Audacity, as most other software has a price tag and/or is not really suitable. But as Audacity is still a bit sketchy, I will use the fork Tenacity instead. There are no releases yet, but the nightly build works fine so far.
- Uploaded v0.7.2 of bloed - the tools window was stealing keyboard input, hopefully this release fixes this problem.
- I reactivated the Health component in the 7dfps project, and now the player can die! Even from falling!
- For today’s game dev stream I extended the 7dfps project by adding doors and collectible loot, after I created a simple security cam enemy yesterday. An interesting problem arose when I made the doors unclosable as soon as something was in the way - be it the player or an item. I used a trigger for that. But when the player collects the item that is in the way, it wouldn’t “exit” the trigger, the event doesn’t fire. Apparently, Rigidbody.enableCollision is the solution to that (which of course only works when there is a Rigidbody). Setting it to false actually also calls the OnTriggerExit() method - something which Destroy() and Collision.enabled = false surprisingly don’t.
- Another “interesting” problem was creating new terrain tiles, which I currently evaluate for Patou, mostly because I don’t want to have a gigantic terrain right from the start, so I want several smaller terrains. And then this: Unity is stupid when it comes to test their own things, thus terrains don’t allow digging holes when one uses them out of the box; instead I had to move them 100 units down, and use “Set Height” to set the height to 100 of the first terrain (so it’s back at 0 level). Which works - but extending the terrain now with new neighbour tiles only creates them with 100 unit steep slopes. To get around this, I copied Unity’s terrain tool code (namely the FillHeightmapUsingNeighbors() method) and changed it a bit so it would recreate the heightmap based on the absolute origin. Which is pretty dangerous, because there is no undo, and it changes the assets directly… always remember to use your version control!
- I tested bloed on Unity 2021.2.4f1 today - and it almost works out of the box. Apparently there is a problem though with the GUI inside the scene getting key input when it shouldn’t. I will look into this soon enough.
- For the 7dfps I’m currently evaluating AI solutions, and I think I will just try to use SUS as much as possible. It feels powerful enough to create some interesting behaviour, but still not too complicated. In the last few days I also added things like being able to collect items (a bouncy test box for now), and the light gem for the player.
- I streamed a bit of Terrobot X’s development. Right now it’s becoming some kind of “fantasy console”, so there was enough stuff to show for the stream; I mostly just added input and line drawing functions, so I could emulate a simple platformer and a simple Pong thing.
- Some fog was added to Patou - namely “Volumetric Fog and Mist” by Kronnect, mostly because it supports “fog of war” out of the box. After having a lot of problems with it in my own scene I wrote in their support forum - and yes, the problems were on their side. Thankfully a fix came not much later.
- Bloed had a very interesting bug - playing the game in the editor would attach all the meshes to the currently opened prefab. Of course it was a bug in my level code - but it’s a bit strange how Unity wouldn’t spit out errors when ingame code would change a prefab. Yes, there is a warning *beforehand*, but only in a very vague way.
- Two days ago I also gave Pry a little update: she does auto-crouch when a ceiling too low if in front of her. It feels pretty smooth!
- As voxel uses bloed quite a lot more than I ever did apparently, he finds enough bugs for another update. I set the version number to 0.7.1 because in the end it’s an extension of the previous release, which was all about bug fixes too. This release fixes transparency issues, and a lot of problems when new textures are added to the project.
- I uploaded some bug fixes for bloed, which means it’s now v0.7 - removing and recreating prefabs’ meshes works now, and UV sets get serialized correctly. Oh, and there was some issue with rotating textures, which sometimes was just ignored by the TEXER.
- For Terrobot X’s code editor I wanted to have more control over when Unity’s UI system is actually allowed to take over the keyboard (to switch between controls and activate them), so I had to set the selected game object manually. Stuff like that. While I didn’t need the link below, it might become useful later on.
- Apparently there are more bugs in bloed than I thought. While I fixed some glaring issues with the Helpers methods in combination with prefabs, I noticed that the TEXER still has problems with setting different UV sets, or rather with saving them. I might fix that bug this year even...
- I’m pretty happy that I could finish my Adventure Kajam entry, The Last Dream. (Zauberwald is the name of the “engine” for it.) In the end the story is much shorter than I wanted, but that’s a good thing because it actually is enough already for a challenging game. Of course tester feedback is needed, as I am sure some things are not obvious at all, and so it will be a bit of a frustrating experience. In any case, the game does what I wanted it to do - motivate me to create this tool (for further use later on), and a story.
- I extracted Pry’s character controller for the 7dfps project. It’s missing quite a few things now, even though I had to copy a lot of files. The main difference though is that instead of Rewired the extracted version uses Unity’s new input system. It’s mostly working okay and is flexible, but it annoys me how cumbersome it is to implement a simple “hold”/”pressed” behaviour for some input.
- voxel and I plan to participate in the 7dfps, and already wrote down a concept for a randomized stealth game. Let’s see if it works out this time! (I would love to see something like Eldritch more focused on stealth.)
- First steps were done towards Patou reacting to other things (sensing them etc) in the world. For now he just stands still at an object that is marked “danger”; later on this could be used like this for example: There is a murder of crows guarding a place, and the child won’t be able to get past them. Only thanks to Patou’s constant barking in the direction of the crows they will fly away. When he stops barking, they come back. So for a while, the child might have to do things alone.
- I uploaded version 80 of Pry, just to have a feeling of progress. I am not sure what to do next for it, the AI most likely needs an overhaul, and I could use SUS for that, but that would be some major rework probably. In any case, one could make a real prototype now with the things that are already implemented.
- Improving, but not really progressing, some projects: Patou’s Simple Utility System (SUS) got better debug display (considerations now can have identifiers), Pry now leans her body with a SphereCast check so she can’t look through the wall anymore when climbing a ladder, and Zauberwald has a better, desaturated color scheme now, and a visual hint for when you can drag a window.
- So for Patou I could combine SUS with PandaBT now as I wished, and also added some simple debug display. It’s not super convenient because one has to find out which consideration is which, but other than that it should help with development.
- I worked a bit on Pry’s leaning, so the player can also lean forward (by pressing both Q and E at the same time). It’s cool, but has a major bug - when climbing a ladder it allows you to look through walls. Disabling leaning while climbing ladders would be the easiest solution, but that’s a bit lame. So I will try to think of an alternative.
- I created an extremely simple system of utility theory “AI”, for Patou and reusable for other projects. I call it SUS. Combining it with PandaBT is possible, but this is very awkward, as there is no way to change a tree during runtime without overhead. So either I write my own behaviour tree system too, or choose another plugin. There are several free solutions, but PandaBT is just so nice to use and debug. And it seems the developer is back from the dead and plans to update it.
- I don’t think I will submit anything (playable) to the Adventure Kajam. While I’m happy with the state of the Zauberwald “engine”, and while I’m not that bad with coming up with a potential story, actually writing down this story, and creating puzzles, takes quite a while. Too long for the time that is left, and I am not motivated enough, unfortunately.
- I replaced some Time.unscaledDeltaTime with Time.smoothDeltaTime in my code of Pry, and it definitely helped with a smoother camera. Let’s hope it doesn’t break anything, as this is not working with a time scale of zero anymore.
- Again, after so many times, I’m back to thinking about how to do the AI for our games. This is for both Patou and Pry, and while the two game concepts are vastly different in their requirements - Patou has only one single character who doesn’t try to fight you, while Pry will feature several NPCs in pursuit of the player - I think there are a lot of intersections in functionality. Maybe it means I just have to modularize some parts. In any case, right now I want to get back to utility theory - at least for the decision making process of a game agent. Because this is the part that annoys me the most with the current AI of Pry’s enemies, even though they mostly behave how they should. Still, my solution of mixing some state machine into their behaviour trees was never a good solution.
- Terrobot X, although now a side side side project, got a small update - the code editor (still the only piece actually existing of the “game”) now has automatic scrolling when the user moves the caret. It had its pitfalls, thanks to the dynamic nature of the content of the scroll rect, but for now it works. The second thing today was line numbers. I can finally think about the actual game, maybe.
- Right now, each room in Zauberwald has its own scripting engine. This way each engine can have subroutines with the same name, called RoomEnterFirstTime, CombineThings, etc. I might change this though, because room-based actions can potentially overwrite general actions (e.g., combining an object with another one could have a different effect in room X than in other rooms), and with the current solution I get annoying boilerplate code. For example, I have to set a Boolean value called “CallGeneralAction” to false every time something in the specialized subroutine happens.
- Patou now catches a ball thrown by the player. Well, it’s not really Patou, but a red-tinted clone of the player character. Anyway, sooner or later I will have to think of a good, extendable system for Patou’s AI states.
- While I still might choose A* Pathfinding Project Pro (God, that name) later on, right now I think Unity’s own navigation mesh system is fine for what we want in Patou. We don’t even have enemies in the game, just one single character following the player. The off-mesh links just work out of the box, more or less, and the fact it’s all part of Unity makes it easy to use, in contrast to A*PPP.
- In Zauberwald, the Rooms’ windows can now be dragged around freely. (That reads a bit strange, without context.) It sounds simple, but as soon as you have the different configurations for anchor, pivot, scale, etc. of a UI element to consider, it becomes a nightmare if you want to prevent windows from getting dragged out of view. In any case, using RectTransform.GetWorldCorners() for retrieving the actual size and position of the windows was the solution, at least in this case.
And I went a bit further and added support for pictures. They have to be in the Resources folder, and get added by name, for now. The tricky part was making them resize to the layout correctly. In combination with the stretching RectTransforms, it’s very complicated. Instead I just set “Preserve aspect” to true and make the Images extremely wide or high. Hacky, but works for now.
- I planned to support more than one window per room in Zauberwald, but after a while of tinkering it didn’t really seem to be a worthwhile feature. So I ditched and vastly simplified some logic. There’s also a configurable limit of items on the floor for each room now. Overall the project is on a good way, the biggest hurdle right now is getting images to work - and the story as my actual entry for the Kajam. My current idea involves social media, inspiration, and cyberspace.
- A lot of things happened for Zauberwald, and one could now make a little story with it. It features a functional inventory (more or less), switching between rooms and interaction with things - examining, using, combining. Some work went into polish, like fading text out and in as soon as it changes via script. Rooms each have their own Small Basic interpreter instance. I really should think of a short story idea now.
- After tweaking it for some time I think I will stick with the “Fundamentals” character controller for Patou (or rather: the child) for now. I also imported PandaBT again, because after researching other AI solutions for the dog behaviour I think most of it would be too bloated for a single NPC “just” following a player. Plus I really like PandaBT’s scripting language approach instead of the node trees that often can get too big, and a mess.
Though I still think I will keep an eye on SGOAP, for Pry’s enemies. But I will probably never be content with how the enemy AI works in this game anyway …
- Zauberwald now has multiple pages - and dragging of individual words. Looks interesting so far, hopefully it translates to a somewhat good game.
- For Zauberwald I had the idea to let the user move the text by letters instead of scrolling. It looks far worse than I thought, so I got rid of the algorithm. I still don’t like the idea of scrolling though. My next plan is to support multiple pages instead; very crude, but effective.
- For some time I noticed that some enemies don’t hear anything in Pry - seems like a bug introduced after version 71. Turns out it was a simple, but hard to see copy & paste error; I once read in an analysis that those happen extremely often, so yeah, I can confirm that.
- I improved the support for the tabulator key in Terrobot X’s code editor. Lines can be indented and so on. At this pace though I don’t think this will ever become a full game. Nonetheless, I always wanted a more robust code editor for my code-based games...
- I dug out Zauberwald, the text adventure I wanted to create with my brothers, for the current Alakajam Kajam (theme is “adventure”). Basically I did a reevaluation of how I want the text interaction to work, and for now I’m confident the approach I used in CitApp and now Terrobot X is probably the sanest way. (Which means using “text chips” for each word, instead of a whole text block.) More or less. There was a bit of parsing to be done, but now I can slowly create actual gameplay, maybe.
- The options in Pry are mostly working now. Who thought that Colorful, an ancient Unity plugin for some post effects, is still working, and the best way to change brightness and contrast directly? Of course this is all rudimentary, so other options will be added later on. If ever.
- Undo and redo were added to Terrobot X’s code editor. Another case where I reused code, this time from bloed. The implementation in Terrobot was still tricky, because my approach of changing the text dynamically made me think around two corners, and even change some stuff. For example, for deleting a character via backspace or the delete key I now select the character and then delete the selection. This was necessary because there were a lot of edge cases with line breaks.
- I copied a lot of code and UI from Behind Stars and Under Hills over to Pry, because I wanted to add a start menu. I also copied the debugging menu (for quick noclip stuff and so on - not a console) and the settings menu, although none of the options (brightness, etc.) are working yet. But at least Behind Stars wasn’t a total loss this way.
- I did a bit of work on Terrobot X’s code editor - who’d known adding support for the tabulator key as an afterthought would be a bad idea?
- I tried to fix a small bug in Pry: Enemies that got knocked out would sometimes die just by falling over. The problem was their low pain tolerance (which is there for them being killed by attacks instantly when they’re not in “search player” mode), so just hitting the floor or even colliding with their own bones would instantly kill them. It’s actually a hard problem to solve, as there are so many contradicting rules - in the end it’s a lot of tweaking of different values, instead of one hard solution.
- I did some small things for Pry. It always annoyed me how jerky the movement is when climbing through a 1.5m high window (because it’s smaller than the player, but they still fit through). With my current solution of automatically letting the player crouch when they climb through the window it should be smoother now. The same with hiding under tables - it won’t work against the physics engine anymore. (Mostly.)
- Things I’d like to see in Terrobot X’s code editor soon-ish: better support for the tabulator key, copy & paste, (smooth?) scrollbars or at least pages, maybe even support for several carets. Overall I will have to rework the lexer for text coloring based on the syntax though. Sooner or later.
- Finally back on vacation, and already working on a lot of stuff: Terrobot X’s code editor now has text selection (of course this is a minor feature, but important nonetheless), and we do more and more planning for Patou (especially the story).
- Finally watched noclip’s documentary about Prey - the Arkane Prey from 2017, that is. It’s actually a good game, especially because it is a lot of game. But I must say that I also understand why it didn’t sell that well. Especially when it comes to the “uniqueness of the story”. Maybe it’s just lacking zeitgeist.
- I worked on Terrobot X’s code editor a bit. I have no idea how sensible parsing actually works, but on the other hand it’s not the most important thing to get the syntax coloring right. I just hope for a smoother experience than working with Unity’s inbuilt text input boxes. Some things I do to make it easier for myself: a) only allow mono-spaced fonts; b) don’t have text-wrapping, instead do overflow for lines (and let scrollbars handle the rest); c) concentrate on Small Basic as the language to be used with this editor, so don’t get too fancy with the parsing.
- I changed a small thing in Terrobot’s web version - instead of using the F keys F1 to F5, users should use Alt+1 to Alt+5 instead in order to quick-execute their little programs. I totally forgot that F1, F3 and F5 already have standard functionality in web browsers and thus are unusable with a WebGL game …
- Afterwards I started with the extended version of Terrobot, calling it Terrobot X for now. First - and probably final task, when I give up - will be a functional code editor based on UGUI. Which is not much fun to make, but necessary. Only if I really finish this thing, the actual game will be planned more thoroughly.
- I will think about extending or rather making a full game out of Terrobot. The main problem is the “IDE” inside the game - Unity’s input text boxes are just not up for the task. So I would have to write something completely different, maybe something with text element blocks like in CitApp. In any case I just like the idea of controlling robots remotely on some alien planet's surface. It has a lot of potential. The question is if I want to go into the direction of some kind of exploration/adventure game, or a Zachtronic-like with discrete tasks to do. I’m leaning to the former, with maybe the latter as little missions in-between. (Current project description: “The Witness, but with remote controlled robots.”)
- I uploaded version 70 (getting rid of those x.y.z version numbers) of Pry, with (hopefully) improved ladder climbing, locks and contextual key prompts. The ladders were the main work today, with adding the possibility to leave the ladder without using any buttons (you have to stand on the floor for that), and adding some colliders that make sense, especially when it comes to the top part of the ladder.
- There will be a “Frankenjam” - a game jam happening in Franconia, starting November 5th. While I could travel to Nuremberg for this, it’s also online. Not sure if I have time/motivation for taking part though.
- The Halle-Spielt App now features timed tasks! Which are just a simple timer with a cancel button; and they’re used for tasks for the players where there is no real way to prove/disprove if they actually did it. So it mostly relies on the honour system, which is totally okay for the scope of the app.
- I updated bloed too. It now has “composite textures”, which means I can have grass blocks which are dirt on the bottom and the sides, but grass on the top. This was possible before, but only via extra side data, which consumes memory. Now there’s a way to automate it.
- Last but not least I further improved the locks in Pry. This mostly boils down to the fact that the naming of the keys/locks is a level-wide thing now, as there are 15 keys maximum anyway per mission. Now I can be (somewhat) sure the naming of “key 13” is consistent with “lock 13”.
- I was always a bit unhappy with how the ladders work in Pry, so I changed them to be used like in Filcher - by pressing the “use” button to actually climb them. I’m unsure if it’s the better system, but for now I find it more stable and logical with how the rest of the game works. A bit of work is still needed for this, then I will upload a new version.
- I tried to port Terrobot to WebGL, but unfortunately it only worked partially. Apart from the constant spawning of a message about how the post-processing stack only works correctly with fullscreen cameras, the scripting part does not work because apparently some code from the Small Basic interpreter gets stripped away. The error message is “MissingMethodException: Default constructor not found for type ISB.Lib.BuiltIn.” This is a problem for a different time, but it seems to be about Addressables?
Last post might be a solution:
Update: Yep, after adding this Preserve attribute to the BuiltIn class of ISB, the WebGL build seems to be fine. I submitted an issue on the ISB’s git repository, maybe it helps the developer.
- Before I forget it again - as usual the standard settings for Unity web builds don’t work out of the box; the project won’t finish loading. I had to disable compression (Compression Fallback) as the simplest solution for this.
- To get back a bit to Pry dev, I visualized door locks. The plan is to make it more clear that a key needs to be used, but of course the underlying problem isn’t solved yet: How does the player know they have to actually take the key in their hands and “combine” it with the locked door? I think it’s mostly a tutorial thing, but on the other hand I know that the system is maybe a bit alienating to some users. (Even though Deus Ex, Thief and now Filcher require a similar thing from the player.)
In any case, to make it even more complicated, I added some interfaces to allow different charge times - for doors that are “more difficult” to lockpick.
- I might participate in the HaxeJam (starting October 17th), because I like the language and ecosystem, and even the community a bit. I’d probably use either Heaps or Kha, or even Armory3D, but with no plan right now what game concept actually. Depends on the theme.
- I participated in the 13th installment of Alakajam (theme was Robots) this weekend - and actually submitted something. Even though for the longest time it looked like I wouldn’t; and really, the game isn’t what I wanted it to be. But it is functional, and shows potential. Which is why I actually finished it up. Terrobot is a programming game/puzzle/dungeon crawler. For the programming part - in order to move the terrobot around - the player has to write small scripts with Small Basic. I decided on Small Basic when I found wixette’s interpreter for this programming language by Microsoft, especially as the interpreter is usable in Unity. It’s far from perfect - for example, there is no handling of syntax errors, the interpreter returns nothing - but it works most of the time. I had to modify the interpreter though, in order to allow asynchronous stepping through the code.
Terrobot is also the first game that uses bloed, my very own level design tool. Not the grandest premiere, but a premiere nonetheless.
- The Patou puzzle-prototype is finished for now as the deadline for the application for the federal state funding is today. I think it can work in third-person view, but if not then a change to some aerial view wouldn’t be too bad either. Right now the puzzle is just about sliding some boxes along other boxes to a goal, or build a bridge. The potential is big enough to add more interesting and compelling elements though.
https://www.youtube.com/watch?v=GwzPFX14Mn0 (top secret!)
- I watched - over the course of a few weeks - an Unreal 4 tutorial which basically teaches how to navigate the editor, how materials work and can be manipulated, a tiny bit of Blueprint, and mostly how to create a landscape with Megascans. Overall I didn’t really get warm with Unreal through this course, mostly because I am very overwhelmed by the amount of options.
- Robert Yang’s “Quake Renaissance” articles for Rock Paper Shotgun were quite nice. I am playing through the game currently and even though some stuff didn’t age well, I would say it’s better than Quake 2 overall. So Yang’s article helped me to understand the game and the culture around it, which is kind of valuable when you’re a game developer.
- A few “Simplest AI Tricks”, although of varying quality. I like the idea of using breadcrumbs spawned by players to teach AI enemies where and how to wall-run. Bonus trick from the comments: “make the bad guys run away sometimes, not necessarily for a discernible reason. It worked for Clyde in Pac-Man, it worked for the Grunts in Halo, it sometimes leads players into a worse situation and seems really tactically clever... just make them run away and/or hide a bit sometimes.”
- I semi-solved a bug that was annoying me for weeks or longer in Pry (even though we don’t really work on the project anymore). When an enemy ran to the player and attacked them, often the enemy would slide quite a bit before coming to a halt. Turns out that the acceleration setting of the RichAI component was the culprit. Increasing it to a high value like 10,000 helped, but caused another problem - such a quick acceleration would look janky in other situations. So I had to add some logic to set the acceleration to this high value when stopping, but easing back to the original value over a short timeframe. It feels a bit dirty, but I guess things like this aren’t really solvable without a hack.
- I did several smaller things for the Halle-Spielt App, mostly graphical improvements and UI work. I also added a rudimentary main menu. Due to health problems in the family I can’t do much currently, but I hope my productivity increases soon.
- Watched a talk by Aubrey Serr about Radically Non-Linear Leveldesign. Nothing really new for me - I guess reading/watching stuff about Thief levels already (and trying to make our own Thief-like) already gave enough insights.
- One of the “mini games” for the Halle-Spielt App is finding a spot on the map by actually walking there - of course with the help of GPS. For that I define the latitude/longitude coordinates of the cache and also a radius (in meters) which indicates where it could be, so you’re not totally blind trying to find it. What I found interesting is that the formulas for converting lat/long into meters have the magic number 111,111 in them.
- I’m currently working on a small puzzle prototype for our maybe-next game project Patou. It has a lot of premises it has to fulfill, so I am very limited in what the puzzles will actually look like. First, it has to work in third-person view, second the puzzles shouldn’t get too complex and third the dog character in the game has to be able to play an integral part of each puzzle.
- The Halle-Spielt App now has a beginning and an end. Which means the story creator can add some kind of introductory text, and also one for when the story is finished. On the negative side I noticed that the update for the QR-code scan plugin doesn’t work anymore, at least for me.
- Watched a short introduction to Unity’s new UI Toolkit (or whatever it is called now). It’s basically CSS and a bit of the old IMGUI. I don’t like how the developer apparently doesn’t get direct references to the elements, so they have to resort to getting elements by string, ugh.
- Noclip did a pretty good Thief documentation, with a lot of interviews and some material even I didn’t know. The gist is: great game design ideas, and crunch is cool if you do it voluntarily. Hm. Other than that I’m sad Doug Church wasn’t interviewed.
- A short video about parasitic (game) design. I didn’t know a word for it, so it was interesting to me. Parasitic design basically are game mechanics that wouldn’t change the game if they were removed. I guess one could compare this to a character in a book, who serves no real purpose in order to advance the story.
- LÖVR could be interesting for experimenting with VR without trying to make a full project. It’s basically LÖVE, but 3D and for VR.
- Lots of tutorials for level building. Seems to be Unreal-only.
- Some neat things in this Blender video about character creation. The character is ugly though.
- I added a QR code scanner plugin to the Halle-Spielt App. I used it years ago already with a jam game (“Die Stimmung kippt”), and it’s still working, so I’m thankful for that. I still have to add a lot of convenience things - what happens if the user aborts the scanning, etc. - but the most important step is done: actually calling the right functions. The game still has no logic on what happens if you do the right or wrong thing though, other than maybe give you points. Maybe it’s not necessary to add an actual lose state, as the game should be super easy.
- I currently have a few project( idea)s that I would like to work on, but somehow don’t have the time or the motivation (mostly both) to actually do it. Some of these are:
- Pry: I work on it from time to time on the side, because I always wanted to do my own Thief-like. Current task though would be to work over the AI, and it’s not easy.
- Zauberwald 3D: a text-adventure my brothers and I wanted to create, and while there is no real incentive to actually work on this, it’s still in the back of my head.
- Archeology game: a game idea that I had during an Alakajam, but it wasn’t feasible to do it back then. I still like the idea though, and I might get back to it someday.
- Stealth gridder: I wrote about this a lot already, and the current state is a good basis for building an actual game on it; but somehow I lost motivation to go further, and I have to find out why.
- Fantasy platformer: this is just a stupid idea that might be fun - a game based on my brother’s puppet series. Could be co-op even. If I’d wanted to do it alone, it would be very low-poly, and short.
- Coding game: something like CHIPCODE, but embedded in a 3D world and with a story.
- A game that uses LEDs. I liked working on my little electronics projects, and I think I could pull off something more complicated. Maybe combine it with the Orba, and/or my old RGB gamepads.
- Zoo game: a mobile game for the local zoo. This could actually be a module for the Halle-Spielt App, so here’s a higher chance for one of these projects to become realized.
- Vestbank: a VR game inspired by the C64 game Westbank; basically just a very simple shooter, but you have to take care not to shoot innocent people.
- Create stuff with my cheap 3D printer, like a simple 3D puzzle.
- A standalone version of the dialog editor I created for Behind Stars and Under Hills.
- Tech I would like to find time to dive into: Flax, Unreal, maybe Roblox. More Python. More Blender. Urgh, so much to learn and see and do. And not enough brain power to pull through.
- The Halle-Spielt App now saves (and loads) the game state, which is important for this kind of game, so I implemented it “early”. Next up: some kind of high-score. This is for actually adding some kind of reward/punishment to the mini games.
- I drew a picture, on A4, with pencil. It’s for the “CD cover” of the soundtrack of my brother’s puppet show. It was fun, and as usual I vow to draw more. What’s missing mostly is having some kind of theme or task, otherwise I just don’t do it.
- Working with longitudes and latitudes for the Halle Spielt App is a bit dry, and testing the stuff is hard, because I’d have to go outside for that... But at least three different quiz types are added now, although they don’t do anything yet. Next up is saving (and loading) the game’s state, especially for the stations. This way I can reuse it ingame when re-visiting a station later.
- Doing small things for Pry, treating it like a hobby project. As such I only add/change small things, for example it’s now impossible to use the bow while climbing a ladder. Tiny additions to the statistics screen at the end. Shooting an unconscious enemy kills them. Things like that. What I really should tackle though is improving the AI.
- I should add more stuff to Alternative Artefacts, but somehow I feel drained. It’s not very rewarding to extend it if nobody writes stories for it.
- Even though Pry is “on ice” for the time being, I changed some of the input functionality in the project, because somehow I feel I can do at least that. I’m still interested in this becoming a full game, so I’m still at least a tiny bit committed. In any case, instead of RMB for manipulating hovered items (like objects on the ground, picking them up), it’s now the key F. This leaves RMB free for alternative usage of the item in hand; like cancelling a bow attack, or parrying with the sword. The question remaining is: how will gamepads handle this?
- Our Machinery now was released as Early Access, and with a price (pretty cheap, for indies). I might want to try to make my usual box puzzle game with it in order to evaluate this game engine.
- I’m doing some boilerplate stuff for Halle Spielt App currently, like implementing popup dialog windows and things like that, and it makes me aware that I should make this reusable because I already did these things for the last three contract jobs now.
- For the Halle Spielt App, a new side project that is already funded, I looked into how to implement getting GPS coordinates using Unity on an Android phone. We already did this with our Global Game Jam entry from 2019, Wehheim, but back then I used Mapbox, so a lot of stuff was already done for me. After a bit of research - and doing the wrong thing for half a day - it actually wasn’t much code to get it working; now I can receive the current GPS coordinates.
- Out of nostalgia, and maybe for Spielgefährten, I installed Ultima 7 from my floppy disks (around 30 years old now) on DOSBox. The installer didn’t continue at first, but I found out I had to reset the disk caching, by using Ctrl+F4. No idea why, but it worked that way.
- I used Blender a bit today to create a 3D model for an art object by my brother Ludwig. It’s not finished yet though.
- A redditor wrote down their experiences when they tried to hire artists. Nice read.
- Watched a video about hard vs. soft worldbuilding, a topic that currently interests me because of project Pry. I found it insightful, and might change my thinking regarding story creation a bit.
- I read this tutorial for ceramic, a 2D engine for haxe. It works a bit like Kha, as it creates a full self-contained installation of all needed libraries. Which is something I’m not a fan of, but I guess it has its advantages. Anyway, what I’ve seen in the little tutorial project is nice enough and easy to understand, so I might use it for a project, at least for a 2D jam game.
- I extended Pry’s revamped interaction component so it also supports “infinite continuous interaction” now. This is useful for stuff like turning wheels, charging stations, maybe some fun throwaway interactions.
- There are now items that can have texts in Pry. So the player can either right-click the object and get the same read interface as with the signs, or they can keep the right mouse button pressed and thus collect it. For this I had to do some heavy changes on how interactable things work, but it was all for the better. Consumables will benefit from this too (either eat it at once, or collect it). I think Prey (2017) has the same system, so I was inspired by that.
- To counteract the effect of lifeless (unconscious) enemies dying too quickly when the Pry player throws them around, I gave them a simple auto heal effect. Not very realistic, but it makes it harder to kill enemies accidentally, while they still suffer death from falling great heights.
- Some strange problems arose with a custom editor in Unity, where deleting a sub asset wouldn’t actually remove it, and I have no idea why. As a workaround hack I added extra checks and anytime the custom editor notices that there are some invisible sub assets, it tries to remove them. Ugh.
- Currently I’m trying to make unconscious enemies (knocked out by Pry) vulnerable to damage. This is somewhat complicated in the case of fall damage, as there doesn’t seem a good simple way to measure how much certain collision events should hurt. I guess it’s a matter of trying around. In any case my current approach kind of works, but makes it clear I need to generalize it a bit more - this would even be beneficial in order to add vulnerability based on different body parts. Head shots would be possible then.
- After adding the tutorial signs to Pry’s playground test level, I now try to make enemies who were knocked out by the player more meaningful. It’s especially important that they die when you hit them with an arrow, or push them into an abyss because of the impact. Easier said than done. Anyway, the reading interface works well and we can even add pictures to the texts. The usual localisation code is utilized as well.
- Noticed that I can’t select UI elements anymore in my Scene view… apparently because Gizmos were not active! The hell!
- Remember, when using TMPro.TextMeshProUGUI in a Vertical Layout Group, use a Content Size Fitter with Vertical Fit set to “Preferred Size”!
- Currently working on an interface to read stuff for Pry. Because it’s about time we add some text messages, and hint at some story!
- I wrote a design document for our next demo level. While it was a bit tedious, we should probably do something like that for every single mission in the game.
- Finished watching a tutorial video about modelling and sculpting a stylized head/bust in Blender. It actually taught me some new techniques, especially the stuff with remeshing, so it was pretty interesting.
- Pry now has a zoom tool that can be used to decrease the field of view of the camera, thus giving the illusion of a zoomed in view. Very handy for thieves and spies! Of course, this is very rudimentary for now, with placeholder optics and so on, but it works quite well so far.
- While it’s nothing special in itself, Pry now displays the current version in the top right corner, and if it’s different from the version on the server, it will show that too. What’s noteworthy about this? I updated my StoneBuilder script so I can automatically upload the most current version (as a text file) to the server without me having to do manual steps.
- Saw the documentary about Axiom Verge. Pretty crazy that the guy did all the stuff for the game, even the music. Got pretty sad about what happened to his son (who was born after the release).
- I did some more work on the ladder in Pry, as the playground demo made it clear that automatic climbing isn’t the way to go. Because if you just want to peek over the edge (as there is a guard patrolling), you climb up into full light instead. So now I removed the automatic climbing, which makes leaving the ladder a bit more complex - which means I have to get back to it sooner or later.
- This tutorial explains how to get rid of strange rotation and scaling when you export a Blender model to FBX and import it into Unity. Basically, uncheck “Use Space Transform” when exporting (available since Blender 2.91) and check “Bake Axis Conversion” in the importer options (since Unity 2020.1).
- I will call Guarden from now on Pry, even though that’s not the final name either - but it might be the name of the protagonist. It fits more than “Guarden” anyway.
So I improved the hacking device a bit - it got some fun effects (all rudimentary for now) - and battery. The battery can be charged at a special station. We’ll see if this is a good idea, but overall I’m all for limiting tools so the players have to be more tactical.
- We gave an interview in our office today, for Halle Spielt. One of our better efforts to (re)present Rat King, I must say.
- Read this article about The Art of Lighting Game Environments. It uses Unity’s HD Render Pipeline, but can be applied to other software and render pipelines. Overall I didn’t learn much new, but it’s nice to see the HDRP is actually using the same stuff as before.
- Added some finishing touches and fixed a few bugs, and now Guarden’s playground demo is ready to get sent to testers. There are not a lot of them yet, but I wouldn’t want to have too many eyes on the game for now anyway. I know about pretty much all of the obvious problems it has. Still, it would be cool to see if there are people actually interested in a Thief-like.
- Guarden finally doesn’t rely on hard-coded missions/quests anymore - instead I programmed ScriptableObjects that do the very same job, but can be created for each level individually; maybe even for different difficulties.
- I set up an itch.io page for Guarden, so we can distribute it to testers when the time comes. The name of the page is, for now, “Pry - Steel and Stone”, because “Guarden” wasn’t fitting anymore for months now. Of course building the game to an .exe made some bugs prominent, so first I had to fix those. After that comes the polish face for the playground - which basically means that I will distribute loot and other items, and define the mission better.
- I wondered quite a bit why, in Guarden, thrown objects would jitter so much when I move the player/camera at the same time. Seems I forgot to change the Rigidbody’s Interpolate value. The internet says the value should be “Interpolate”, but so far the jitter really got removed only with “Extrapolate”.
- For a bit more “juiciness” I also added some small camera roll when the player moves left or right. I think it looks awesome, but it might be annoying for some.
- I’m currently working on some kind of dynamic help system for Guarden. It mostly consists of signals that the different components can broadcast. E.g. the sword, when pulled out, just broadcasts a signal INPUT_BUTTON_ADD with the values “LMB” and “Attack”. Of course, this has to get improved later, to accommodate gamepads and rebindable controls.
- I removed the Collab integration of Guarden, because honestly it annoyed us more often than it should. Instead I tried to export the repository because I wanted to use the data for a GitHub repository of Guarden. Unfortunately it wasn’t usable for us, but thankfully a full development history isn’t that important to me for now. This might change later. In any case I am trying out the GitHub for Unity plugin, even though the reviews on the Asset Store are far from positive. But as we don’t use most of the functionality it might be a boon nonetheless. In any case I need to look into GLFS (Git Large Files Storage) sooner than later.
- Among some small changes the crouching in Guarden is now a toggle. It will probably be an option later on, when we have a menu for that.
- The 52nd entry of Jackson Dunstan’s series “C++ For C# Programmers” is a list of best practices in C++, and it really was interesting to read. Especially with my extremely rusty C++ knowledge.
- I could make the ragdolls in Guarden much more stable now. One reason they always behaved like goo was that I put the ragdoll colliders into a physics layer that doesn’t collide with itself. Another very helpful thing was just using PuppetMaster, a plugin by the FinalIK developer. PuppetMaster is actually pretty powerful for dynamic ragdoll functionality, and a bit of an overkill for our project. But for now it works much better than before, and maybe we will use some of the other features of PuppetMaster.
- Apart from doing smaller things for Guarden, like adding support for methods with an integer parameter to the Hacking attribute, or increasing the senses (view distance, angle, etc) of AI agents that are suspecting or follow a target, I again tried to improve the stability of ragdolls the player throws back into the world after picking them up. Apparently I am not the only one with this problem, and it seems one culprit at least are the joints that have to get reset somehow, otherwise they have old and now invalid values in all the wrong places.
- The player can now grab stuff and move it around in Guarden. This isn’t as sophisticated as it was in TRI, as the physicality of the system back then is not needed or wanted; instead a much simpler system akin to Thief was implemented. Right now it only works for bodies of enemies, but it would be no problem to extend it to crates and similar stuff. It still needs some kind of collider check though. And the bodies behave very strangely; I gave them a special “throw pose”, but the main problem is the fragility of the ragdolls.
- As Guarden’s enemies notice corpses of other enemies when walking around, it would be bad if the player wasn’t able to carry dead bodies around. Now they can do that. There are problems with the ragdolls though, which are not that important for now.
- My brother is getting another trailer from me, for one of his exhibitions. This time I’m not doing it in a video composition program (I mostly use Hitfilm Express), but in Unity, because he wanted it to look like a cracktro. A nice idea, and scripting this instead of animating it feels more natural. Most elements are done for now, but here and there will be corrections to the timing.
- It’s probably a quite brittle system, but guards in Guarden can now “remember” corpses lying around - so they won’t get alerted by them forever anymore. It’s actually not really bad if they do, but in the end the game should at some point return to a “safe state” because otherwise it feels unfair.
- I added some rudimentary path-finding code to my gridder. It’s not used yet for anything. The important part is that AI agents should determine if they can use doors or not, even if they’re currently closed.
- I did an overhaul of how the new AI agents in Guarden look at things. It’s not finished yet (as usual), but the gist is that I removed “rotating body/head at a target” from the agent’s move module and made it an integral part of the agent class. Unfortunately there are still some problems, and not everything is absolutely clear. I especially dislike how I coupled the rotation behaviour to the current state, and I will most likely change this.
- Interesting way to see Unity’s internal editor functions: “Create an asmdef and call it Assembly-CSharp-Editor-testable.” (The functions are internal because they are not documented, because they can change anytime.)
- Had a look at C# 8.0’s new features, and while some of them are interesting, I am not sure I will use them in the near future. Especially as Unity does not allow all of them.
- I’m still pondering about switching Guarden from the built-in render pipeline to the Universal RP, but of course the fact it’s only forward rendering (which means: it’s not possible to have a lot of dynamic lights at the same time) is the main reason we won’t do it. As there is a deferred renderer in the works, this might change. But then again I skimmed over this (fairly old) article about Forward+, comparing it to Forward and Deferred, telling me that we should wait for Unity to get to that one. And who knows how long this will take.
- As Jana wished for an enemy who can look from above, from some kind of balcony or so, and attack the player as soon as they see them, I worked on that. It’s really frustrating what a can of worms that is, even though Guarden’s new AI mostly works. But there will always be strange and unsolvable edge cases.
- Someday I really want to release a gridder, so I had a look at my old TODO list of the last iteration of it. Seems doors were very important to me, so I outlined how to implement them. Making them interactable for the player is the easiest part; it becomes more interesting when enemies should be able to use them too. So there should be connections between the way points that have information if they can be enabled by doing an extra step.
- Guarden’s enemies can now switch to far-range weapons if their enemy (i.e. the player) is too far away. Not perfect yet, but it’s working. Main problem is the fact that they switch weapons instantly without any animation, so this looks a bit strange.
- I kind of solved the new, modular AI’s problem with the alarm buttons. AI agents of Guarden can tell other agents “facts”, which are just single strings for now, but with a time constraint. It’s definitely not the most robust system, but somehow I feel that a little “wonky” AI can create funnier/unexpected moments, and that’s probably more important anyway.
- I fixed a tiny bug in bloed that prevented it from working with Bakery - as I added a NotEditable hide flag to each chunk, the lightmapper didn’t find the objects. So I removed this hide flag. It’s still not enough to warrant an update of the editor on itch.io, especially as less than 20 people actually purchased it.
- As I actually wanted to do a game this weekend (but didn’t), I opened my old gridder project and fixed a bug with the player being able to climb sideways. At least this won’t annoy me now. (The actual plan for the weekend was a very simple game with only a single level and a single enemy.)
- With a free weekend to come, I wonder what I should do. I have several projects still open that I’d like to pursue, but most of them are not really weekend material. Like, one idea would be recreating my dialog editor (for Behind Stars) as a standalone tool, maybe using Dear ImGui, and its C# wrapper.
- While we’re fleshing out the story of Guarden, I still work on the AI from time to time (which will be the case for, probably, forever). Now the AI agents can activate alarm buttons if they feel there’s danger. The problem though: they all run to the button at the same time; so I need some kind of blackboard for enemy groups where they can add infos, like “agent X is going to activate this alarm”.
- Interesting tool for curve fitting. Not sure yet for what I’d need it, but looks useful of course.
- Interestingly enough Unity Tech wants to add support for Enlighten’s real-time global illumination to URP in the later versions of Unity. After they said they would remove Enlighten completely from Unity 2021 and beyond. It’s really bad how much they’re behind with their own tech so they can’t deprecate stuff as planned.
- Today I tested Bakery’s settings and generated lightmaps, in combination with the Universal Render Pipeline of Unity. This works so far, although I still miss the real-time global illumination of Enlighten. Anyway, things got strange when I changed the forward renderer of URP to the experimental deferred - suddenly everything became grey. I guess this needs quite more time before it’s actually usable.
- Watched another Blender video, this time about one hundred add-ons. I’m not sure why I watch these videos, but they are kind of entertaining, and in the end it’s a good idea to know what the software actually can do.
- While fixing a few bugs with the “new” AI in Guarden, I noticed a big problem with how the enemies react when getting suspicious because of some sound. There are a lot of cases where they would walk stupidly in exactly the wrong direction, because, of course, they are suspecting and don’t have a clear target. There’s also a problem with pathfinding, but this is just an amplifier. I will try to find ways to solve this later, when we actually build stuff.
In the end the problem might solve itself when I make the detection angle and radius more dynamic. (For example increasing the sense radius when suspecting a sound.)
- Furthermore we worked more on the new story/plot, and it’s actually the first time since the inception of Guarden as our new project that I am quite content with the direction our story ideas are going.
- Had a problem today in my code where something that became null wasn’t recognized as null. Of course this was because of Unity’s Objects being able to be destroyed but still not null internally. So I have to check thing == null || thing.Equals(null) on my interfaces from now on.
- The “new AI” of Guarden is done now, as in: it’s now a complete copy of the old functionality, just spread out over several classes instead of just one. Next step is to put the modular design to a test and extend it with interesting things like: pushing alarm buttons when a threat is near; detecting (and reacting to) dead bodies of friends; attacking foes that are not the player. And so on.
- More work on the “new” AI of Guarden (which is still only a re-implementation of the current behaviour) - it now can potentially sense multiple targets. Choosing the “best” one is not really implemented yet, but that is only a matter of time, and when we need it. I also could make attacking the player more general by just playing the animation and letting animation events do the rest.
- Just to see if we can use it for Guarden maybe, I tested Unity’s Universal Render Pipeline - with deferred rendering. Deferred rendering is still experimental, not officially supported, but what I saw did work at least. (I had to update to Unity 2021 for that, because it didn’t work in Unity 2020 LTS.) The amount of draw calls is pretty high though, even higher than with the old in-built render pipeline, so I am not sure if a change will be a good idea. Only actual performance tests will tell the truth.
- Still working on Guarden's AI - and this will go on for another month is my guess. I am back and forth on how to distinguish between a “suspecting” state, and the actual “sensing something and following it”.
- We also discussed the story of the game a bit; while this is also a big construction site for the foreseeable future, at least we’re very happy with its current direction.
- During Easter I mostly worked on Guarden’s AI, as planned for a long time. The current state of the new code is “barely working” and “extremely unfinished”, but at least I could separate some of the original code so there won’t be a monolithic Enemy class anymore, but a GameAgent that can have several components responsible for animation, movement, etc. Hopefully I can keep this up till the end.
- I watched a video about optimizing physics performance in Unity. It actually contained stuff I didn’t know before, especially things they added in recent Unity versions. For example, you can change the solver iterations per rigidbody. The raycast command API is interesting too, although the last time I tried it it didn’t fit my use case unfortunately.
- I read the two PowerPoint presentations by Randy Smith, namely "Design Fundamentals of Stealth Gameplay in the Thief Series" and "Level Building For Stealth Gameplay". They still hold up. Later that day I also read "How To Help Your Players Stop Saving All The Time", even though it’s probably not that applicable to Guarden - a highly interesting read nonetheless.
A day later, I read “Practical Techniques for Implementing Emergent Gameplay”, and while Guarden already follows some of the proposed techniques, it was still a good read.
- While Guarden still uses the legacy render pipeline, which is very outdated nowadays, I saw that there are efforts to bring deferred rendering to the Universal Render Pipeline. Which would be awesome, because “infinite amounts of lights” is what the game needs the most. Hopefully it’s coming soon enough.
- I wrote a blog post about bloed; which is pretty much the pinnacle of my PR efforts for this tool.
- Enemies in Guarden now have foot steps. At first I tried to use animation events for this, but as I blend idle, walk and run animations, this wasn’t feasible. In the end I now check the Y position of each foot and if it’s below the start position, it checks the floor’s properties and the correct sound is played. Works well enough so far.
- As enemies in Guarden got startled by their own actions (namely: closing doors) because of the sounds, I added some kind of “ownership” to incidents like this. So now they can distinguish between sounds caused by the player and sounds caused by anything else, which removes the problem. I put the info of by whom it was caused, and when, into a class SignalInfo, and this is probably not good for performance (because it needs to get garbage collected at some point). Changing it to a struct might be bad too though, because the info gets copied for each receiver. Ugh, decisions…
- Finally added a few missing projects to my website.
- I am still working on that “perfect” behaviour tree for our Guarden NPCs. It’s pretty much an AI agent from Thief so far, but I’m okay with that, because those were fun to play with.
- Finally read an article on The Digital Antiquarian, about System Shock 1. A great game, ahead of its time, as they say.
- Finished reading a book about - writing books. Not that I really want to be an author, but I toyed with the idea of writing something from time to time. I know I should be much more active to actually do it. I have that problem a lot with other creative things too, like drawing or composing music - I am interested in them, but I don’t have the energy to master these things.
- For Guarden I need to make the AI of the enemies more robust, especially as I’m coming up with things I’d like to add, and of course with a growing list of things that are broken or don’t work in specific cases. I still want to use behaviour trees, and I’m slowly accepting that I still have to use “states” with them. Maybe I should just rename them to something else, like “condition”, so if the enemy notices the player, they get into the “attack” condition. No change actually, just in name. In any case I am filling a document with how I want the behaviour tree to look like, and it’s not a big difference to what it is currently, but here and there I see room for improvement.
- Mozilla Hubs is really nice for a different kind of chatting, so we want to do a Rat King hub someday.
- An interestingly complex problem in Guarden currently is picking/hovering items that are attached to enemies. As the enemies have a bounding box (a capsule actually), the item has to “float” a bit detached from them, because otherwise the hover raycast will pick the enemy, not the item. I tried various things to solve this differently, but I actually didn’t find anything that would work correctly in all cases.
- I improved the sound “hearing” of the enemies in Guarden, by giving each sound an “importance” factor, so the suspicion of an enemy raises slower for certain sounds than for others. Fixed one or two bugs with my SoundType class on the way. (I should commit them to my jam base code.)
- For Jana I printed a little box for her nose piercings, but unfortunately the lid doesn’t fit. Back to Blender, I guess.
- Tried to fix some really nasty bugs with my Guarden propagation code, which was bad in a lot of places, but mostly in the pathfinding section. Had to resort back to this A* tutorial that is still one of my most beloved tutorials I ever read.
- Writing down a plan for a talk we will give in two days. As usual it’s about personal games.
- Found out why the 3D printer didn’t connect via to my PC, and also found out how to solve it. So, the solution is to search for “wch.cn ports 3.5.2019.1”, download this driver and install it manually. I think the main problem is that I suppress driver installation on my laptop (because of certain problems with stupid microphone drivers that get downloaded and installed automatically).
- I uploaded bloed on itch.io. I won’t do much promotion for it, probably.
- Finally I did what I wanted to do for weeks now, I made a video for bloed. Of course everything that can go wrong went wrong (sound problems, my stuttering, screen too bright, bugs, etc), but I am not in the mood to fix the errors or do it again, so there it is. Maybe in the future I’ll try another video. Tomorrow: releasing version 0.5 on itch.io and listening to the crickets.
- I added footstep sounds to the player in Guarden, which made me realize the AI sensing and propagation needs more work. Mostly because enemies hear the player too well, as there is no info of how “suspicious” a sound actually is. Walking on metal should have a suspicion factor of 0.8 I guess, wood maybe 0.5 and carpet should be at 0. Something like that. That means I need more data, either via ScriptableObjects, or maybe a database.
- I’m working on a system for sound propagation in Guarden. With my naive approach I can define rooms (with one or more points), and connect them via portals (usually doors). For now this works well enough, although in the future I want to be able to define the “penetrability” of a portal, and also implement some A* algorithm for the propagation; otherwise it is not “realistic” enough. The main problem with my approach so far is that it isn’t automated - every room has to be prepared by the designer, and things can go wrong in that case...
- As an experiment I changed the parry button of Guarden - it is now the same as the sprint button. When the player is standing still (more or less), has the sword equipped, then they would parry on the press of the button. Otherwise they increase the movement speed. This is just so I can change the parry button to drop/throw, which I find much nicer.
I also finally started with making the hacking device a bit more useful, but there’s still a long way to go. In any case every hackable thing can have more than one function to hack, and it will be displayed in the device instantly. Using the device will now make the player stop - they can’t move as long as they hack. I don’t like this solution much, but it’s the most real-time one I found so far.
- I started my entry for the current Alakajam (theme is “Ancient Ruins”), because during my self-imposed computer-free time during the whole Saturday I actually got a good idea for it. But I do it relaxed, because I am sure I won’t finish, and the vision of the game is grander than a jam game, even though it is fairly straightforward. I like the game idea enough to try it later on again.
- A semi-regular development update in a voice channel inside our Discord server could be fun. Just to get more comfortable with sharing stuff, and talking about it. We don’t have a big audience, so it would be really for the practice, not anything else.
- I extracted the code for throwing items from Behind Stars and pasted it into Guarden. Amazingly it mostly works, though a few bugs remain. And there is the problem of re-using the blocking/parrying key for dropping/throwing items. So blocking probably has to go, because there are not much free buttons on the gamepad left, and it really is only used for the sword. We don’t even know if we will have melee weapons at all...
- I extended the existing inventory UI for Guarden, so you have more than just the 8 quickbar slots, but also a full inventory when pressing Tab. You can also swap items between slots. A lot of work to be done, still.
- The hacking is rudimentarily implemented in Guarden - you can click on something and it changes maybe - but now I found out that UnityEvents can be generic too and have up to four arguments, which is nice. Using it in the Inspector has to be done with care though, because you can still (accidentally) select the method with the parameter to be defined by the user.
- One of the things that annoy me with bloed is the fact that the prefab workflow is bad because of a bug with Unity (the physics scene gets missing in the prefab view). It means I have to save the asset after every click, and this drags down performance a lot. So I thought I could use this piece of code I found in the forums (by chance) - basically Unity’s own editor-only ray-cast functionality for MeshFilters (instead of Colliders), which means I don’t have to use Physics at all. After some tweaking I got it working, and it actually improves performance a lot. At first I forgot that my bloxel textures can have noise that will move the geometry around quite a bit. I chose to not use shaders for this so the physicality is better, and the noise can have more impact. That meant I cannot use the drawn meshes for the picking, as it can lead to wrong positions, so I had to resort back to the specifically generated colliders - which is a bit sad, because I hoped I can get rid of those too.
- It’s now possible to knock out enemies in Guarden, via the standard tool “fists”. They also die instantly when they get hit by a weapon if they’re not alarmed. This is all rudimentary; but when I thought about making this another generalized system I noticed that this will be too much of a hassle. For now it works well enough, and is still somewhat extensible.
Ladder functionality is still in the works, too. Because of all the edge cases it will need a lot of time and thinking, and I procrastinate too much while trying to do it.
- I published a blog post about our jobs as tutors at our former university.
- Recorded a video for bloed, version 0.5. It is probably the worst video I could do, but I just don’t feel like putting more work into it. As already stated, I don’t expect anyone finding this tool useful enough, and I also actually don’t want to answer support questions (much). Though an FAQ (if there are any questions) will happen probably.
- I started working on the ladder functionality of Guarden, and it frightens me a bit. Mostly because it will make the player’s character controller even more verbose and complex. So the first step actually was to have a look at it again, just to see if I could improve the readability a bit. In any case, being able to crouch, climb, jump, swim,... it makes a character controller very heavy indeed. I have no idea how to break this down into cuter code chunks.
- Something I’ve never done for our first-person games would be having ladders, so this is something I want to implement in Guarden soon.
- I updated the actual bloed project. Next: some promo material probably, for the itch.io page.
- The next 7DRL Challenge is happening soon! Maybe I’ll participate, if I have an idea for it. It should be short, but in the end it could be the first game for my ray-caster...
- I updated bloed’s documentation for the upcoming version 0.5. Next step is updating the actual bloed repo, and then making a video.
- After, again, fiddling around with Unity’s serialization system I can now define “dynamic variables” for each prefab, scene object or ScriptableObject in Guarden and even merge those variables. Albeit powerful, the system I wrote is very shoddy. In any case it seems to work, as long as I don’t want object references. If the need should ever arise (especially for referencing prefabs), I will have to rewrite it a bit.
Anyway, I can now easily define some dynamic variables for an item type, and overwrite them via an game object instance.
- The inventory system of Guarden shouldn’t be the most complex one, but of course it has its own pitfalls, as does every system has that needs to be more or less “foolproof”. So I worked on it a bit this weekend, adding more to the item types, and so on. What dawned on me is how the controls could work. Everything that has to be combined with objects in the world, like keys with doors, can be taken into the hand. Keys would work like weapons this way. So you use it like a sword (left mouse click), and if a door is near, it (maybe) unlocks its lock. With right click you can open the door then. This means, LMB is “using the item in your hand”, RMB is “using the object in the world”. I am not sure yet how consumables will be consumed then, but that will probably be just the key F. (Or vice-versa, with RMB for consumables and F for doors/chests/collectables/etc.) Consumables are items that don’t need to be actively put in the hand because they are not combinable with specific world objects in the same sense as keys. This includes health potions, food, bombs, traps.
- Hopefully I can finally release bloed next week on itch.io. I don’t expect that anybody will actually download and use it, but it will be a milestone for me. It might also pressure me into doing updates. In any case I want to use bloed for my still planned stealth gridder. But before I can release bloed I still have to do the following things: a) test it with Unity 2020; b) update the documentation; c) create screenshots; d) make a video explaining the tool a bit; e) copy the bloxels code from my Demon Thief project to the actual bloed project f) update the test level (it’s broken now, because of the changes below); g) decide for a price, if any. Afterwards, h) write a blog entry.
- For Guarden we have some kind of wishlist floating around in our heads, things we’d like to see in the game. This list includes: ladders for the player to use, AI enemies that alarm other enemies, sounds that get propagated through the rooms, a lot of ways to open doors in the game - codes, keys, secret levers... But for now I am mostly “stuck” at mundane things like deciding what kind of inventory we will have. We also have to do a lot more for the story/plot. In any case, for the sound Steam Audio might be something I should have a look at.
- We do another weekly live-stream, this one each Friday, where we play stealth games. This is meant as research for our own upcoming stealth game Guarden. So far we did six episodes.
- Overall I did not do enough for Guarden the last few days, because of other stuff going on, stuff that doesn’t actually take time, but is a bit pressing on the mental side. Hopefully karma will balance things out a bit, and soon.
- I did the “last” point on my checklist of things I wanted to do for bloed before releasing it - “optimizing” the extra data for bloxel sides. It now uses a list of integers instead of a dictionary of a side data structure. This probably won’t save much in the long run, but it just feels nicer, especially as dictionaries are not serialized anyway.
- A friend made me aware of a book from 1995 called “Amazing 3-D Games Adventure”, where the author Larry Myers describes how he created a ray-caster engine. This engine was ACK-3D. Which was highly interesting to me, because ACK-3D is the basis (or precursor) of the ACKNEX engine, which I bought and used a lot as a teenager. Ah, fond memories. So I researched a bit and found this fun article about fixing bugs in code decades old.
- The ray-caster is far from finished, but as the deadline was only minutes away I uploaded it. Instead of a game it’s a sandbox for now where people can edit the only level it has. It is not possible to save it though. The full Sunday was dedicated to adding a working ingame editor (via zui). That means you can walk around and change the level in first-person. I actually didn’t have time to offer all the features “rc-test” supports - individual wall textures are not possible to edit for now. The current state will be confusing for users anyway.
I am interested in taking the ray-caster further and maybe create some jam games with it. Hopefully I don’t forget about it. Best of all though: finally I have some time for other things.
- As this is the last day I have for my ray-caster, I thought I’d try to add portals, because this should be fairly easy with ray-casting (more or less). As the first step I replace differ, a fine collision library for haxe, with my own code, because differ does not support collision with line segments, only with polygons and circles.
- It’s always “fun” to find out what tiny thing is causing problems next. This time it’s the fact that Unity does not have a diff tool on its own for the Collab stuff, and all of the third-party tools recommended come with problems on their own. Some of them have to be paid, others (TortoiseSVN) install more stuff than needed, WinMerge doesn’t get recognized. But at least I found a forum post that explains how you can add WinMerge as a custom tool, so I’ll try that next.
- The “ZwölfElf” room game, a collaboration between our students, is finally playable on itch.io.
- After downloading Visual Studio, which was around 10gb, and some unforeseen problems with images and divide-by-zeroes, I finally created a working windows build of the ray-caster. The colors are all wrong, but other than that this means I could create a level editor for it without having to use a third-party tool or another framework. The question is if I will have the motivation and time for that.
- For Guarden I delved into my character controller code (which is basically what was created for Behind Stars) and tried to add duck climbing. It’s a bit of a bigger hassle than I thought, mostly to get it working with higher ledges.
- I fixed the usage of the doors a bit, originally created for Demon Thief, now for Guarden. Of course doors are a big hassle in games, so I know this is not the end of it, but for now they are usable enough; I just need to implement the usage of keys.
- Optimized the ray-caster a tiny bit. I rendered the top/bottom walls behind other top/bottom walls even when there was a center wall in front of them, this is now fixed. I also had an idea for the actual gameplay, but I think it’s too much work for the rest of the week.
- Users of bloed (if there will be any some day) are now able to change the chunks’ size from 8 to any value between 4 and 64. It’s not really tested, but it should work.
- Although I am still not sure how a release (for the game jam) of the ray-caster will look like, I added bottom walls too.
- I added top walls to my ray-caster, but my heart isn’t really in it anymore. I guess I will continue to work on it from time to time, but for the game jam it won’t be a game release, more of a tech demo.
- I prepared the repository (residing on Unity Collab only for now, github will most likely follow) of our current game project so Jana can use it too and add test levels. This happened before already, but now we upgraded the Unity version and actually use almost everything from Demon Thief. I also created a documentation for all things related to the project and the scenes’ hierarchy, so hopefully there will be less problems.
For now the code name of the project is still Guarden, even though we do not actually use the “Gardening game + Thief” idea anymore. It still will be a Thief-like, but with a “Berlinpunk” setting. My fear a bit is that it will remind of NEON STRUCT a lot, but then again that one is sci-fi.
- To make bloed’s bloxels a bit more general I removed all references regarding sounds in the bloxels. Users should define their own reactions (sounds when walked on, when hit, etc.) via tags and template variables.
- Another day, another student’s project; this time Unity, but with the Universal Render Pipeline. I didn’t know, but apparently the URP comes with its own special post effects. It was also “interesting” to learn that shadows on terrains don’t work if the Shadow Cascades are set to 0 instead of 2 or 4. (It’s a bug, who’d have guessed.)
- Saw the inners of a student’s Unreal project. Blueprint was pretty intimidating. I guess if we ever get around trying out Unreal, I will directly go to C++, because I don’t see the benefit of Blueprint and its bad overview and even worse sense of structure. Unfortunately - I definitely like node-based scripting, but here I just don’t feel the positive side.
- Now that I potentially know how to implement collision for the ray-caster, I am not sure what to do next for it. I know I need some kind of level format and editor to actualy make meaningful content for it. But mostly this is an experiment for me anyway, and I like the infinity stuff already, so I should concentrate on that, maybe just making levels that are nice to look at.
- For our new game project I basically took what I did for Demon Thief and upgraded it to Unity 2020.1, and tried a few different assets. While I kept returning to PandaBT after trying NodeCanvas once again (very briefly - it will always feel much too bloated now), I will have to use Aura2 instead of HxVolumetricLighting, because the latter one is now officially deprecated. Too bad, I really liked the visual result of it. What I also want to change is to use FinalIK instead of LookAnimator - not because LookAnimator is bad, quite the opposite, but because I want to have a certain limit for the amount of third-party assets we’ll use. Having one asset (FinalIK) that does a lot of different things will always be better than one specialized asset; even though FinalIK’s LookAtIK and AimIK and definitely more difficult to use so far. But FinalIK also integrates with PuppetMaster (because it’s the same developer), something I plan to use for the ragdolls from now on.
- Seems like the bug with UVs getting strange git me again in bloed. I now removed the functionality to update UVs only (instead of the full mesh), even though this degrades performance a bit in certain cases. Unity strikes again!
- After following a very bad tutorial and went nowhere, I chose the lazier path and added differ to my ray-caster for collision and resolution. It works quite well with the walls so far even though it could probably be optimized by supporting a grid-based world map. Collision with sprites will be next. After that I will have to think of either a simple level editor, or at least a readable and powerful level format.
- I semi-solved my problem with the sprites not being drawn by just adding all the neighbour tiles to the list of things to draw. This is “semi” only because I didn’t test it yet for enough
- I added sprites to my ray-caster by following the aforementioned tutorial, and I’m still working on them so that they can be seen in “infinity”. This mostly works already (even though with bad performance), but there are edge cases where sprites don’t get drawn even though they should. The reason is that I collect all tiles with sprites on them during rendering the walls; which means that hidden tiles will not draw their sprites even though they might be visible (as they can have free positions on them).
- Because of the half-baked way prefabs work in scripts, I removed the ability in bloed to edit prefab instances. Users are prompted to either to unpack the instance, or open the prefab editor. Editing the prefab is insanely slow because of a bug in Unity with marking the prefab scene dirty - it removes the physics scene somehow - so I have to save the prefab asset on every change.
- I followed the tutorial further and now my ray-casting project has floors and ceilings. Next is either sprites, or collision. Probably both.
- Got very frustrated today, because the prefab workflow with bloed is a never-ending story without a happy ending. After a lot of hair-pulling today I decided to change my approach, with probably as much work as it was before, but maybe a bit less error-prone.
- We did another live-stream today where we played and analyzed a stealth game, because that’s what our next game’s genre will be.
- Working with prefabs in conjunction with bloed now has much less problems, but it’s very slow and will probably break if the user does anything fancy. Still, it’s better than before. I had to do some nasty hacks because there is a very strange bug with marking the prefab scene dirty and physics.
- I wrote a blog post about my questionnaire from a few weeks ago.
- By removing a chunk of code (and degrading the performance a bit in the process), I did another step towards usable prefabs with bloed. A big problem currently arises when the user unpacks a Bloxel prefab, which doesn’t recreate the meshes for now.
- After a bit of tinkering - there is no event for unpacking a prefab instance - I can now make the meshes of a BloxelLevel unique as soon as it becomes not connected to a prefab anymore. The same happens when the prefab gets deleted from the project.
- I am currently trying to make bloed compatible with Unity’s prefabs, and it’s just hell. There doesn’t seem to be an easy way to accomplish this.
- Ross made a video about SiN, one of the many late 90s era shooters I never played. It is based on the Quake 2 engine and that makes it very interesting regarding level design. The gameplay looks pretty standard. All in all a nice video, as Ross is hilarious as usual.
- Very interesting and comprehensible video about the Fast Inverse Square Root algorithm (often attributed to John Carmack usually, but as far as I know he’s not the inventor).
- I recreated the box puzzle game (which was also part of my Unity course) in Flax. I had some fun, but also a lot of bugs and crashes. Some parts of the workflow are okay, most of them are annoying if you’re coming from Unity and are used to it. Right now I wouldn’t recommend switching to it, but maybe observe it for the time being.
- Found out about Flax, another game engine that looks very much like Unreal and Unity (via GameFromScratch.com). Somehow it looks promising to me, so I might dig into it a bit deeper in the near future, maybe trying my box puzzle game once again.
- I had a funky bug today that was caused by Unity’s Unwrapping.GenerateSecondaryUVSet(), as it not only creates lightmap UVs for a mesh, but also optimizes it by potentially reducing the amount of vertices overall. This is a cool sideeffect, but not documented, and messes with bloed’s functionality of updating generated texture coordinates…
- I tried to create prefabs with an instance of a bloxel level - this does not work, at all. There will be a lot of research needed to find out how to make this work.
- I did some work on my 7dfps entry, but I don’t think I will be able to finish anything meaningful. Still, it was a good way to get back to networking stuff again, and pulling my hair out over authority and latency and other fun termini.
- I laid the groundwork now for a multiplayer-based first-person Sokoban. Not really the best idea I ever had, but it’s something I can do. It also became a gridder, which I didn’t plan to do, but it makes it easier to implement via networking, and it’s so much smoother already than sending transform position updates all the time.
2020-12-05 / 2020-12-06
- The more or less last step for the texture processor scripts is on its way - making a dedicated tool window that doesn’t need a ScriptableObject. It takes a bit longer than I thought because I don’t want to have too much code duplication, but it seems necessary in this case.
- I gave another course for our students, this time about making a simple dialog system with C# in Unity. Last week it was about doing basic enemy AI. I basically sat down and recorded 1.5 hours of me writing code, while also doing it via a Jitsi server, so people (when there were any) could also aks questions. The next course will probably be about shaders.
- Not much to talk about these days. We’re busy with tutoring students, and with trying to find a new direction for our next game project.
Other than that I managed to implement a semi-working solution for auto updating texture processor assets if the source texture changed. It’s probably not the best for performance, but I tried a lot of things and this was the only working way: utilizing void OnPostprocessAllAssets().
- 7DFPS is soon, and I’m planning to participate. I would like to use bloed, and the current idea is to make a first-person Sokoban for one or two people. So it would be a good idea to look into Mirror (or another networking solution) once again before it starts.
- Working on a texture processor script for/in Unity currently, and the usual complaint still holds true: serialization of objects is a big hassle.
- It would be nice to have some kind of texture editor (for changing colors and resolution, etc) inside of Unity which does not rely on having special shaders. Maybe I’ll create something like this next, as an add-on for bloed too.
- As planned I managed to add multi-level editing in bloed, which basically means I don’t necessarily need to have one single bloxel level only in a scene now; it can be several. For that to work in a meaningful way I had to extend all the tools to work with transformed bloxel objects, which was the biggest chunk of work. I also didn’t test it yet with prefabs, which might break it.
- One nice-to-have feature for bloed that I want to tackle next is the possibility to have more than one level in the game. This way it would be easy to create singular architecture, like houses, and duplicate it, move it around, rotate it, maybe even make prefabs.
- After working a bit more with RealtimeCSG, and not even using every functionality, I must say it is very pleasant to use and definitely feels powerful. Definitely the best tool so far for prototyping levels, and in this case making the final geometry too probably.
- The noisy texture feature for bloed added some complexities that I mostly solved, but probably not completely. For example, changing the texture of cube can change the geometry now, so it’s not enough to only update the UVs. Anyway, I updated the “official” bloed documentation, to version v0.4, and as we’re pondering about using a different level design tool anyway, it might really become a release on itch.io relatively soon.
- I watched some of the Handmade Seattle talks, at least on the first day, and oddly enough, the Unity talk (about DOTS) by Elizabeth Baumel was the most interesting to me, even though it did not really provide much new insights. The talk by Ramón Santamaría (developer of raylib) had a fun concept, but unfortunately I didn’t understand much due to his accent (and me doing other things on the side).
- Among some other small things I added the ability to have “noisy textures” to bloed. “Noisy” meaning that I can add positional noise to individual bloxel materials. This is still experimental - and very bad for performance if you’re regenerating all meshes at once.
- The Handmade Seattle sounds interesting, even though I am much more of a high-level kind of programmer. I was always interested in low-level programming, but I know I will seldom, if ever, use it for a serious project. Anyway, in my time-zone the conference goes from 6pm to 12am.
- I tested RealtimeCSG a bit - while I’m really not confident with the controls, I can see how powerful it is for quick level prototyping. The documentation is not great (I still keep forgetting how to add Boolean Operations), but in the end the only thing that makes me hesitant to actually use it for our next project (which won’t be Behind Stars) is the fact that there is a new tool by the same developer in the works called Chisel; and apparently they’re working together with the SabreCSG creator. Which means RealtimeCSG will be obsolete sooner or later. I am actually excited for Chisel, but our timing might be a bit off here, again.
- I probably won’t talk about the aforementioned ‘next project’ for a while, just to see if it doesn’t die too early. But overall it means Behind Stars and Under Hills is on ice for the foreseeable future. Again it became too much of a monster, and we were not able to tame it. I might write more about it later.
- “Our Machinery”, a new 3D game engine, is out in open beta now for a few days already. I actually applied for the closed beta a few months ago already, but other than downloading it once and having a quick look at it I never really investigated. Maybe someday I will have more time for it - I am still kind of interested in it because you program it in C, which sounds strangely appealing to me, even though it only supports Vulkan and no OpenGL.
- There’s another game jam by the bpb (Bundeszentrale für politische Bildung) announced, online of course, thanks to Corona. I really enjoyed the local events we visited, so I am not sure if I will feel the same with an online event. The theme is “gender” - no idea if I, as the typical cis-man, could create an appealing prototype out of this. So in a sense, it’s an interesting challenge.
- I will, at least for a bit, participate in the 11th Clash of Realities. I don’t actually have a deep understanding of what it is, but Professor Jonas Hansen recommended to us and our students to visit it, so here I am, complying.
- My actual productivity is still pretty low, especially as everything is “in-between” currently. There would be a lot of tasks to do for Behind Stars, but what we actually should do is plan more. Every decision we make feels wrong somehow, which is an awful situation. Of course it could just mean the project is wrong in itself - but then again we never found a good alternative…
It’s also frustrating for me that a lot of my personal projects (Demon Thief, Stealth Gridder, etc) never came out of the prototype state, so I get more and more cautious - maybe too much so.
- Slow progress currently, mostly because of personal life things. But we both downloaded the Unreal Engine with the firm intention to try it out soon, at least for a little bit. Just so we can maybe help our students who choose to use this instead of Unity.
- We’re currently thinking about transforming Behind Stars’ general structure from a full game to several smaller episodes. This way we would be more free in level design and story design.
- Although I’m still not convinced that anything I’m doing isn’t nonsense, here is my approach for the immersive sim aspect of Behind Stars: game objects that should react to actions (named Traits in my prototype) need scripts inherited by Attribute (inherited by MonoBehaviour), one for each Trait. There are three semi-different types of Attributes.
The first Attribute type is the general case - every time its Trait is applied, it calls OnAffect() and decides what happens. The simplest example would be “hit” - so every time the thing gets hit its condition worsens, and that’s it. It is also allowed to have Traits that get applied several times over a timespan, let’s say a spell that hurts the enemy for ten seconds, and it loses 1 health point every second.
The second Attribute type is similar, but it doesn’t allow several Traits at once - an example would be a wooden crate that burns: applying more fire Traits won’t give it another “burn” Trait (but it might make the current one stronger).
The third Attribute type is a specialized version of the second one; it allows to differentiate between sub-types of Traits. For example, this can be useful for if there is an Attribute that lets an NPC get poisoned by all kinds of poison (snake venom, mushrooms, spells, etc.). So they can be affected by several kinds of poison at once; and even have immunity against certain kinds of poison.
This could all be stupid over-thinking, or the direct opposite - only actually using this system will tell. But what I have to think about soon is some kind of “answer” by the Attribute for Traits, or rather for the Traits’ source. It would be fun to be able to have things like matches, and only if something burnable is touched by it, it gets consumed. On the other hand this is not really how matches work, so maybe thinking about this is not necessary? A better example might be picklocks, they get “used up” as soon as they combine with a door lock, no matter if the picking is successful or not - but they shouldn’t get destroyed if the player combines it with anything without the Lockpickable Attribute. Simplest solution for this would be just telling the Lockpick Trait’s Source object that the action actually commenced, but this feels unclean.
- We’re currently doing a “game jam” with our students for the course we’re giving at the Burg Halle. They have to build some kind of atmospheric room, based on a poem by Christian Morgenstern. The results so far are promising - I don’t think I could have created stuff like this back then in university, but then again our tools were much worse, and there wasn’t an asset store...
- After some thinking I will go back to a more or less pure MonoBehaviour based solution for the immersive sim prototype. Because I fear the complexity is increasing even though I wanted the opposite. It just doesn’t make much sense (probably) to fight Unity’s current approach, instead of just using the engine’s features. It would probably be different if I were using the DOTS stuff, but I don’t see me using this in the near future. I should keep looking into it though, otherwise I will definitely become obsolete sooner or later.
- I did some prototype code for Behind Stars’ immersive sim aspect, and while I am sure this is not how you should do it, so far I like my solution. I am just not sure yet it will be applicable for all the needed use cases. And if the performance will be good enough when there are hundreds or thousands of objects.
- I am currently doing thought experiments about Behind Stars and Under Hills, especially about the immersive sim aspect. On the surface it sounds easy enough: make a system where (potentially) every object can react to (potentially) any action. As usual the devil is in the detail, and in the implementation. Checking every type of object against every type of action is madness of course, so I have to find something that is less verbose. I’m definitely not the greatest programmer, and stuff like this makes it more obvious to me.
- I can really imagine myself making a very small game with this. I like the idea of PICO-8, but I actually dislike the resolution of the programming window, so this might be more up my alley.
- As part of the Halle of Games festival I showcased It Rains. I also participated there in a 2 hour workshop about making board games, which was pretty cool - the coach was a fellow game dev who did board games and mobile games before. In any case, this was a very long but eventful weekend, because we were at the festival the whole time.
And while keeping children from destroying the computers and explaining the games to some of the visitors and also while helping out with various stuff (carrying chairs, getting pizza, installing software, etc.), I managed to re-program my Arduino-based “game pads” I created for last year’s summer showcase of the Designhaus. Those game controllers were part of a game I called Richtig Gute Buttons (it was nevery really good, though), but I took them with me and repurposed them with a simple game where you have to tap the right button at the right time. While I finished much too late and pretty much nobody played the result, it was still fun to fiddle around during the exhibition.
By the way, I had a hard time getting my old C++ code for RGB to run on the Arduinos - until I discovered that they’re Leonardo clones, and I tried to target Uno boards. Dumb me.
- While still not sure what Tree Defense, now officially called It Rains, actually is, I uploaded it to itch.io and called it a day. I like the overall feeling the “game” has though.
- I finally updated the “official” version of bloed by extracting all the changes I did in Demon Thief and calling it v0.3. I even updated the documentation accordingly. I’m entertaining the thought to put it on itch.io for two or three dollars, just to have it “out there”.
- For Tree Defense I digged a bit deeper into Heaps these days, because I wanted to know if I can dynamically change the vertex colors. It’s unfortunately not that easy. I also noticed a graphical glitch - for every mesh with vertex colors the last vertex would be black, no matter what color I assigned to it. In the end I submitted a bug report, because I couldn’t find the error in my own code.
It doesn’t matter anymore anyhow, because I switched from vertex colors to a shader that would take an additional texture which I can actually change on the fly during the game. The current result is promising, and it looks nice. The game is becoming a simple “simulator” more and more.
- So far I did #inktober nearly every day, even though I hate everything I drew, so maybe I’ll stop the next days.
- Today I worked on Tree Defense, doing things I didn’t plan to do. But I added a compass that shows the current wind direction, because I plan to change the player’s actions from planting trees to creating clouds. The clouds will rain, and follow the wind direction. The player's task is to water the trees with the clouds and help them to grow this way, basically playing “as the weather”.
- Commissioned by Jana, for the Silbersalz Festival I created a small program that would take a text string and directly convert it to a series of character codes (in binary). I used heaps’ Input Example as the basis for that. The interesting part was that it currently runs on a Raspberry Pi and while I hoped I could run the program via Hashlink, this didn’t actually work because Hashlink doesn’t support ARM devices. (Which I didn’t know before.) And I just couldn’t get the C code to compile on the Pi. In the end I just made it a HTML5 application, and it works okay-ish, even though it is prone to users pressing Escape or Alt+F4.
If I were to do this again I would probably use Raylib. Raylib can even run natively on Raspberrys, but not on the new one (4) because of some changes. But the desktop version would have been okay too. Update: seems this was actually fixed yesterday, with the DRM platform target.
- The trees in Tree Defense can die now - either by too much water, or not enough water. Before that I implemented the time concept, so everything is “automated” now, although nothing is balanced in any way. Adding some kind of weather is the next step.
- I made it possible in Demon Thief that interactive things (loot, buttons, doors, etc.) can take time before they actually get active. So the player has to press the mouse button a bit longer before it does something, and if they cancel the action - either by releasing the button or by unfocusing the object - it won’t do anything at all. This is something most games do nowadays, mostly because it adds a bit of “investment” for the player, and because you can make an action more meaningful by changing the interaction time needed. And third you can have more than one action associated for the object by distinguishing between short and long interaction - for example, in Gloomwood you open a door by clicking it, but if you keep the button pressed a bit longer, you open it slowly (and thus make less noise, which is always good in stealth games).
- For Tree Defense I did some things which unfortunately are not to be seen in screenshots. But at least now I can remove water from a tile/lake, and the camera controls were improved too. There’s also info visible if the player hovers a tile.
For the near future I want to add the concept of time - trees should grow by themselves (instead of me clicking on them) and use water from the tiles; water should evaporate over time, and it should rain now and then. The latter will be the “Tower Defense” part, where the amount of rain will get worse in the later game, and the amount of sunlight too much.
- I wanted to make a simple “level plan” for Behind Stars and Under Hills. While I could just use pen and paper, I actually needed something that lets me make the three-dimensional structure of the caves and dungeons much more clear. At first I tried Blender and later a tool named Tinkercad by Autodesk, but then I settled by just using Unity - together with Clayxels. This way I can create more “organic” caves, instead of just simple boxes, and stick them together.
- Demon Thief now has doors, at least conceptually. It seems editing the graph (the navmesh the AI agents are walking on) can be done easily, for example with tags; and these tags can be used to prevent AI from walking there, or not, and let them have the “key” (tag) to walk there. The biggest thing missing is the actual door graphics to make it look good.
- Small steps for Tree Defense: tiles can now “save” water, so they will actually be useful for the trees that I can place on each one.
- Small steps for Demon Thief: I improved the sword animation (this is an ongoing story), and added animations to the bow of the player. I also added some of the assets from the fantasy packs. Only by reducing the texture sizes they’re now actually usable for me.
- Small steps for Behind Stars and Under Hills: I wrote down the complete main quest in Miro, and now - together with what Jana wrote - it’s a good basis to discuss it and change it.
- For Tree Defense I tried to find some cheap low-poly trees so I can place them on my blocky terrain. This proved to be somewhat more work than expected, because as usual “free”, “clean”, “good-looking” and “easy to get” seem to exclude each other most of the time. In the end I decided to use an asset that I got from the Unity asset store by Broken Vector.
- We continued working on Behind Stars’ quest line - even writing down only the main quest makes it look like an entangled mess; but that might not be bad in itself. But overall we noticed we need to focus more on our core points (secrets!), somehow they get lost while writing a story.
- My brother visited us over the weekend, and among other things we played a short session with my newly acquired Story Cubes. While our attempts at spontaneous story weaving were laughable at best, it actually sparked a bit of hope in me that such “random inspiration” could be used for creating quest lines for Behind Stars.
- I skimmed over this water shader tutorial, it’s basic and still complex enough to learn something from it. The rippling effect was the most interesting, I wouldn’t have guessed it’s just a particle effect combined with a second camera for RTT.
- For Zauberwald, the text-adventure, my brothers and I discussed a bit if it would make sense to have characters that could roam through the different screens. Ultimately I decided that would be too much work and probably not that much fun anyway. Instead I want to have the characters working like other objects you can click and look at, but with a bit more interactivity for a ‘dialog’ with them.
- The application for our course for MM|VR is now online, so students can apply until October the 6th.
- I got my “water flow” algorithm for Tree Defense working, in Heaps. No idea yet if I will actually make a game that works, but it was an interesting experiment. I will try to do one thing per day, to minimize the workload, and keep the project interesting for me. If I see enough potential shortly before the deadline in 17 days, I might try to expand it to a usable experience.
- We worked on Behind Stars’ story a bit, especially by re-telling it. It feels it might come together nicely, but of course at least 80% is still missing. The next few days I want to just try to create quests and maybe tie the game’s plot together this way. I would be using Miro for that, as we already do all the planning in it.
- Even though I am a bit demotivated when it comes to Demon Thief, because it won’t be finished anyway, I am still working on it from time to time - for example, I added a bit of furniture from some Fantasy asset packs. I also like how the Thief-likeness is actually a plus for a lot of people, so I am still downloading a lot of photo textures from textures.com.
The Demon Thief project might be useful though as a test-bed for things we want to do in Behind Stars. E.g., I wonder if the system for the immersive sim mechanics actually work.
- Not much was done this week, but at least I fixed a strange, obscure bug that appeared in my bloxels; apparently my calculation for the UVs of bloxels with more than 2 sub-textures was wrong, but only if the “direction” was 1 (“rotation” didn’t matter). In the end it was just commenting out one line of code, but until I got there, that needed some serious code digging.
- I think I figured out an algorithm for distributing water in Tree Defense, but currently I am not really in the mood to actually implement it.
- I took Jana’s chart for the “immersive sim” gameplay of Behind Stars and Under Hills and extended and transformed it so it feels more like the blueprint for an actual game system. Objects in the game, either characters, 3d objects (e.g. furniture) or items, would be called Things, and Things can have Traits - which means you can, for example, give anything the “poison trait”, but only characters would actually react to it. On the other hand a lot more things would react to the “damage trait” - characters lose health, doors and chests get destroyed, items might disintegrate.
- The player has a much better sword now in Demon Thief, but functionally it still has a lot of problems. For example, it doesn’t work correctly when the player is crouching, because then the sword move into the ground... Also the enemy reacts more “rationally” now when they got hit by the player’s sword, as they’re instantly turning to the attacker.
Overall I’m currently thinking about stopping the project - not because I don’t like it (the opposite is true), but because it feels like wasted time that I should spend elsewhere. Namely: Behind Stars and Under Hills.
Nonetheless I finally chose some textures for the level I’m working on and placing them here and there. Even though the level is missing everything (lighting, props, enemies), it already looks much more “real” now.
- For the Climate Change Jam game I want to do, with the working title Tree Defense now, I started a Heaps project and generated a mesh for the ground via h3d.prim.Polygon. Currently I’m thinking about how to actually make the “rain logic”, i.e. how water will be distributed over the different tiles and their neighbours; it’s more complex than I anticipated.
- I am now more confident with the solution of melee attack of the player in Demon Thief. It’s a far cry from my personal gold standard Thief (I won’t even try to think of Dark Messiah, it’s too advanced for my aspirations), but already works okay-ish. Of course the animations are terrible, and don’t feel good yet, but at least they’re animations I can do in Unity.
- Some more small improvements to bloed - it uses a GUISkin now, so I can change the look much more comfortably. Also, as this was always a step I had to do manually, textures to be used for the bloxels are now automatically changed so they’re a) readable from scripts, and b) uncompressed.
- While I actually should work on the level(s) for Demon Thief, I actually do a lot of small things on the side, mostly beneficial for bloed. For example, the joists are much more integrated now, the hover marker and cursor work and look better, and the editor got some more colours. I guess there is a reason why I’m putting the important work off, and the reason might be that I know that Demon Thief won’t be finished in the 2 months anyway.
- A bug appeared in Demon Thief that was hard to track. It seems I made a change to the enemy’s code at some point in the past that broke the flee behaviour (and probably more). The problem is that for over a week I didn’t check if the fleeing was still working (because I didn’t suspect it wouldn’t), and now the enemy just wouldn’t run away after getting back to their start position. Thankfully, git made it easy to try out older versions of my project, and after a while I found the culprit - something bad happens when you set the destination of the RichAI component to Infinity. Which I thought would be the way to let the path-finding AI stop.
Turns out this is true, but when you use richAI.destination once, you have to use it always - you can’t just use StartPath() and then be done with it. So I have to manually set the destination to the last point of the path; which smells like a bug to me.
- The sword-wielding enemy of Demon Thief had the small but annoying problem that they wouldn’t be able to hit the player if they’re standing on stairs, because even with the Look Animator the slash animation is vertically too limited to reach the player’s hit box. I circumvent the problem by moving the sword’s hit box up and down, into the direction of the player. This is very hacky, but at least it works.
- While I’m busy every day downloading textures from textures.com, because I am actually building a somewhat larger level for Demon Thief nowadays, I also added the BloxelJoist tool to bloed. First I had it as a parallel tool to the bloxels, but then I decided to make it a subtool just like the Texer or the Cuboider. It works quite fine this way.
What I noticed is that the levels get quite large, and I have to be careful not to upload the gigantic meshes to git. I can remove them before I do that, so that’s what I do.
- Tried to build a small room for Demon Thief with bloed. Made a video of the “result” so far. In other news I bought 2,500 credits on textures.com, so I can download all the low-rez textures I need for this game, without having to wait days (you only get 15 credits per day, and those are only usable for that day).
- I ported the joist tool from Behind Stars to bloed, but it’s not done yet. Especially as there are some hurdles with duplicating a joist and actually deep-copy a mesh. No idea yet how to do it.
- After some trial and mostly error I just name the mesh the same as the instance ID of the game object - if it’s different, it instantiates a new mesh. A bit hacky, but it works well enough.
- It would be cool if the joists are actually part of bloed, so you can create them with one click (instead of having to create an empty game object and add a BloxelJoist component manually).
- For the upcoming Climate Change Jam for the Silbersalz Festival I’m planning to make a small game in the vein of a Tower Defense. My biggest problem right now is to find the right tech, because once again I would like to deviate from Unity - so far the options are Heaps and Godot. Heaps would be interesting, because I’d like the game to be 3D and I never made a 3D game in Heaps, but that also means I would need more time for the development-
- For a change I worked on bloed again - because I needed something for Demon Thief. I added the ability to have different standard bloxels and different methods to set them. This way I can, for example, create a floor automatically, and for the first level I want to make this means I will need less bloxel data (probably), reducing the level’s memory hunger.
- Fiddled a lot with the settings for the ragdolls in Demon Thief today, but there are still a lot of edge cases where they are wonky, wobbly or just plain crazy. Physics in computer games is the bane of my existence.
Thankfully, making the archer skeleton a bit more aware if there’s a companion in front of them or not (and thus not shooting them in the back) was less work than I feared. Of course friendly fire still happens a lot, but that’s actually okay. If it happens too much I can make enemies just immune to it.
The third thing today was refactoring the UI a bit so it works as a separate scene. This way I can test levels more easily; and eventually I will have to separate all the game logic too.
- I have the API help for EditorTool still in my bookmarks because I will use it definitely at some point, but so far I didn’t get around it. No idea if there’s a big advantage over the old method of creating editor tools, other than having a neat icon in the scene view.
- Insight of the day: raycastHit.transform is not necessarily the same as raycastHit.collider.transform.
- I finally created my first ragdolls and added them to the enemy of Demon Thief. Fortunately there are automatic tools for this nowadays, so it didn’t take long to prepare the model. The only “problem” was that I forgot to deactivate the LookAnimation component, so the ragdoll would behave like crazy. I also noticed that the best approach for my enemy’s death is that I only activate the ragdolls in the middle of the death animation. I alwas dislike it when characters have no dedicated death animation and just get to being ragdolls instantly, which makes them look like unimmersive puppets. And I can’t activate the ragdoll at the very end of the death animation, because that often clips the model into the wall and would lead to glitches.
- Apart from a tiny bit for Demon Thief, the biggest achievement today was that we discussed Behind Stars’ story and quests more. In my opinion it makes sense, is not too psychological and a good foundation to build on. Of course it is very trope-y, which I would love to improve, but on the other hand we’re already alienating people enough by having characters with animal heads. So more familiarity is probably a good thing.
I also created a mindmap (on a Miro board) for the gameplay, and it’s a mess. But somehow everything is “important”. The next thing now is to prioritize (although we already identified the core gameplay), and simplify. The amount of gameplay elements will probably not decrease, but with every element we will have to think hard about how to implement it in the simplest way possible. For example, pausing the world in a dialog is good, because you won’t have to deal with strange AI problems. And with a simple screen fade you don’t have to check if the character is standing at the correct point to talk to you. And so on.
- Demon Thief, yet again. I worked a bit on the inventory of the player. As most things in my prototype it’s inspired by Thief, where it definitely existed, but was very simplistic and a bit hard to use. (The latter I will try to do better - mostly by reducing the amount of items available...) I also added the usual highlighting system (already in use in Behind Stars), to improve the visuals when hovering an interactive object.
- A while ago my brothers and I hatched a plan to create a text adventure, inspired by an old C64 game we played as kids. For this project, code-named Zauberwald (after that text adventure), I now made a prototype in Twine. This was actually interesting, because I tried to create an inventory and object system with Twine’s Harlowe macro system, and it was kind of doable.
- Enemy AI, day 1986342. The archer enemy in Demon Thief can now shoot up and down, depending on where the player stands. I was too lazy to actually find out how to calculate the trajectory from the point of impact, so I searched in the Unity forum and found a thread with code that did what I want. Finding out why it didn’t work out of the box and fixing it took quite some time though.
I also added a second enemy skeleton for the first time. I always expected it to go totally haywire, which is why I delayed this step. In any case I found an animation bug this way, and it made me think about how to prevent an archer from shooting another enemy just because they’re in the way…
For the enemies to look into the direction of the player in a “natural” way I bought an asset called Look Animator. It produces strange results so far, so I have to tweak it a lot more I guess. It also created problems with a script of mine that makes a GameObject following another - this doesn’t work anymore in a specific case because the Look Animator moves the object further after I moved it with my script. Oh well, maybe I’ll look into that too.
- Made a video of the far range combat behaviour in Demon Thief, and the flee behaviour.
Furthermore I (hopefully) improved the “suspicion” behaviour the enemy. One of the problems was the reaction of the enemies for when they were hit by the player’s arrow. Enemies should search for the player when that happens, but not directly run at the player. The reaction should be different if the enemy is already inspecting something suspicious. And so on. As usual, it’s a fractal of a problem area, and it only gets more detailed the more you look at it, but never really solved.
- As planned I extended Demon Thief’s enemy’s behaviour so it supports ranged combat. It was a bit tricky because I want to have both enemies that can switch between ranged combat and melee combat, and enemies that only have a ranged weapon. So the latters have to “flee” as soon as the player approaches them, and find a spot to attack the player from a safe distance. Later on I even want melee fighters that only use some simple far range weapon (like stones picked from the ground) when the player is not reachable. But that’s for the future.
I also added the “quest” system. Because of the possible dependencies between single quests it took longer than I thought. Next up: better behaviour when the enemies gets hit without them knowing about the player yet, better death handling (not sure I want ragdolls though), some limitations for the player’s arrows, the enemies being able to shoot up and down. And while the AI will probably never be finished I really should look more into the visual design aspects of the game, not later than the week after next.
- We’re doing more and more planning for Behind Stars, and we now have a very, very rough story, and some fractions that should be part of it. Overall I’m confident we can write some interesting/fun characters with it.
- Demon Thief. The enemy’s behaviour tree now has flee behaviour, which is a lot of fun. Because whenever their health is low they run away to a randomly chosen point, and after a while come back. But when they see the player again (or just hear a suspicious “sound”), they run away again. I also added the ‘getting hurt’ animations, which really brings it to life, and the player now gets visual feedback whenever they’re hit.
Next I want to add ranged combat for the NPC. To take a break from the AI I will also add some kind of mission progress soon, so the player gets tasks in the beginning (“steal 500 gold”, “kill this enemy”, “don’t get seen”) which get ticked or crossed off during the game. When they fulfill all tasks, the mission ends. (Note to myself: to have a task that forces the player to return to a certain place to end the mission, I need to have tasks that are dependent on other tasks. And in order to not confuse the behaviour tree tasks with mission tasks, I will call them quests.)
- I gave the enemy “AI” in Demon Thief some “suspicion” value, and whenever this value raises (e.g. by a sound caused by the player), the enemy walks towards the suspicious target point. When they reach it, they choose another point randomly near this point, to look a bit further. This is all a bit wonky still, but a good start.
My biggest problem with behaviour trees right now is that they are kind of stateless, so I have to find a way to reset values when the character switches from Patrol to Inspect behaviour and vice-versa. So far I added an Initialize(string) task that instantly returns when the parameter is the same as last time it was called. Otherwise it resets some values, depending on the state that was set - which probably is not what one should do in behaviour trees, because it’s by design not a FSM.
- I compiled a test Unity project to WebGL just to check the generated C++ code, because the discussion with Felix about if (gameObject) and if (gameObject != null) left me wondering. And lo and behold, the generated C++ code is pretty much the same - the first line of code actually becomes Object_op_Implicit(gameObject), which itself calls Object_CompareBaseObjects(param1, NULL). And the second one becomes Object_op_Inequality(gameObject, NULL), which in itself calls Object_CompareBaseObjects(param1, param2). So I guess the first version is a tiny bit better, because one less parameter is used. But Felix actually claimed the first version would catch more null errors, which I can’t believe right now; maybe the result is different when Mono is used as back-end instead of IL2CPP, but I doubt it somehow. Only real-life bugs will tell.
- Had a discussion today about how Unity’s Objects and their weird behaviour regarding null can be confusing. I stumbled over this today because I tried to check in some method in a generic class if a generic parameter is null, and forgot that a UnityEngine.Object can be null and not null at the same time, so I had a (thankfully small) bug. After that I discussed with Felix about the differences between if (gameObject != null) and if (gameObject) to check if a game object exists - it’s interesting to me because I always used the former. I read about the whole matter ages ago and what I took away from it is that both forms are okay, but the first one always felt more explicit to me and easier to “read”. But Felix said the second form should be preferred because otherwise it leads to bugs (“it explodes”) in edge cases like level reloads. I need to test this next time I encounter such a bug.
- I implemented some very rudimentary “bow” mechanic in Demon Thief, just to switch to a different task while I still mess with the AI, extending it and fixing bugs on the way. The suspicion level should be the next addition, but also some flee behaviour, because it would be strange for the enemy to stand around dumbfounded while they’re hit by arrows.
- I’m still occupied with the “AI” of the enemies in Demon Thief, and I am sure I will be for quite a while. At least the test-skeleton now sees the player and immediately follows them - later on there should be a “suspicion level” of course, and different movement speed for patrolling and following. In any case I enjoy PandaBT a lot more than NodeCanvas so I bought the Pro version. Even though the developer of PandaBT doesn’t seem to be active anymore, at least that’s the word on the official Unity thread. Thankfully the Pro version has the full source code, and some people are still to active in the forum.
- We tried to give the possible gameplay elements of Behind Stars different priorities, but in the end we couldn’t really decide. It always comes back to the fact that we somehow want to have everything, but mostly: talking to NPCs, running around, finding secrets. A bit of alchemy would be cool too. Oh, and of course some challenging combat. And so on.
This is why we need to create some scenes to test the style, and several prototypes for the different aspects of the game. We played through the last iteration of the game to check out what we would change, but mostly we were like “that’s so cool, let’s keep it”...
But, on the bright side, even if Demon Thief won’t be a success (in terms of “getting finished”), it definitely can already serve as a pre-version of the new Behind Stars, because implementing the AI/combat is beneficial already. It doesn’t have to be innovative, it has to be fun. In my opinion we should concentrate on the aspects “secrets” and “alchemy” for the innovation - I’ll think about it.
- Created some simple patrol path editor for the Enemy class in Demon Thief, and now the skeleton follows pre-defined patrol points. I am slower with this project than anticipated, but it’s still fun somehow. Next up: enemies should sense the player. It would also be cool if I could define wait times at each path point, to make the patrol behaviour a bit more interesting.
- Today was the “official” start of my 2 month project Demon Thief. Currently I’m mostly occupied with creating enemies, because they will be one of the most important aspects. I have the websites/documentations open for Animancer Pro, A* Pathfinding Project Pro and Panda BT (Free), switching between them all the time. Panda BT is now what I plan to use for the behaviour trees of the enemies - reading the documentation was a breeze, and it looks like it should be powerful enough for my needs.
- We created a time schedule for our next projects (mostly our personal projects, Behind Stars and Under Hills, and teaching at the Burg Halle next semester), and the rest of 2020 looks pretty stressful…
- A user at the A* Pathfinding Project forum told the developer that they found another pathfinding asset and they’re happier with it. I was curious so I wrote them, and they recommended Super Pathfinding System. As I still have my problems with A*PPPro I will have a look at this.
Update: Looks a bit too simple for my needs. The example video/screenshots also show some errors in the path...
- From next week on I will “officially” work on my 2 month project (working title “Demon Thief” for now). It will be a Thief-like made with Unity. I plan to use the following assets, but nothing is set in stone:
- Bloed - my own level editor. It’s not really finished yet, but should be usable enough for this kind of project.
- Rewired - a very powerful input system that makes it much easier to support gamepads; a must nowadays.
- Animancer Pro - for easy animating the characters without having to annoy myself with Unity’s Mecanim.
- A* Pathfinding Project Pro - for letting characters walk around in the levels. I’m not really sure about that one yet (see earlier log entries, and the SEEN above), so I might have a look at other assets before I start. It seems to work though as long as I don’t try too complicated stuff, and as long as I don’t need support on the forum. The character being able to reach the player without getting stuck is the essential thing. (Note to self: use breadcrumbs maybe?)
- NodeCanvas - for the “AI” / behaviour trees of the enemies. I haven't really used this for a few years now, I think last time it was for our 2D co-op prototype Power of Love, and I wasn’t happy with it. Maybe because I was using it wrong, but mostly because it felt like overkill. So it could be that I will just use MonsterLove FSM (on github) which I actually already use for my Utility Theory AI system (I could use that one too, but I don’t think it would be a good idea with this project, as the enemies are not needed to be emergent and human-like). In any case I just want to do simple BTs instead of trying to be too fancy with AI. Another asset I could try in this regard is Panda BT Pro.
- LeanTween - probably for tweening, but I might have a look at DOTween Pro’s capabilities again. Maybe my own naive implementation (RatKing.Base.Tweens) is enough though.
- More Effective Coroutines - I import it often in my projects, but I might actually omit it this time, because I mostly use the functionality of delaying function calls, and that one is also handled in my RatKing.Base.Tweens class. Probably not as effective though.
- Rainbow Hierarchy 2 / Rainbow Folders 2 - because they make the project much neater, and a little bit easier to handle.
- QHierarchy - just to have extra buttons for hiding/showing game objects right next to them in the Hierarchy window. Can’t live without it.
- Console Enhanced Pro - not that much needed anymore as Unity’s standard console window was improved a lot since I purchased it, but it still has a few advantages.
- Several fantasy 3D model assets, because this will be an asset flip...well, they were on sale during the “Discounts&Dragons” sale on the Unity Asset Store, and I know that I won’t have time to do all the models myself. So I don’t see shame in trying to save some time. I also don’t expect to win a design award for this game.
Other assets that might be interesting for this project are: Mtree, UMotion Pro, Volumetric Fog & Mist, Wire Builder, Search Grid, Odin, VertPaint, Bakery (for light maps), MK Glow, Mesh Combine Studio 2, Puppet3D (for rigging), Final IK, Easy Decal, Amplify Shader Editor, Amplify Color, Highlighting System or Selected Effect, Hx Volumetric Lighting, GraphIt, Colorful FX; and maybe something for gameplay scripting (MiniScript).
- Did an A4 page of nude drawings and even after a day I don’t really hate it. Either I’m getting ignorant towards my shortcomings or I really should draw more again.
- After some more tests with A* Pathfinding Project Pro I am still not sure if it has been improved significantly. Seemingly simple problems like just letting the AI Controller follow the path while always looking into the right direction turn out to be a hassle already. Meh.
- During vacation I prepared a bit of the groundwork for my 2 month project. I want it to be a stealth game in the vein of Thief, so I took bloed, the character controller of the Behind Stars prototype, and the light gem functionality of the ping-pong project and combined them. So far so “good” - a lot of tweaking is necessary of course, and the most important thing (the AI) has to be prepared sooner rather than later.
- For the upcoming projects I bought a Unity asset called Bakery. It’s a much better alternative to Unity’s own lightmapping stuff, and it already was much faster both in terms of usability and in plain lightmap baking. I will do some more tests if it actually is a good tool to use for the 2 month project and for Behind Stars, because of course I need a combination of dynamic lighting and static lightmaps.
- Another asset I bought is the A* Pathfinding Project Pro (I still dislike the name). We actually used this before, mostly for Solitune, but since then new versions came out which meant we had to buy the upgrade. I hope the asset was improved a lot, as I had problems when I incorporated it in Solitune - strange behaviour of the character controller and so on. But it’s one of the most popular assets on the Asset Store, so my guess is that I just have to dig deeper this time. In any case, I do hope it will be helpful with the 2 month project, because I don’t want to put too much work into things that are solved already.
- I am creating yet another “music video” for one of my brother’s tracks (as usual with HitFilm Pro), for Behind Stars this time. It’s a bit bitter-sweet, because it makes me going back to the prototype, specifically the (very old) “Outpost” level, and capturing some scenes.
- Currently reading the Arduino Kompendium by Danny Schreiter. Even though this is beginner stuff which I already know, there are still new things I didn’t know (which shows that I didn’t too much with my Arduinos yet). So books like this help me to get back to electronics, which interest me but will be obscure to me forever and for which I apparently never have a real project. The latter is the reason why I never learn something “properly”.
- I uploaded version 0.2 of bloed, so if there will be someone testing it some day, they will now have to have both project settings and individual level settings. The updated documentation describes it in detail.
- As usual, small things can be more complicated than you’d think initially - like calculating the field of view in a grid-based roguelike. This algorithm is pretty sound. I wonder how easy it would be to have both diamond-shaped and box-shaped walls in it.
- Nicely done article about light and shadow by Bartosz Ciechanowski, as it visualized the math behind it pretty well - and you can interact with it!
- Pretty voxels (blocky and not-blocky) for Godot - unfortunately this “plugin” must be compiled into the engine, so I will probably try it much later only.
- For bloed I did the first steps to be able to have different settings for different scenes. Which means one scene can have boxes as standard template (so you dig into the level) while another scene would have air as standard (so you build the level from nothing). The only problem remaining for this is that I put all the standard templates and textures, and the lists of templates and textures, into the BloxelSettings, and those should actually be saved globally.
In the future it would be interesting though to be able to have different sets of textures for different levels, so you plan the size of the texture atlases better. (This wouldn’t make as much sense for the templates.)
- As I subscribed to Jackson Dunstan’s blog I also read his series about C++ for C# programmers. It’s still interesting even though I know a bit of C++ (I used it a lot in university actually, in combination with Irrlicht and OGRE, but I never was really proficient in the finer details of the language.) The thing is that you learn something new about C# too, and I found the article about references particularly worthy of a bookmark.
- Unity made the visual scripting asset Bolt free today, as they acquired it a few months back. I might have a look at it, just because it could be fun to use it, and maybe even teach it. A successor is also announced, and it probably won’t be fully backwards compatible. So I’m not in a hurry to try it out, but the option is still nice.
- This looks interesting - DREAMUV, which also includes an automatic UV unwrapper. I did think it looks like it would be straight out of Valve’s Hammer, and then I saw the creator actually is a Valve employee. It’s cool that they use Blender too.
- Unity 2020.1 is finally out, and there seem to be one or two features of interest to me. But overall it feels meh more and more. Which is probably because I will never be an AAA developer.
- The Coxel-like is now done (not really, but the main functionality is there), and even after all the problems I had I actually think I will try to use Godot some more. I still find the whole node system somewhat unnatural for me though. Being able to use C# made the engine much more approachable to me, especially as I had a look at my old GDScript code in other projects and didn’t understand much anymore.
- More Godot woes are coming, as I’m still trying to port my Coxel-like to it. nuget restore helped to remove the annoying dialog in VS Code that told me on every start to restore the project - I tried dotnet restore, but that was obviously the wrong choice.
Now I have to battle with the fact that I got the problem again where the project would only build but not play whenever I press F5. It does work if I start it from VS Code though, so it’s only 50% awful.
- I “optimized” bloed a bit by removing the list of strings for saving the unique IDs of all the templates and textures, and replacing it with lists of indices which would refer to lists of the IDs inside the BloxelLevel script. In certain cases this might be even bigger, but most of the time it should remove a bit of superfluous data.
- I created a documentation for bloed, so I (theoretically) can give it out to people who are not me. Not sure what kind of feedback I expect though.
- With bloed being not finished but at least mostly usable now, it might be a good idea to make a little prototype game with it, maybe a shooter or a simple adventure game. For Behind Stars I’d like to make a combat prototype that should be very quick to create (at least that’s the goal) and still be interesting and challenging. The bloxels would be a good way to test the terrain for that.
- Bloed is consuming most of my free time nowadays, because it’s the most rewarding hobby project I have currently. So since my last entry I added a copy&paste tool (not finished yet) which lets the user rotate the copied bloxels even - this wasn’t possible with the Copy&Paster in the Behind Stars editor Morited. It does not copy extra side data for now.
I also tried to add round corners as bloxels - they produced problems with the UV generation, and while I mostly fixed it somehow, they made it apparent that the Texer tool needs an additional option to set the offset of bloxel sides. Because otherwise there will be visible seams much too often.
- I’m thinking about the “2 month project” I want to do after we are finished with the contract work that is currently occupying us. Two months because this is the time we needed to to publish Pitman on iOS back then - the game itself was done in the first 7DRL Challenge we ever participated in, so this is a good point of reference. This means I will try to implement the game in one to two weeks, the rest is polishing, testing, bugfixing. Overall I’m looking for a very small project that still might be commercially interesting (probably donations-only though, or there’s a version with soundtrack that you have to pay for). Other than that I’m mostly hovering over ideas that are too big for now.
- I added the (player) character controller I wrote for Behind Stars and Under Hills to the bloed project. It was actually kind of managable, but there are two rather big dependencies that I’d like to remove: LeanTween (for the camera shake stuff) and Rewired (everything input). The first I maybe can implement myself, and for the second I might just create a wrapper, although I dislike to have too many layers.
Of course I need to remove the controller should I ever make bloed’s code public, as it’s not needed and bloats the project too much.
- I’m still working on bloed from time to time, and it’s still all about re-implementing the things the old Behind Stars level editor had. I can be a bit more flexible now, and have some features faster, which is great. Currently it’s about tools that help to reduce the size of level files by letting the user to remove all superfluous bloxel and bloxel side data. This is data that cannot be seen - for example invisible cube bloxels with a texture other than the standard texture. Or side data for a side that is completely air actually.
- Ratings for the Alakajam #9 are out, and while I didn’t expect De Moleculis Motus in Vacuo to place very high I am actually pretty disappointed how low the ratings for the audio category are. Of course I understand that it’s hard to hear that I created all my own sounds and made my own music, but somehow this is a very petty community.
- I streamed myself while playing entries of the Alakajam I participated in, in order to gain some karma so my own game would not fall under the 8 needed ratings. The games I played were mostly interesting and fun to play, and the feedback for De Moleculis Motus In Vacuo is pretty good so far. Experience tells me though that doesn’t usually mean the ratings are positive too.
- Fixed an extremely annoying and hard to debug error in bloed today. In the end a single !chunk.Exist in an if() (with two other checks inside) was the culprit. The problem was to find out how to generate the bug reliably, and then to find out what could cause it.
- My Alakajam #9 entry has now a name: De Moleculis Motus In Vacuo, and it’s available on itch.io as WebGL and as Windows standalone version. Not the greatest game ever, but it works well enough. I even made some music for it; usually I just use random generators. I composed it with Rytmyk Studio.
- I started an entry for Alakajam #9; the theme is Connections. My project doesn’t have a name yet. Overall it’s very simplistic, which means the gameplay is mostly finished. The player has to remove connections (lines) between bouncing circles, because it’s game over if the connections intersect too often. Tomorrow I want to create some sounds and music; maybe a small local highscore.
- After several small bugfixes I did the first step of re-adding the Cuboider to bloed. The Cuboider is just the tool that adds/removes several bloxels at once. I will make it a bit more powerful - as it was in Behind Stars’ editor; it was able to change the texture of all surrounding bloxels. (Actually, that was the Framer’s ability, but in the end the Cuboider and the Framer were very similar.) This way you could easily create rooms that would be already equipped with the correct wall texture. Maybe I can even distinguish between wall, floor and ceiling now.
- The Texer tool of bloed, which lets you change individual sides of a bloxel, and also the Bloxer (i.e. the standard tool of changing whole bloxels) have now undo and redo. I overwrite the Z and Y hotkeys for that, but they’re both not really used when bloed is activated. The undo/redo manager is a very short piece of code - it just registers a System.Func<bool> (for the actual action, and for redoing it) and a System.Action (for undoing this action). It’s most likely not very memory friendly, but for now it works as it should, surprisingly.
The next step is to re-implement some of the old tools of the old Behind Stars editor.
- I now can have subtools again in bloed, so I added (rudimentarily) the old Texer. It allows the user to change the individual bloxel sides’ texture. Right now it only can change the index, but not the offset, so that’s the next step.
Update: apparently I never actually implemented being able to change the offset. Bummer. Other than that it’s mostly feature complete now.
- Just a short progress report - I worked on bloed from time to time, mostly improving the editor layout and stuff. Which mostly means I keep putting back the important work, which would be things like being able to change individual bloxel sides, oder creating several bloxels at once. I will reuse the system from Behind Stars and Under Hills for that - a collection of subtools that can be individually programmed and optimized. Back then I did them in Lua for a while, but that was much too slow anyway.
- We streamed again - but not via our own channel. Instead we talked with the people from Silver Seed Games about our game SOLITUNE, and about game development in general. It was pretty wholesome, although I wish some would have asked questions during the stream.
- I restructured the whole project for bloed so it uses “bloxels” instead of “voxels” now and is generally nicer to look at. I should send the stuff to some people for testing, but then I’d need to write some documentation.
- As I did more work on bloed I mostly battled Unity’s serialization system again, and it drove me crazy for a lot of reasons. I should write a blog post about my findings, although the infos are out there already. In the current case I wanted to serialize my bloxels not as references to their types but only as their UIDs - to save a bit of space, but more importantly to not lose those references when I add a new type and have to recreate all templates. This meant I had to save the list of templates separately, so I could recreate the list of bloxels to use their respective templates when Unity deserializes the scene. Which actually became the problem, because it’s not guaranteed that the list of templates is deserialized before the list of bloxels in each chunk. Which means I had to take special care of that, and in my case it thankfully works (after a lot of pulling hairs), but only because the chunks don’t need the bloxel list when the scene gets loaded; only when they get manipulated. Phew.
- Over the weekend I worked a lot on bloed, mostly doing more refactoring and adding small features like picking bloxel templates and textures. Seeing Oskar Stalberg’s tech is a big downer though, as I question my approach more and more. In the end though it’s just a matter of time - I need to release it as soon as possible, so it won’t result in depression when it’s DOA.
- We watched the noclip documentary about Arkane Studios, and a big part of it is about the games they worked on but never released, because of business reasons. I like the idea of the nail gun in the Ravenholm game, which lets you create “paths” of current in a relatively elegant way.
- I put the block editor for Unity on github, and named the project “bloed” (block editor); this after I tried to refactor some class and broke the whole project because of that. So finally I can do a bit of experiments.
For the curious, the thing that broke the project and myself was yet again the whole thing with Unity’s serialization of classes. To be able to reference something more than once it needs to derive from ScriptableObject, which makes a class very heavy. And if you don’t create the ScriptableObject as a real asset in the project, you can’t use it outside the current scene.
- We livestreamed once again as Spielgefährten on Twitch, where we talk about games and game design. This time we tackled Ultima Underworld, and - because it is heavily inspired by it - Behind Stars and Under Hills, our prototype that was never meant to be.
- Watched this talk about automated game apps that made actual money. Kinda depressing that those guys made more money with actual crap than we did with some ‘real’ games… But interesting nonetheless.
- Had to re-learn Rigify again, but thankfully it’s less complicated (at least on the surface) than it looks like. I guess I will remove almost all of the face bones and only keep some for the mouth, eyes and ears.
- The Unity block editor now allows adding new block templates and textures. It’s more than one step though, so far, and the changed texture is overwritten for all levels. Not sure yet if I want that actually. Maybe an interesting way would be to name the texture atlas according to the textures inside, and let a level define which textures it want. The question is if that is actually necessary?
- Because I semi-lost motivation to continue with the gridder - even though I still like the project and the idea - I want to shift the focus a bit on what to do next. While I do need some kind of working AI with pathfinding for it to become a game at all, I think switching to bit of level design could help with finding out what the game will look like and how it will play. And if some things I am planning are even necessary at all.
So the next step should actually be to write down a bare-bone story that will define what kind of levels have to be made. I know I want monumental, castle-like structures with three-dimensional architecture, but not yet for what and how much of it should be “realistic”.
- I added a rudimentary 3D cursor to the block editor for Unity. It works different now than with Morited, but I’m a bit limited by Unity and their already existing controls and hotkeys.
- We created a keynote video for a game jam for the Macromedia Hochschule; we basically gave tips and showed several of our (ancient) jam games. Let’s hope it’s not too awkward for the students; I know it was for me. But it paid off that we do some streaming (as Spielgefährten) now and then since a few weeks, because the style worked well for a keynote and let us do the recording in less than an hour. We used OBS for recording, and it seems it was a bit of a mistake to use MKV as target format of the video, because Jana had problems using it in Premiere Pro CS 5.5 - several attempts to convert it were necessary.
- I started to “texture” (more like colorize) the doberman model for the ping-pong project. It feels very old-school, or rather out-dated, to do a semi-manual UV layout and then paint (via Affinity Photo) on the UV islands. I should research on how the modern approach is, although I know don’t want to use something lik Substance Painter. Maybe the drawing tools in Blender are good enough?
- Update: a few hours later I actually used Blenders drawing tools to create the texture. As the model is mostly single colors, it was good enough, and quicker than the back-and-forth to Affinity in any case. Especially as there seems no way to automatically reload the texture in Blender when it was edited in another program. You always have to press Alt+R (when hovering the image window).
- The Unity block editor has now a much better way to set and remove blocks, by using a raycast. Based on Physics though - I tried to use Unity’s inbuilt picking system instead (someone found out how to utilize it), and while just picking a game object worked, casting a ray against it would semi-randomly choose a point on back faces, which is less than ideal. So I had to resort back to the Physics system.
This system of placing blocks is of course much easier to use than the one based on floor grids, but I’m missing the system I had in the Behind Stars editor, where I could place a block anywhere I wanted via a 3D cursor. Without it, you can’t even begin creating a level, because there is nothing you can pick… and creating large rooms was much quicker and easier to do. I will try to find out if that system is feasible in the Unity editor or not, although it depended quite a bit on how the camera system worked in Morited (Behind Stars’ level editor).
- The block level editor inside Unity now saves the texture by writing it to a PNG into the project’s Resources folder. This way I can directly apply it to a material. After that I felt fancy and quickly added the functionality to change the placement grid’s height, to be able to actually create 3D structures. Overall the editor plugin is bare-bones, and one messy hell pit of code, but it was fun to try to get it work. I always regretted a bit that I implemented Behind Star’s editor the way I did, even though it really made level design easier (IMHO) and allowed me to have some really neat tools.
- Additionally I added buttons to choose the block template (air, block, brick, half block, etc) and texture. I needed a bit of trickery because Unity’s IMGUI can act funny sometimes, but it works now. Of course it’s all very rudimentary. In any case, next up would be a preview mesh for what you are currently placing.
- Worked a lot on the block level editor inside Unity - I was mostly trying to make sense of what gets serialized and what I should replace. Because I hit some soft and hard limits I had to refactor some classes and data structures and now it’s probably uglier than ever, but it kind of works. What is missing right now is a way to save the texture atlas for the materials, so I don’t need to generate that every time.
- Another episode for our live-stream Spielgefährten was done last week (Deus Ex), and this evening there will be another one, about Dark Souls. It’s fun to do this stream because we actually talk about game design now and then.
- While doing more stuff for the Unity-based block level editor, I notice that I am very unsure where should be saved what. Is the generated texture atlas something for the current scene only, or should it be shared between several scenes? Is the generation of the block faces something to be done in a static class, or inside the level script? Is a static class needed at all? What belongs into a ScriptableObject, what does not need to be saved in the editor window? Exciting questions!
- I did some more Blender-ing and “finished” the doberman model. Next steps are UV unwrapping and simple texturing, and rigging. I will most likely use Rigify, because Maximo’s rig doesn’t have stuff like inverse kinematics.
- I forgot that I did some small stuff for the Gridder; the player can climb now into the correct directions. The problem is that I am still unsure if the project is actually worth it...
- I started a little experiment: I tried to import the block-based level creation code from Behind Stars and Under Hills into a blank project and use it for a Unity-based level editing plugin. There weren’t many errors and I am positive that it will work in the end; I already can click in the scene and it creates the chunk meshes as it did in the original. The biggest problem right now is that I use a lot of Dictionaries and those don’t get serialized by Unity, thus changes won’t be saved consistently. I could use OdinInspector, but then I wouldn’t be able to distribute the editor if I’d ever fancy that. So for now I’ll try some of the free stuff to create serializable Dictionaries.
- While I have more than enough projects already, I still think about doing a level editor within Unity. So I’m going to research and tinker with Unity’s editor scripting capabilities once more.
- The Gridder has now a semi-functional player controller again, mostly copied from the former prototype. Climbing is not really working yet, because there is no thinking ahead, which would be needed to use two consecutive waypoint connections.
- While becoming more comfortable with Blender I exported the current state of the doberman guy for the ping-pong project and imported him in Mixamo. As with my last try (the goblin), there are mostly problems with the fingers. I should try to give them more space.
- Somehow I think the Gridder project should be my “two-month project”, but then again I just know it would get too big for that. If I have the movement stuff ready before we officially start, maybe it could work out.
- I integrated the basic functionality for lifts in the new Gridder, but it’s very hacky and unstable (at least it feels like it). I am sure I will get back to it when I have re-implemented a player and “real” AI. For now it should suffice, and the next step will be thinking a bit more about ladders.
- A short video on exploration, but with a more philosophical / psychological perspective. It rightfully questions the mechanic of a lot of games where you collect meaningless gizmos around a constructed world. Why does it need that, especially if the world is interesting to explore already?
- An interesting break-down of the character animations of Tangle Tower, and how to import and use them in Unity. Somehow I didn’t expect modern solutions to still use “craploads of still frames”, with all the shader power there is - but of course it looks a lot better that way.
- I’m trying to compile a list of short game ideas that would be doable within two months ideally. Because after the current contract work (CitApp), we want to work on (maybe) Behind Stars, but releasing it will take another year at least. And I’d really like to release something commercially much sooner, so maybe doing smaller projects first is a good idea.
- Yesterday we did another episode of Spielgefährten, this time we played some local coop games, like Out of Space, Overcooked or our very own Spheroneers prototype. It became a bit more personal, which I’d like to avoid next time.
- Not much, but I semi-solved the problem in my recent Gridder iteration with entities falling on other entities. I added a CollisionWithOtherEntity() method, and defines for each case what happens if, for example, a character moves towards another or falls onto another’s head. That method can be extended as needed, and most likely intercepted by the AI and the player classes.
- We did a livestream (in German) for our podcast format Spielgefährten. We played the game “Star Trek: Deep Space Nine: The Fallen” (in German), commented on it and talked about us and games and game development in general for more than 2.5 hours. It was quite fun, even though I still hate hearing my voice.
Setting the whole thing up with OBS was nice and easy.
- I tested 72 a bit more. On our own 10 year old Mac it doesn’t actually freeze, but the physics go bonkers and you can’t leave a room after you enter it. I decided to not bother anymore, as it’s so random what’s happening here and with only one person who showed interest in the Mac version it’s actually wasted time already to just write about it in this log…
- I did some more light stuff for the Gridder; I think the problem “stairs” is not fully solved yet but the outlook is bright, thanks to positions being able to share one waypoint (done via the waypoint objects in the scene). In any case, the random AI walks around relatively sane. Next step will be connections that can be (de)activated, which might lead to usable doors. After that, maybe, lifts, ladders and entities falling onto other entities, “crushing” them.
- Bitbucket warned me that the repository of Behind Stars got too big, so I followed their advice and removed some files. Afterwards the repository became even bigger. I am very sure I made a mistake somewhere, but to get rid of the git-induced headache I just created a new repo on github. This one is now 260mb; the one on bitbucket accumulated over 1.3gb of data. While losing the history is kind of sad/bad, it hopefully doesn’t matter much, as we’re going to overhaul a lot of things completely anyway.
- While I don’t want to see it as a sign or anything, I get the old notebook out much more often now and doodle stuff. I’m still missing some kind of “motive” I want/need to follow, so I get lost in ugly characters nobody cares about instead of doing some meaningful or at least pleasant drawings. Maybe Behind Stars, or the Gridder, or the ping-pong project could be a goal here, but on the other hand I actually should free my head of these projects now and then.
- I uploaded our old GGJ game from 2013, 72, on itch.io, because someone asked for it. I didn’t create any new builds, so of course the Mac build freezes… I really don’t know where to begin to fix this, especially as the log doesn’t say anything.
- Coincidentally, another person tweeted me 2 days later about another 2013 jam game of mine, Soliloquy. I only had a Windows build lying around, so I just uploaded it on Dropbox, but maybe another itch.io upload would be good.
- Now that we’re back thinking about Behind Stars, there are a lot of things I’d like to completely change. From the top of my head, those would be
a) replacing the animation stuff with Animancer
b) replacing the whole ingame UI (ugh) - which means the inventory, the quests, the help system
c) replacing the editor for texts (notes and quests) - the quests could be controlled by a special version of the dialog editor, maybe
d) replacing the torch system maybe
e) finally making cool grass decals
f) replacing the event system with simpler signals
g) replacing the ground fog system with another asset
...and of course much much more.
- I opened the old Behind Stars and Under Hills prototype/game in the latest Unity 2019.3. Apart from a few warnings it went kind of well. I am scared of my old and sometimes hacky code though.
- A few days ago I implemented “dynamic” geometry in the New Gridder. Which means I can remove a block or add one, and it would generate a new set of waypoints around this position only - thus reduces the amount of involved physics shenanigans.
My next goal should be a conjunction of having stairs in the game, and random “AI” roaming through the level because it usually shows how much everything is making sense. One new approach is to not let characters reference waypoints, but only their position - because waypoints can possibly get deleted anytime, or just not exist (e.g. when falling down). Oh, and I need WayPointObjects and WayConnObjects, which inherit MonoBehaviour, so I can add extra data to a level.
- I’m finally doing a bit in Blender again. After I created that Goblin for another project (even rigged and animated it a bit) I felt good about myself, but of course I let it drag until I barely knew any 3D modeling. But now I am doing another character, and while it feels harder than before, I still enjoy it.
- The reset of the Gridder was helpful to rethink my actual intentions, but it led to question everything I’m doing right now in Unity. The current target is to have dynamic waypoints that can be removed and added without problems. Of course there are a lot of raycasts and sphere overlaps involved right now because I do it based on blocks, walls and ceilings/floors. But it feels it’s the right direction, and for now it works.
“Different heights” is a goal I won’t pursue anymore, at least not as I was envisioning it before; but stairs should be possible if I let two waypoints share a world position, basically telling them they’re twins, or even the same waypoints.
- I think I want to “restart” the Gridder project, basically making a new movement prototype. This would be the fifth time then, if you count my failed 7DRL from 2016 and They Look Strange And Have To Die too. I want to get back to the original 2016 movement, as I don’t think I won’t need some of the specific features I added in They Look Strange, like having multiple enemies on one grid tile. Instead, I really want to have climbing, which my current prototype also has but (IMHO) awkwardly implemented. The climbing should need two turns (one going up, one going forward) to give it more impact. One thing I always never knew how to handle is what happens if the player lands on an NPC - currently I can push the NPCs away, but what happens if there is no space? In the current prototype it’s possible to have several characters on one tile and that helps, but it can look strange and not work always (needs a more sophisticated system of finding the next free tile for that). So my new idea is to just give every character - NPC and player alike - an “unconscious” state, where they are immobile and reduced in height, to reduce strange clipping errors (for the player this would lead to a third-person camera, and/or death).
It would also be very okay if the player has more movement possibilities than the NPCs; most games are like that anyway. So while the NPCs could be able to climb, they don’t need to be able to jump across a gap. Especially if they get other abilities in turn, e.g. using far-range weapons (stones, spells) anytime they need to. I can also give them the ability to switch places. All in all I want the game to really feel like a roguelike, but in 3D and (probably) with designed levels.
Now what to do about doors? It would be great if NPCs can use doors, and especially open them on their way to hunt the player. Doors could either take up a whole waypoint/block, or sit between two waypoints, on their connection. I think I will reduce complexity here as well and just give waypoints and connections special flags that mark them as doors, and thus easy to identify for pathfinding algorithms. Platforms that move a character from spot A to B can exist too, but would probably only be usable for the player.
One feature that was in the 3rd prototype actually, but not the latest, and that I’d really like to get back to, is different heights. It interferes a lot with the climbing (and falling) abilities, but it would allow a much more diverse looking environment I think. As the base block size is around 2x2x2m, I would probably define every height difference above 0.5m (i.e. 25%) as climbing, and 0.5 and below would be a direct connection. The whole ordeal can lead to inconsistencies with characters falling from different heights, so this needs to be reevaluated for sure.
- We uploaded the GRITO GRIOT game we made during (and after) our stay in Salvador de Bahia, Brazil. It’s mostly a random rhythm one-button shooter with a very special story about sci-fi brains and robots, and also a music instrument called the berimbau (look it up). Unfortunately the beat detection never really worked as good as I wanted, but it’s interesting to look at in any case.
- Watched this video about stealth game mechanics (it’s the first part, about how guards detect the player). For my taste it mashes stealth puzzle games (e.g. Marvellous Miss Take) too much together with stealth action games (e.g. Thief), but I guess the underlying mechanics for the NPCs are the same or at least similar. It doesn’t go into cover-based vs. “brightness-based” stealth, which is probably okay. I just don’t like cover-based-only stealth, because usually it needs a lot more user interface to make the player aware if they’re seen or not.
- Funny/interesting abstraction of driving physics. And it’s exactly what I would rather do than trying to get real car physics right for months.
- I’d like the ping-pong project to be a bit of an immersive sim; unfortunately I can’t find a certain video I once watched about what makes an immersive sim. IIRC all there is to it is just having things that react to events. Thief would solve this by actually spitting out an event (i.e. a message with an unique ID and some information, I guess) anytime anything happens. Sound designers could grab any event they wanted and add a sound to it, making the experience great for the designers, and the players.
- I actually created a Signals class for the ping-pong that could replace my Events class from my base code. It feels a bit more elegant because it is simpler overall, but only real use will show if that’s actually the case. I also tinkered a bit more with the character controller, and while it still has a lot of flaws, it is done for now. (First problem to note: there will be glitches if the player stands up under a low ceiling.)
- I tried to make the character controller for the ping-pong project force-based. This is because I think directly manipulating the velocity will bite me in the ass when it comes to interaction with physicalized objects like crates. Yesterday I also added running by pressing Shift; nothing fancy. It will probably be better to invert it and make the character slower when pressing the key.
- I added some old code from the StealthGridder version I did in 2018/2019 to the ping-pong project, so we can have a light gem similar to Thief. It’s missing a correct detection of spot lights, but at least I found and fixed a bug from the original version.
- CAPTCHA does accept input by the user now and compares it with the current string displayed in the letter noodle soup in the background.
- I remembered West Bank, a very simplistic game on the C64 about being a bank clerk, receiving money and shooting robbers. When we played it back then my brothers and I would concentrate on one door each (there are three) - we still didn’t score a relevant high score. In any case I thought about transforming it into a VR game. I think it could be an interesting project, because easy and yet extendible.
- For the ping-pong I created a basic character controller for the player. It’s possible to walk and look around. I pretty much recreated the physics-based dynamic character controller that I always use; mostly because I wanted to see if I would “improve” something if I’d try it from scratch. I do believe it’s already somewhat more robust thanks to using Rigidbody.MovePosition() instead of transform.position for setting the character’s “leg height”; but only time will tell if that’s actually useful.
- I did some kind of code clean-up in my Gridder project, because a lot of things I did so far were hacked in. It’s not substantially better I guess, but at least I named things more clearly and also use events now instead of coroutines at some places. Next step I should try if I can add waypoints dynamically without much hassle; those are missing from They Look Strange And Have To Die. It might also be interesting to try if I can make the y coords of the waypoints a fraction of 1; this way, stairs would make more sense.
- I downloaded Mirror today and got the first example working without any problems. The code of this super simple demo is already interesting, so I will definitely try it out. The ultimate goal is a prototype for Spheroneers that can be played via LAN at least, so we won’t have a couch game only.
2020-03-11 / 2020-03-12
- Did work a little bit on CAPTCHA. Working with UGUI and TextMeshPro is actually okay, if one knows which of the obscure methods one has to use to get the size of RectTransform and text bounds.
Spawning hundreds of TextMeshProUGUIs (horrible class name, by the way) produces only 6-7 draw calls, which is nice.
- In order to implement doors for the Gridder I actually extended the WaypointPhases class to not only manipulate waypoints but also connections. The class became a bit cumbersome, because with Unity’s serialization system I can’t use polymorphism just like that, and now I have four arrays for the waypoints and connections to activate and deactivate per phase. What’s missing now is actually sensible animations for the door objects in the world.
- I created a Unity project for the ping-pong project, with the goal to make it a stealth/hacking game. (Don’t ask how that happened.) Stealth is one of my favourite genres, but I also know it is pretty hard to make. Even though we made The Sun Is Deadly aeons ago I don’t think it will be a matter of a few evenings only to create a good enough hide mechanic.
- It was clear before probably, but the 7DRL this year won’t be finished. Debugging it in Unity is just too slow with my current setup, and I am not really convinced of the game’s concept anymore either.
- There are now Interactables in the Gridder, so the next step can be adding doors. (This also means one can enable/disable connections too.) I need a sensible way to logically connect interactables (and their effects, e.g. opening up a pathway) with waypoints, so the AI can use them too in some manner. I am sure this will need a lot of thinking in the future.
- The 7DRL project is going forward much too slowly. Only now I got the movement back that I had in Wood for the Trees, mostly. I guess I should have looked at my old code, but I fear old code sometimes. At least the export to the Oculus Quest is no problem; the actual issue for me is that one needs a beefy PC for impromptu testing of a VR game in the Unity editor, and my laptop is not beefy. So right now I constantly build the game on the Quest, which is a time waster and not very motivating.
- The ping-pong collaboration project is, once again, going to become another type of game. We might want to do a Zach-like for it, with dungeons and mechanical goblins. It sounds fun already, in my opinion.
- I worked a bit more on the 7DRL, not really following the time plan I did. At least I now understand better how creating a game with Unity for the Oculus Quest works. I should get that emulator going, for quicker play testing, because right now the constant switching between headset and laptop is giving me headaches.
- The Gridder has now semi-working lifts, activating and deactivating waypoints. The code is a mess and I should clean it up sooner than later, otherwise it will bite me in the future; especially as I don’t work on the project consistently. Other than that I am happy with the progress; next up will be interactable things - like doors, which also need to be able to activate and deactivate not waypoints but connections between waypoints.
An interesting challenge will be to make AI agents understand that a blocked connection can be unblocked by just opening a door. It might involve even more trickery with waypoints having additional information about their connections.
- I began a Unity project for our 7DRL entry. We plan to make it a VR game, because traditional roguelikes are done a lot already, and we want to experiment. The idea is to create a game that is spatially similar to Wood for the Trees, but randomly generated. Like most action roguelites, each room will have a wave of enemies coming at the player, which they have to shoot. Only then they can proceed to the next room. Each room will probably be pre-designed, consisting of ruins and plants. The enemies are planned to be skeletons. That will most likely be more than enough already for the sparse time we have left while doing contract work and other things on the side.
- After already having done it on my office PC, I now could export an APK directly to our Oculus Quest on my laptop. Quite a feeling, even though we already made Hands Off Thief some years ago.
- For the Gridder I thought a bit about how to create dynamic level elements, like moving platforms, doors, traps and things like that. As I want the system to be conflict-free and mostly predictable when it comes to the creatures moving around, I will have to make it a bit more complicated to use (as a programmer and level designer). Right now I envision waypoints that can be activated and deactivated, and scripts with “phases” which define which waypoint is activated when. Between two phases, all of their waypoints need to be deactivated, to make sure no entity (character) is doing unforeseen movements. So when a lift is moving up, it deactivates the waypoint on the ground and activates the one at the upper target point. All characters on the ground waypoint are moved to the target point - this can be instantly or (in this case preferably) with a tween. It would also be possible to kill all characters that would occupy a waypoint that is deactivating - or just give feedback that the phase can’t be set.
For doors, i.e. walls/obstacles between two waypoints that can open and close, it actually doesn’t have to be this complex. It would only involve a connection that is either passable or not, and an object (the door) that would be connected to it somehow.
- For CAPTCHA I should think of an interesting play progression. At an exhibition I think a game not lasting longer than five minutes would be okay, but it still should have some kind of difficulty curve and a satisfying end each time.
- Fixed a bug with the “AI” in Spheroneers (the enemies continued with their mindless attacks even when a player was still near but not in their view direction anymore). There still is that problem with the enemies not reacting at all though, and I couldn’t replicate it so far. In any case, I think it is now much more ready to showcase it at the Talk&Play in March.
- I finally created a Unity project for CAPTCHA. I thought about doing it in Heaps or something else, but Unity’s text rendering capabilities are pretty much the best I have, and that’s what’s important for this project. I also feel proficient with UGUI nowdays to actually be productive with it.
- Had a dev meet-up via Discord with voxel, and it only worked on Chrome. Both the app and Firefox refused to recognize my microphone. Strange stuff.
- Seems like my problems with VSCode (see 02-25) were happening because I had a git related extension active with the project not being a repository. Success, for now! Enabling all the extensions feels like bloat anyway; although in any case such things should never happen, especially not without any hint of what's going on.
- I created a new version of CHIPCODE specifically for Linux, which replaces the TextMeshPro objects with normal TextMeshes, because only those made problems - and only with this specific font too. I should write a bug report.
- The dash mechanic was kind of easy to implement for Spheroneers; but of course it might be a bit overpowered now. For the prototype it will suffice. All it needs is to add a hint text about it somewhere.
- I noticed that Heaps actually has some basic GUI elements too; not immediate, but that shouldn’t matter. Maybe I’ll try to make the dialog editor (if I will do it at all) with Heaps then.
- I started to add a dash mechanic to Spheroneers, but VSCode acted up again and it lost all Intellisense functionality. A maddening circumstance, and the various solutions to this problem don’t work so far. I even could add the missing .sln file, and still no dice.
- I added CHIPCODE to my website. A Linux user commented they don’t see the text on the chips, but I cannot reproduce that unfortunately, and other Linux users said they don’t have that bug. Oh well. An after jam version would be nice though, with one or two more tasks, more chip types and the possibility to save progress or at least choose levels.
2020-02-22 / 2020-02-23
- I participated in the 8th Alakajam and made CHIPCODE in less than 48 hours. It’s basically a “programming” sandbox strongly inspired by Zachtronics, for example TIS-100. For a real coding game there are probably too many options missing, but a lot of stuff is there. In the end I never studied Computer Science and it shows.
The theme of the jam was “Depth”, and while I was kind of inspired by it, the result doesn’t have much of it anymore, as I had to re-scope and change the functionality at important points.
The hardest part was the “recursion” of the small chips boards, and I am still not sure it is correct now. I might get back to it later. Unity 2019.2. crashed annoyingly often, especially as I never had this problem with former versions of Unity.
- I worked a bit on my Gridder project and actually didn’t do what I planned last time, because it dawned on me it would interfere with my current logic for force pushing characters out of the way. Instead I extended the waypoint generator and now it automatically generates connections for climbing up and down walls. This involved a lot of raycasts, so I’ll see later how robust this is when I (try to) make the connections more dynamic.
- Because of boredom I added “shooting bullets” to the ping-pong C project, and ditched the Snake mechanics for now (because voxel doesn’t like them).
- VSCode’s auto formatting stopped working suddenly. Had to research what was wrong, and I still don’t really understand it. A lot of small annoyances are happening, but not enough to change back to VS Express. Not yet.
- At some point I’d like to try another networking game - Karoshi! It was so long ago, I don’t really know if I could do it again just like that. Also, the inbuilt multiplayer support in Unity is shaky at best and they are constantly trying to make something new and better; so it’s wise to not wait for it. After a first few seconds of research the most viable options are Photon, Mirror and Forge. In any case, for Spheroneers I will definitely have to look into some options in the near future.
- The after-jam version 0.7 of Spheroneers is now live. We basically only added sounds and replaced the music. Of course some bugs were fixed (like a missing animation, or characters falling through certain floor tiles), and it’s much more clear now that walls can be repaired again after you destroyed them. I also added keyboard support (rudimentary), and it’s better handling a single player now, if there is a need for it.
- We showcased Spheroneers at the 18th Leipzig GameDev Meetup with both a 5 minute presentation and letting people play the game, and it was cool. Naturally there weren’t many players (it’s only Leipzig, after all), but a lot of fun was had and some feedback was given. Seems like we need to ramp up the “juice”. A problem is the back-tracking which destroys the flow a bit - more checkpoints would help here. It was a bit chaotic when three people played it (instead of the usual two), but then the fun was also bigger I think. And of course a lot of glitches and bugs became apparent, but nothing serious.
- As someone who is allergic to learn git properly, this might be useful.
- MyPaint looks like a pretty lite alternative to Krita and other paint programs. Might have a look into it, if I ever do some digital drawing again.
- On my laptop I actually use VSCode for everything coding related now - C, C#, Haxe. After having problems with the auto formatting with C#, especially as the FixFormat plugin doesn’t seem to work when it comes to keeping my curly braces on the same line, I found this github issue regarding OmniSharp, which solved the problem.
- I worked a bit on the Spheroneers after-jam version (0.7), mostly adding physical scrap objects as feedback for having walls and floors destroyed and repaired. It looks funny already. Big annoyance today was the totally strange behaviour of the players’ character controllers suddenly. They got stuck on small slopes and wiggled around stupidly. The latter I could solve by replacing rigidbody.Rotate() with transform.Rotate() in the Update() method, but the former was a conundrum. Asking around didn’t gain anything. And now, after restarting Unity, it works again as it should. That is not really good, more like worrisome, but I take it for now.
In other news, we requested Nintendo Switch Access, meaning the project might become quite a bit more serious in the future. Here’s fingers crossed. Although we are still searching for the full game’s core principles and setting. Doing research of similar (and successful) games is also making me a bit depressed.
- As I don’t use my Tumblr anymore, but this simple log instead, I updated my website’s link section. This is the first “official” appearance of the log anywhere.
- I added buffered input to the Raylib ping-pong game, as planned. It was a lot more complex than in any language with dynamic data structures (a simple List for example), but I am sure the real problem is my rather fragmentary knowledge of C. It probably would also have been easier if we’d support only one key per movement action (e.g. A for moving left). Overall I liked it, but I can see that handling this project can become very frustrating as soon as there’s more stuff going on.
- A very old prototype of mine, CAPTCHA, needs to be extended and polished for a typography exhibition. (As I promised it to the people from lalalab.) The old prototype actually uses an ancient version of Unity, but I think it would be an even better fit for the “new” UI of the latest Unity versions.
- For the problem of distributing differently sized characters in my Gridder project I decided (for now) to go with a sub-tile system. So each waypoint would consist of 4x4 sub-tiles that can be deactivated individually. Creatures are sized 1x1, 2x2, 3x3 or 4x4; 2x2 and 3x3 are the most common ones; if they don’t find any free space, they can’t go. The problem becomes like a simple texture packing algorithm; so I will probably try to sort characters on a tile by size, with the biggest ones first. Otherwise it could happen that a 3x3 creature doesn’t fit even though less than 7 1x1 creatures are there too. I don’t know yet if I will have such small creatures anyway.
- Current plan for the Raylib ping-pong project is to add buffered input. Afterwards (maybe) basic Snake functionality (getting longer), and an endless procedural level. Sounds fun to me at least, and it’s what I think I can actually do with C so far.
- Did some work on the jam version of Spheroneers, because we want to showcase it in Leipzig, at the GameDev Meet-up this Thursday. So I added an arrow in the UI that would always display the direction where the sphere currently is; for that I have to find the intersection of each border line of the view with the line between the center of the screen and the screen position of the sphere. Probably not the fastest solution, but the most correct one. I was too lazy/dumb to think of the intersection math, so I got it from the link below. The C# code only returns true/false depending if the lineas actually intersect, but getting the intersection point was easy enough.
Next up: some particle effects, for the feedback and overall polish. So far we mostly received mixed reactions on the game, in the vein of “good idea, but probably not successful”. Hmm.
- VSCode + Unity seems cool so far, although I find the references by code lens somewhat too big. I might disable it just because of that. Also the integration of VSCode is not perfect in Unity 2018.4, and I don’t know if I want to switch all my projects to Unity 2019. On the other hand not having 3 versions of Unity installed might also be nice.
- Out of curiosity, and to (re-)learn C a bit, I compared the speed of getting and setting values in a single dimensional array A versus a two-dimensional array B. The result isn’t really conclusive, because I calculate the index for array A, which I don’t have to for array B, so of course B is faster. I could maybe “optimize” it by just using an index counter for A. More interesting though is the fact that (at least for this online compiler) a two-dimensional array of the size  is too big; it will segfault; while array A with size [1024*1024] works fine.
Making the arrays static (that means, putting them on the heap instead of the stack) works though. Still, I wonder why array A doesn’t have a problem with the size. Is it always allocated on the heap?
- I finally read this hands-on article about the View Cones in Shadow Tactics. I think the most interesting part for me was how they render the cones, and how they iterated on the detection/flee mechanic.
- Felt adventurous today and installed everything needed to use Unity with VSCode instead of VS Express. The next few days will probably feel strange; especially as there wasn’t a real need to switch.
- I downloaded Blender 2.82, but still don’t really have a project that might make sense. At least I know now that Armory3D is compatible with it. I also found out that it’s easy to import 2.81’s settings into 2.82; losing my settings was always a problem I had with the portable versions. No more!
- I should learn and use Unity’s new Universal Render Pipeline, at least for a small project, just to evaluate it. Felix ported some samples, those might be a good start.
- There are many things still missing for the StealthGridder to be even considered as a foundation for an interesting gridding game, but one step at a time. So next I might implement a more dynamic way to distribute characters on one 1x1m tile (aka waypoint). It will probably be based on a rectangle (if I should ever introduce a maximum height for a waypoint, it would become a cuboid), with offset and width and length. The rectangle would also define the maximum capacity of the waypoint. To make it even more interesting, a rotation angle (for slopes/stairs) should also be added, but that might also just be solved via raycasts.
The distribution itself could be solved via Poisson maybe, or I try to think of something simpler. This is for four characters on one waypoint at max, after all.
- The WobbleAnimations in my base code use scaled deltaTime - why didn’t I notice that earlier? I fixed it in CitApp, and need to integrate that.
- Finally copied most of my player input code from the old StealthGridder project to the new prototype, and it mostly works. Gamepad support as early as possible is one of our mantras.
https://ratrogue.itch.io/stealth-gridder (old prototype; not public)
- Unfortunately zui produces a lot of errors/warnings for me when I use it with the JS target. I didn’t find anything about these messages, so I fear there is some misconfiguration on my part, and I am not sure I want to go down that rabbit hole. Meh. I wrote an issue on github at least, although I am sure this is not reproducible.
- Nowadays I can’t live without Dictionary<K,V> and other data structures anymore. Which is why I’d need them in C too, if I really want to pursue this way further with raylib and raygui. The awesome-c list seems like a good start to find libraries for this, and from the clean look and the (hopefully) ease of use, I like LeoVen’s collection of macros best so far. And I heard good things about stb. I used uthash before, but unsurprisingly I already forgot how to use it.
- As I’m still in the research phase for the Unity-free dialog editor project, I’m looking at other libraries that might be a good fit. Especially as I fear that my C knowledge will never be good enough for a complex interface beast like a dialog editor; but for now I know that the rendering problem would be solved with raylib and raygui, and that’s good already. Anyway, apparently there is an Immediate GUI library for Kha worth checking out, called zui.
zui is like GUILayout in Unity, which can make it very easy to use, but also somewhat inflexible. I guess I need to reevaluate what my old dialog editor had and what it actually needs.
- Added the operator overloads to the Variable SOs in my base code, but much less than I thought I would. Mostly because it was not needed (thanks to the implicit cast to the base type, so I don’t need to overload comparisons for example). It also could be dangerous - as the user (me) sometimes wouldn’t know if an operation manipulates the variable or not. So it’s actually more safe to just use the Value property of a variable object.
- To go further with my Unity-free dialog editor I created a VSCode project with raylib and raygui. After a lot of fiddling the “Hello World” kind of works. My biggest gripe right now is that I need to specify the absolute path to raygui.h as include, because otherwise the compiler can’t find it. Which is strange, as I actually defined the path to raygui in the c_cpp_properties.json file from VSCode. I hope I can get an answer to that. Creating C projects correctly is hard.
Okay, seems I just forgot that the actual build process is defined in the Makefile; task.json gets ignored mostly (maybe one could change that), and c_cpp_properties.json is only meant for Intellisense anyway. Had to hardcode raygui’s source path into the Makefile. I am sure there’s a better way.
- We prioritized the tasks, or rather wishlist, for the extended version of Spheroneers by hanging cards on the wall with points like “Get a Switch dev account”, “Graphics style experiments”, or “Ramps”. Hopefully we can show a somewhat improved version at a Talk&Play (Berlin), a GameDev Meetup (Leipzig) or at the A MAZE (Berlin); but if not it wouldn’t be that bad. We still have contract work to do after all.
- I followed this tutorial to create a website with Eleventy (@11ty) - a static site generator. Seems a bit outdated, the index.html generated in the end didn’t quite match the one in the article.
Overall I am not sure if Eleventy, as nice as it is, is suited for my needs. (A simple website for this dev log.) Especially as every entry would need to be in its own file. On the other side I might just use static sites for that (like an About, etc.), and ignore blog entries, or use them for something else (pictures?).
Here’s another static site generator, called Nice, written in and with Haxe:
But maybe I actually should use something totally different; or something I write myself. (But with what?) So for now I keep using Google Docs; I dislike having to rely on an external document system, but at least with Chrome I can have them offline too.
- I never really knew how to create an (empty) file in the DOS prompt / terminal. (Or I forgot.) Now I know:
> copy NUL out.txt
Apparently there are several other solutions for this..
2020-02-08 / 2020-02-09
- I should add operator overloads to the Variable ScriptableObjects for my Unity base code.
- I want this dev log to be online and public some day, I might have to look into a simple static blog generator. Or something else?
- My StealthGridder project needs mouse look, as a small next step. Right now it’s a bit of an extended movement prototype in comparison to They Look Strange, but it’s also lacking a lot, for example the dynamic levels.
- I want to try pure Kha soon again; it’s now usable with VSCode, and I have Kha installed and can use it from the path directly. The “art project” might be a good fit as a project - simple, grid-based, multiplayer. Of course, another big step would be the arcade cabinet (?) itself.
- I should check out raygui to see if it would be usable for a dialog editor.
- The raylib project workflow would probably benefit from using VSCode, because right now I’d have to edit the Notepad++’s build script if there are more .c files.
- It would be interesting to try out VSCode for Unity. I probably still need Visual Studio to be installed though, as some libraries (e.g. Kha) need the compiler for Windows builds.
- Idea: I could and should do some small visual scenes, probably in Unity, by reusing art I have from Jana and myself, from jams, prototypes and games. And put those to small scenes, with interesting lighting even.
- Spheroneers was a big achievement for us, and we want to extend it. The question is: how to progress from this point? I think a single player mode (that is fun) is needed. But also an interesting style, and more people testing if it actually could be successful.
- I added a new tool, Voxelator, to my list of free online game dev tools.
- I checked out HaxeUI, because I want to make my dialog editor (originally for Behind Stars) more independent some day. Seems like HaxeUI isn’t exactly a good fit, because there is no inbuilt line drawing functionality and so on. There are plans for cross platform canvas access, but they are just plans. The HTML5 target creates an actual DOM tree, which would make it hard for me to make easily draggable components. Instead I will probably try raygui soon.
- For a ping-pong project I re-tried raylib. Version 2.6 is the current release, but it doesn’t have an installer, so I used 2.5 again. Which was a mistake, because some things really changed; for example, Camera2D.target is now what Camera2D.offset was. In the end I removed all the relevant files from the install version on my laptop and replaced them with the 2.6 version from github. Then I built 2.6 by using F6 in the special Notepad++ make command. It was easier than I thought.
- I tried Armory3D this weekend a bit more seriously, by “porting” the box-based game jam game I usually do for university courses. Armory3D actually is kind of nice, and does not have a lot of friction. Both the visual coding and the Haxe “Traits” are interesting. You also don’t have to download a special version of Blender anymore; just use the one you have. The tutorials on the git wiki helped me get started.
It’s seriously lacking a 3D text mesh. I wanted to let the camera follow my player, and there wasn’t any LookAt() functionality. There is also no Slerp() for quaternions. Overall it’s not suitable for me.
- I tested UMotion, an animation plugin for Unity. It feels very powerful, and yet somewhat easy to use. If there should be any need for this in the near future, I would be happy about it.