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 🙂
– Finish preliminary main menu – Add splash image for the main menu – User proper aspect ratio for widget background picture (and make it possible to manually define one) – Add support for horizontally positioning text in widgets – Take a widgts zIndex value into consideration when determining what widgets has been clicked – Properly initialise widget dimensions (and positioning) when starting up in full-screen mode
Hello! It has been quite a while since the last commit, this has been largely due to some good old fashioned scope creep. The initial thought was to simply creating and adding a background picture for the main menu. That unfortunately quickly spiralled out of control, due to newly discovered bugs as well as some missing features.
Look ma, no hotkeys!
Today I won’t get into too many details, as the somewhat verbose commit message mostly speaks for itself. It should be noted though that finding bugs in the UI code is never that much fun, rivalled only by the renderer itself. That aside, it almost looks like a real menu now. 🙂
I still haven’t fully decided yet which topic to tackle next, improving some things in the renderer or finally getting started on preliminary scenario definitions are both high on the list, but let’s see. Byeee!
– Add new button to activate the in-game menu without a hotkey – Slightly change the sizing of the UI elements on the bottom left to make it more aligned – Fix bug that when selecting an agent and changing to shop mode it briefly shows a rubbish icon instead of the menu
Hi! A lot less happening in this commit, as it was mainly me adding a new button to bring up the in-game menu without having to use a hotkey. While I like the new icon quite a bit, I’m not the biggest fan of its placement, I haven’t had a better idea as of now though in terms of placement. As a bit of a silver lining in that case though it tends to look nice at higher resolutions.
While working on this I noticed some possible improvements with the default size settings of some of the UI widgets, which I’ve slightly changed to get things to align a bit better, it’s a minor detail, but I’m quite fond of that small change.
Aaanyways, not much else to report except stumbling upon and fixing a minor bug, next up is finally giving the main menu some attention, after that it’s time for.. I honestly don’t know which topic exactly. Let’s see! Byeee! 🙂
– Add new in-game menu with preliminary information – Add support for semi-transparent background colours in widgets – Enable(toggle) menu by triggering a cancel() call or by pressing F10/M – Introduce concept of global widget types in the InterfaceManager
Hello! The menu mania continues, this commit adds a brand new in-game menu to OLives. The greyed out parts do nothing yet, but what it allows you to do is to go back to the main menu without having to use an enigmatic hotkey.
The irony of that is that the only way to open the in-game menu right now is also a hotkey. However, at least this time they are hotkeys which are here to stay. Simply hitting Escape (if in simulation or shop mode) or F10/M (all three game modes) will bring up the menu. Either hit that key again or click on the aptly named “Continue” to continue.
“2/5 – would menu again.”
Adding this brought up some unexpected showstoppers, such as a lack of transparent background colours of widgets and a slightly buggy padding calculation. Also, the commit was unfortunately delayed by some rather unpleasant debugging. That eventually boiled down to a non-initialised variable which triggered a lot of seemingly random behaviour. Good times were had. In the end though, the only thing is missing is a small button to actually activate the menu without any hotkey required. After that it’s back to the actual main menu, which now looks a lot worse than the in-game one now, something that needs to be remedied. Anyway, looking forward to get all of that done. Byeee 🙂
