-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
One of the funny things about Hy is that it's a Lisp for Python, and so one of its primary selling points is that it provides a macro system for Python, but Python is so dynamic that things that would require macros in many other languages can be done entirely at run-time. For example, I define all my monster, scenery, and item types with (defitem …), which could look like a macro call to the casual reader, but is actually just a function call with keyword arguments. One way Hy makes this kind of call more convenient than Python does is that it allows multi-statement anonymous functions, so you don't have to predefine all your callbacks. Here, for example, you can see the method definition for hook-player-walked-into for exits embedded right in the call to deftile.
I am now pretty much exclusively debugging and testing my game with Tauri. I really love how smooth the performance is, and also how the game automatically refreshes in seconds every time I make changes to my code for me to test it right away. It's so elegant that it has gotten me to start reading the first few chapters of the Rust book. Ironically, I had bounced off Rust when first trying to choose what language to make my game in (thebracket's [tutorial]() is amazing but very complex for an absolute beginner). I think I would actually stand a chance now that I have honed my skills - but I don't want to risk getting sucked into a new project, so my interest will remain superficial for now.
I have a function [pos+](https://github.com/hylang/simalq/blob/e8ade1506f70a61ed83662e6fb02c6acd8ad3ba9/simalq/geometry.hy#L104) that adds a Direction to a Position, for things like seeing what square is directly east of another square. It used to raise an exception when the result was off the map border. It now swallows that exception itself and returns None, because I noticed I had to catch the exception pretty much every time I used the function, and it's neater to check that it's None than catch an exception. In general I'm an exception enjoyer, and I shudder at how e.g. Go makes you follow practically every function call with if err != nil { … }, but it comes to show that errors that happen a lot and need explicit handling every time are more easily treated as just another value.
This month I wanted to work on a new Python tutorial, but I'm having trouble getting parts of my test engine to work cleanly (right now involving interactions with how actions poll their inputs from the UI). I might have to settle for making another "bad" tutorial and then fix architectural issues later.
After build2 devs added a missing feature that was preventing me from correctly running the python scripts from godot-cpp that generates the C++ bindings (the build2 devs were actually hitting similar issues and I was lucky to reach it while they were working on a solution), I managed to complete a working version of the build2 package of godot-cpp. As a reminder, godot-cpp is the library you need to use that provides the C++ api for GDExtensions which are non-GDScript plugins for Godot. Current prototype (number2) is about checking that working with the model of the game in C++ using build2 as buildsystem and package manager but having the "view" of the game implemented using Godot is viable, work-process-wise. (see [this for more details]())
After build2 devs added a missing feature that was preventing me from correctly running the python scripts from godot-cpp that generates the C++ bindings (the build2 devs were actually hitting similar issues and I was lucky to reach it while they were working on a solution), I managed to complete a working version of the build2 package of godot-cpp. As a reminder, godot-cpp is the library you need to use that provides the C++ api for GDExtensions which are non-GDScript plugins for Godot. Current prototype (number2) is about checking that working with the model of the game in C++ using build2 as buildsystem and package manager but having the "view" of the game implemented using Godot is viable, work-process-wise. (see [this for more details]())
I found an issue thread about this which have some recent comments, but I suspect most of the people in there never implemented a hot-reloading system (this kind of thing exists since like 20 years but are rarely generalized as libraries). I have some experience in implementing hot-reloading systems, but no experience with tweaking Godot and I dont think I have enough free time to help them with that, unfortunately. The good thing is that a lot of people are interested in the subject because they say GDNative (the previous system) and GDExtension is simply unusable for projects that use C++ for most scripts. So there will probably be some solution implemented soon. You see the issue is that you need to reload the whole engine/project to get the modified GDEXtension library loaded. Also on Windows there might be file locking issues even preventing you from doing the install of it properly. Reloading a whole project in Godot is far faster than Unity, but the bigger the project the longer it takes. So it can be a massive pain if you tweak something in C++ and then have to wait several tens of seconds to see if it does what you want. In particular because you have to build using a C++ buildsystem, then move the binary in teh right place then reload the project in Godot then run the game then reach what you need to see.