Friedrich Hanisch's Dev Log
SEEN
- 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.
https://www.youtube.com/watch?v=evvqlj2Kk6Q
SEEN
- 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).
https://www.youtube.com/watch?v=p8u_k2LIZyo
DONE
- 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.
https://twitter.com/RatKingsLair/status/1340779890438758401
SEEN
- 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.
https://flaxengine.com/blog/
DONE
- 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.
DONE
- 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.
SEEN
- I re-read this old article from 2009 about graphics in 1999, BSP and John Carmack's strange way of naming things. Level design must have been fun, back in 1999.
http://www.shamusyoung.com/twentysidedtale/?p=4759
- The Tuxedolabs Blog is pretty interesting. The game, Teardown, is pretty and somewhat innovative, and it's nice to read about the techniques behind it.
https://blog.tuxedolabs.com/
DONE
- 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.
PLAN
DONE
- 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 ask questions. The next course will probably be about shaders.
DONE
- 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().
https://docs.unity3d.com/ScriptReference/AssetPostprocessor.OnPostprocessAllAssets.html
PLAN
- 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.
http://7dayfps.com/
https://mirror-networking.com/
DONE
- Working on a texture processor script for/in Unity currently, and the usual complaint still holds true: serialization of objects is a big hassle.
PLAN
- 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.
DONE
- 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.
https://twitter.com/ratrogue/status/1330165499632754694
PLAN
- 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.
DONE
- 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.
SEEN
DONE
- 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.
SEEN
- 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).
DONE
- 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.
https://twitter.com/RatKingsLair/status/1328269899437907968
PLAN
- 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.
https://www.handmade-seattle.com/
DONE
- 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.
https://realtimecsg.com/
- 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.
PLAN
- "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.
https://ourmachinery.com/beta.html
- 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.
https://game-jam.bpb.de/doku.php
- 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.
https://clashofrealities.com/2020/
SEEN
DONE
- 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.
PLAN
- 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.
PLAN
- 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.
DONE
- 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 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...
PLAN
- 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.
SEEN
DONE
- 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.
PLAN
- 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.
SEEN
- 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.
https://microstudio.dev/
DONE
- 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 never 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.
https://halleofgames.de/
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.
DONE
- 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.
https://ratrogue.itch.io/it-rains
SEEN
DONE
- 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 of putting it on itch.io for two or three dollars, just to have it "out there".
- For Tree Defense I dug 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.
https://github.com/HeapsIO/heaps/issues/896
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 few days.
DONE
- 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".
DONE
- 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.
https://heaps.io/samples/input.html
If I were to do this again I would probably use Raylib. Raylib can even run natively on Raspberries, 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.
https://www.raylib.com/
DONE
- 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).
DONE
- 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.
https://www.tinkercad.com
DONE
- 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.
DONE
- 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.
DONE
- 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.
https://assetstore.unity.com/packages/3d/vegetation/trees/low-poly-tree-pack-57866
- 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.
PLAN
- 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.
https://www.burg-halle.de/design/multimediavr-design/multimediavr-design/lehrangebote/l/play-your-self/
SEEN
- 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.
https://www.storycubes.com/
- 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.
https://halisavakis.com/my-take-on-shaders-stylized-water-shader/
DONE
- 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.
https://itch.io/jam/climate-change-trial-and-error
- We worked on Behind Stars' story a bit, especially by re-telling it. It feels like 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.
https://miro.com/
- 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.
https://twitter.com/RatKingsLair/status/1308717663984799745
https://twitter.com/RatKingsLair/status/1310556209594929153
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.
DONE
- 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.
DONE
- 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 moves into the ground... Also the enemy reacts more "rationally" now when they get 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.
https://twitter.com/RatKingsLair/status/1308489050769305600
- 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.
SEEN
DONE
- 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.
DONE
- While I 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 two months anyway.
SEEN
DONE
- 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.
DONE
- 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.
DONE
- 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.
SEEN
DONE
- 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).
https://twitter.com/RatKingsLair/status/1303774533640388608.
DONE
- 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).
PLAN
- 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.
SEEN
DONE
- 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.
SEEN
DONE
- 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.
SEEN
- I have the API help for
EditorTool still in my bookmarks because I will definitely use it 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.
https://docs.unity3d.com/2019.3/Documentation/ScriptReference/EditorTools.EditorTool.html
- Insight of the day:
raycastHit.transform is not necessarily the same as raycastHit.collider.transform.
DONE
- 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 always 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.
DONE
- 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.
SEEN
DONE
- 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.
DONE
- 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 wanted. Finding out why it didn't work out of the box and fixing it took quite some time though.
https://forum.unity.com/threads/trajectory-calculations.98598/
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 Look Animator moves the object further after I moved it with my script. Oh well, maybe I'll look into that too.
https://assetstore.unity.com/packages/tools/animation/look-animator-122249
DONE
- Made a video of the far range combat behaviour in Demon Thief, and the flee behaviour.
https://ratrogue.tumblr.com/post/627968199816773632
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.
SEEN
DONE
- 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.
DONE
- 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.)
SEEN
DONE
- 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.
SEEN
DONE
- 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.
SEEN
- 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.
DONE
- 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.
DONE
- 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 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.
DONE
- 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.
DONE
- 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...
PLAN
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 has 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).
SEEN
- 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.
https://assetstore.unity.com/packages/tools/ai/super-pathfinding-system-168018
Update: Looks a bit too simple for my needs. The example video/screenshots also show some errors in the path...
DONE
- 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.
DONE
- 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.
DONE
- 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.
SEEN
DONE
- 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.
SEEN
- 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".
SEEN
DONE
- 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.
SEEN
- 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.
https://www.albertford.com/shadowcasting/
- 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!
https://ciechanow.ski/lights-and-shadows/
- 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.
https://github.com/Zylann/godot_voxel
DONE
- 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.)
SEEN
- 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.
https://jacksondunstan.com/articles/5587
- 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.
https://assetstore.unity.com/packages/tools/visual-scripting/bolt-163802?aid=1011l4rAy
- 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 is actually a Valve employee. It's cool that they use Blender too.
https://twitter.com/Leukbaars/status/1279288819708125185
- 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.
https://blogs.unity3d.com/2020/07/23/unity-2020-1-is-now-available
DONE
- 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.
DONE
- 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.
SEEN
DONE
- 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.
DONE
- 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.
PLAN
- 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.
DONE
- 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.
PLAN
- 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.
DONE
- I added the (player) character controller I wrote for Behind Stars and Under Hills to the bloed project. It was actually kind of manageable, 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 having 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.
SEEN
DONE
- 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 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.
DONE
- 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.
DONE
- 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.
DONE
- 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.
https://ratking.itch.io/de-moleculis-motus-in-vacuo
DONE
- 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.
https://twitter.com/RatKingsLair/status/1274426956461858819
DONE
- 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.
https://ratrogue.tumblr.com/post/621370074116325376/
SEEN
DONE
- 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) now have 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.
DONE
- 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.
DONE
- 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, or 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.
DONE
- 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.
https://www.youtube.com/watch?v=NBNMU30kqVQ
- 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.
SEEN
DONE
- 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.
SEEN
DONE
- 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.
https://imgur.com/gallery/i364LBr
SEEN
- 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.
https://www.youtube.com/watch?v=h4kdqwdbZZ8
DONE
- 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 serialisation 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.
DONE
- 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.
https://youtu.be/CGEyjVPPEzo
SEEN
- 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.
https://www.youtube.com/watch?v=E8Lhqri8tZk
- 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.
https://www.youtube.com/watch?v=8JGC32PKc1U
SEEN
DONE
- 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 wants. The question is if that is actually necessary?
PLAN
- 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".
DONE
- I added a rudimentary 3D cursor to the block editor for Unity. It works differently 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 for 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.
DONE
- I started to "texture" (more like colourize) 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 like 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 a single colour, 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 now has 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 utilise 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 depends quite a bit on how the camera system worked in Morited (Behind Stars' level editor).
DONE
- 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 to 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.
https://ratrogue.tumblr.com/post/618793805971357696/after-some-hours-of-work-i-could-rework-the-block
- 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.
SEEN
DONE
- Worked a lot on the block level editor inside Unity - I was mostly trying to make sense of what gets serialised 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.
PLAN
- 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.
https://twitch.tv/RatKingsLair
DONE
- 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.
https://docs.blender.org/manual/en/2.81/addons/rigging/rigify.html
- 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...
DONE
- 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 serialised 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.
PLAN
- 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.
SEEN
SEEN
DONE
- The Gridder now has 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.
PLAN
- 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.
DONE
- 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.
PLAN
- 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.
SEEN
- 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?
https://www.youtube.com/watch?v=TGxQzbCuh2M
- 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.
https://twitter.com/SFBTom/status/1254870214287769602
DONE
- 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.
https://www.youtube.com/watch?v=ck5ZCIG_aAU
SEEN
DONE
- 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.
DONE
- 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.
https://www.youtube.com/watch?v=gU8AccKw-LI
https://www.twitch.tv/ratkingslair
- 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...
https://ratking.itch.io/72
DONE
- 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.
DONE
- 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.
https://ratking.itch.io/72
- 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.
http://fholio.de/soliloquy/
PLAN
- 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.
DONE
- 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 reducing 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.
DONE
- 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 modelling. 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 me 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.
PLAN
- 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 will 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.
DONE
- 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.
https://ratking.itch.io/grito-griot
PLAN
- 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.
https://thehistoryofhowweplay.wordpress.com/2018/11/30/thief-the-dark-project-20th-anniversary-oral-history/
SEEN
- 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.
https://youtu.be/Ay-5g36oFfc
- 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.
https://twitter.com/Nitroneers/status/1238779466832363520
DONE
- 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.)
DONE
- 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.
DONE
- 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.
PLAN
- 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.
https://www.youtube.com/watch?v=is5KnA-EcTs
DONE
- 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.
https://mirror-networking.com/docs/
DONE
- 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.
DONE
- 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.
PLAN
- 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.
DONE
- 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.
https://forums.oculusvr.com/developer/discussion/82363/oculus-link-unity-set-up-guide
PLAN
- 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.
DONE
- 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.
https://developer.oculus.com/documentation/unity/book-unity-gsg/
- The Gridder now has 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.
PLAN
- 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.
https://itch.io/jam/7drl-challenge-2020
DONE
- 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.
PLAN
- 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.
PLAN
- 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.
SEEN
DONE
- 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.
DONE
- 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.
https://alakajam.com/8th-alakajam/856/chipcode/
- 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.
PLAN
- 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.
https://heaps.io/samples/
DONE
- 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.
DONE
- 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.
http://fholio.de/chipcode/
DONE
- 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.
https://alakajam.com/8th-alakajam/games
https://alakajam.com/8th-alakajam/856/chipcode/
https://store.steampowered.com/app/370360/TIS100/
DONE
- 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.
PLAN
- 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.
http://fholio.de/karoshi/
https://mirror-networking.com/
https://github.com/BeardedManStudios/ForgeNetworkingRemastered
SEEN
DONE
- 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.
https://ratking.itch.io/spheroneers
- We showcased Spheroneers at the 18th GameDev Leipzig 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.
SEEN
- As someone who is allergic to learn git properly, this might be useful.
https://gitexplorer.com/
- 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.
http://mypaint.org/
DONE
- 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.
https://github.com/OmniSharp/omnisharp-vscode/issues/1506#issuecomment-303390666
DONE
- 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 will 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 on 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.
https://ratrogue.tumblr.com/
http://fholio.de/about/
DONE
- 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.
https://github.com/pixelsyntax/coolfriends-pingpong/commit/ee4e83e82a3c41c2a8e7335c8cd1f0f401dc57e8
PLAN
- 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.
http://www.lala-lab.de
https://youtu.be/ba2dlK9zBHA
- 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.
DONE
- 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 centre 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 intersection maths, so I got it from the link below. The C# code only returns
true/false depending if the lines actually intersect, but getting the intersection point was easy enough.
https://www.spieleprogrammierer.de/wiki/2D-Kollisionserkennung
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.
DONE
- 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 "optimise" 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
[1024][1024] is too big; it will segfault; while array A with size [1024*1024] works fine.
https://onlinegdb.com/BJuS54H7U
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?
https://stackoverflow.com/questions/851122/large-2d-array-gives-segmentation-fault/851135
SEEN
- 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.
https://www.gamasutra.com/view/news/290733/
DONE
- 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.
https://code.visualstudio.com/docs/other/unity
- I downloadedBlender 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!
https://www.blender.org/download/
SEEN
DONE
- I use this Google Doc for my log because it provides the least friction possible, and I can actually publish it to make it visible for everyone. Problem is that a published Google Doc is very ugly, the text goes from the left to the right screen border, which works great on a phone, but not so well on a PC browser. This is why I embed the published Doc in an iframe. Unfortunately this results in all links opening inside the iframe. My research suggests that this is not that easy (and crossplatform reliably) to circumvent. Best would be the
<base> tag, but it'd need to be inside the embedded html, not the html that does the embedding. In the end I found some JavaScript that helps though.
http://fholio.de/log/
https://stackoverflow.com/questions/4377324
PLAN
- 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.
https://twitter.com/____herbst/status/1227406553348747264
- 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.
DONE
- 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.
https://github.com/armory3d/zui/issues/115
DONE
- 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.
https://notabug.org/koz.ross/awesome-c#data-structures
https://github.com/LeoVen/C-Macro-Collections
https://github.com/nothings/stb
http://troydhanson.github.io/uthash/
- 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.
https://github.com/armory3d/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 ScriptableObjects 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.
https://github.com/ratkingsminion/game-jam-base-code
DONE
- 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.
https://github.com/raysan5/raygui/releases
https://github.com/raysan5/raylib/wiki/Using-raylib-in-VSCode
https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
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.
https://ratking.itch.io/spheroneers
- 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.
https://www.filamentgroup.com/lab/build-a-blog/
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:
https://github.com/gmisail/Nice
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.
http://stackoverflow.com/questions/1702762/how-to-create-an-empty-file-at-the-command-line-in-windows
PLAN
- I should add operator overloads to the
Variable ScriptableObjects for my Unity base code.
https://github.com/ratkingsminion/game-jam-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?
https://haxe.org/manual/target-php-getting-started.html
https://www.11ty.dev/docs/tutorials/
- 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.
https://ratking.itch.io/they-look-strange
- 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.
https://github.com/raysan5/raylib/wiki/Using-raylib-in-VSCode
- 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.
https://twitter.com/RatKingsLair/status/1226047630184243200
- 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.
https://ratking.itch.io/spheroneers
- I added a new tool, Voxelator, to my list of free online game dev tools.
https://onlinegamedev.tumblr.com/
DONE
- 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.
https://github.com/haxeui/haxeui-core
https://github.com/raysan5/raygui
- 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.
https://github.com/raysan5/raylib/releases
https://www.raylib.com/cheatsheet/cheatsheet.html
- 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.
https://github.com/armory3d/armory/wiki/playground
https://twitter.com/RatKingsLair/status/1226268252336201728
- 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.
https://assetstore.unity.com/packages/tools/animation/umotion-pro-animation-editor-95991
