Hi! As hard as it is to believe and weirdly unceremoniously it finally happened:
The two agents are now finally generated by configuration, rather than by code:
Using it is pretty straightforward, a new “controllable_info” property was added to the existing object configuration which allows the user to configure all of these specific properties. All of these, except the name, are optional and will default to sensible values if left unconfigured.
That means the only task left about this is how to handle the object-in-object mechanics. I am still arguing with myself whether or not to postpone that until I actually implement the save function, as that feature realistically is not a must-have for defining game scenarios/maps and rather do something else instead. But let’s see, time will tell. Byeeee. 🙂
Hello! This commit brings rudimentary support for adding objects through the scenario definitions. While we’re not quite there yet to have Foobert and Bart being added this way, it definitely does support all “regular” objects, including light sources and temperature modifying objects.
I also took the opportunity to extend the house1 scenario a bit to include more of an actual, well, house.
Check out the great insulation, this house has great value
As you can see in the screenshot above, the radiators work as they normally do, keeping everything cosy even during cold nights. How cold those nights get is a simple scenario setting now. 🙂
Hopefully I’ll be back soon with more work on the object insertion. After that the next stop will probably making all of this accessible through the menus, giving everything more of an actual “game” feeling, something I’m really looking forward to. Byeeee. 🙂
Hi! Here we are again with another missing piece to the scenario definition, wall definitions!
Look Ma, no manual building!
While putting together this demo scenario (house1.json) I also realised that it’s probably a lot better to have a more compact format for defining the tiles, as can be seen on the screenshot.
While manually putting together that test data I also noticed that I really cannot wait for the ability to actually save this, as manually putting the data together was not that much fun. Be that as it may, it’s another step in the right direction 🙂 Next up will in all likelihood be adding object support. Hopefully soon. Byeee!
Hello! Another small step towards the greater scenario system milestone, now the files support setting tile type data, tile types!
The syntax is pretty self-explanatory, it is enough to simply look up the name of the desired tile type in its asset definition file. 🙂 In order to keep this as small as possible, only “custom” tile types need to be explicitely defined, all other tiles will simply be considered empty/grass tiles.
Next up will, in all likelihood, be the definitely more challenging walls. With some luck that shouldn’t take too long either though. Byeee 🙂
Hi! This commit builds on the basic skeleton last time around, now it is possible to see quite a big difference: besides the overall world dimensions more specific properties like the height map are now being dynamically loaded. As a positive side effect I could also get rid of quite a bit of settings that were hardcoded for quite some time. 🙂
To showcase these rather substantial differences, I added a second scenario sporting pretty absurd settings, aptly named crazy.json.
Here you can see crazy.json in action, being configured with alternating dark/light cycles, colours and temperatures every 30 in-game minutes. But don’t worry, the vanilla OLives settings are (and for the foreseeable future will be) available in the default.json scenario, which is also what gets launched if you click on “New Game” in the main menu.
I actually tried to get OBS to cooperate to finally get a clearer picture when recording these, but even after trying to set absurdly high bit-rates (as well as other encoder options) I didn’t really see a discernible difference, so this is it for now, I’ll try again at some point though. 🙂
Anyway, next up will probably be tile types, since those will probably give me a better idea of how to eventually handle the the more complicated walls and all things wall related (looking at you, doors and windows). Byeee!
Hello! This commit is providing the basics for the new scenario system. One of the reasons (or rather the reason) that makes me excited is that after years of development it is finally possible to configure the size of the world in OLives, which up until two days ago was hardcoded. 🙂
The –scenario parameter is now actually used for its intended purpose, specifying which scenario file to load, not just simply whether or not to jump right into the game or stay in the menu. The game will now happily crash if a bad (non-existent) scenario is being passed, of which right now exists exactly one, aptly called default.
The format of the scenario files looks something like this right now:
The format is definitely not complete yet, and only the funds and world_dimension are currently honoured. As is suggested by the existence of is_save, this format (or a very similar one) will be used for save games, when the time finally comes to actually implement saving the current state.
To summarise the current state of things, here is what already works:
Loading and very basic parsing of the JSON scenario files
Specify which scenario works from the CLI
Initialising some game state properties based on it
Loading the scenario (“default”) from the menu
What does not work yet however is:
Honouring the other existing (world) properties
Adding and honouring other important settings (objects/wall state/tile state)
Listing existing scenarios and letting the user select one
It is important to underline how much work is still to be done to finish the feature in its entirety. However, much of the work is in all likelihood pretty straight-forward and there will be gradual, but very tangible progress along the way, to which I’m really looking forward to. There has been a piece of code which has been moved around to (including the comment at the top) for about two years now, it looks like this:
I’m very excited that the prospect of getting rid of it for good has changed from “sometime in the future” to “sometime in the next few weeks”. Byeee. 🙂
Make it less likely to have objects in an invalid rotation state right after entering another object for a frame
Hi! This commit does exactly that: there sometimes is a slight disconnect between the rotation state of an object and its current animation status.
Flow of the an object (circle) entering another one (square)
When one object (i.e. the dark grey circle) enters another one (light grey square) it will first position itself on a designated entry point, which in turn is connected to a so called “slot” on the object to be entered. In the example above this has already happened, the circle is on the entry point and facing the coordinates of the slot associated with it and changes its ContainedStatusChange from None to Entering. When this is happening, it will also start playing the appropriate animation for the chosen slot type (e.g. “sitting down” for animation type and “front” for position). While the object visually changes its position, it logically stays in place at its current position, the same is true for its rotation, this is what is seen in step two. The critical part here is what is happening between step three and four, the number of (logical) ticks that are required to enter the object have passed and the object needs to complete the transition. During this process it will change its ContainedStatusChange from Entering to None, as well as set its new coordinate, rotation and animation. The problem which can lead to a flickering model here is that the render thread may not be taking the new model rotation (and position) into consideration very briefly, as the logical object (!= model) information may not be synchronised yet, the new animation has already taken effect though.
In short, this commit makes this scenario less likely, does not fully alleviate the problem though. I’m not thrilled by that, but it’s also important to keep the bigger picture (tangible progress) in mind and not getting lost in too many minor details, particularly after wrangling for an extended period of time with a polishing change like improving animation performance. This does not mean these changes are unimportant in any way, but it is important to carefully consider when the right time is to invest work into a certain topic to get the best, well, bang for the buck. 🙂
Next up will in all likelihood be something in preparation to the scenario/map mechanic, I have also some of other (bigger) topics, those will still need to get turned into GitLab milestones and tickets. One step at a time. Byeee 🙂
Hello! It has been a long while, as work on the rendering process somehow always managed to get dragged out. I’m pretty happy with the results of this one however. Due to a quirk of the implementation, the animation updates used to be tied to the actual logic ticks, not the render ticks as they should be. This situation has been remedied now and the animations look a lot smoother, particular non-looping ones, like sitting down and getting back up. 🙂
I would like to a show a nice video of this, but given my definitely lacklustre recording setup I don’t think the difference would be quite as noticeable as it is in “real life”. Anyway, next up I’ll either pick up another render problem or go back into the bigger topic of loadable scenarios/maps and in the end also saving/loading mechanics, but let’s see. Byeee 🙂
