Hi! In the previous commit I talked about how OLives finally got a menu after nearly four years, so it’s only right that this commit makes it possible to skip it again. For actually developing OLives it is important to keep the way from making a change to actually seeing it in action as short as possible, clicking your way through a menu is not helping too much in those situations. While I was working on that, I also added some more command line switches, check out those striking visuals:
The observant reader may notice that “files” are being mentioned in the help text, but rest assured, this has no function yet.
Now that this is out of the way, I will either pretty up the main menu a bit or do some other menu related tasks. Let’s see, byeee 🙂
Hello! This commit finally brings some visual changes:
After nearly four years OLives finally gets a menu. Or at least something that could be described as such if you were to squint very hard.
Clicking “Start Game” does exactly what it says, so does “Quit Game”. This is made possible by the work of the last few commits, so hacking together a few lines of UI code was more like the icing of the cake.
Luckily, in the next few days the menu will be fleshed out a bit, so that it is at least somewhat presentable, but I’ll make sure to post a screenshot then, it can only go uphill from here. 😉 Byeee!
Hello! The work goes on, it is now possible to switch back and forth between the “menu” (i.e. the void) and the simulation mode without having to fear break anything or cause Vulkan handle leaking. Good times all around.
Next up will be disabling certain types of input that only cause problems in menu mode. Then, I’ll finally get to actually show some sort of preliminary menu screen 🙂 Byeee!
Hi! The work on making everything, well, resettable continues. At this point it is actually possible to “use” OLives again – to its usual extent. By pressing ‘O’ it is possible to move from menu mode to simulation mode. Pressing ‘L’ will switch back to menu mode.
These handy little shortcuts are obviously temporary, but help a lot in finding all the little problems that are still occurring. While it is already possible to switch back and forth, some things are still not getting reset properly: portals tend to stick around even after the reset and you better not try to add a light source or a temperature modifier and quit to the menu.
Anyway, things are progressing nicely and hopefully soon those issues will be weeded out, then it’ll be time to actually put in a menu of sorts and get rid of of my little dev shortcuts. Byeee. 🙂
Hello! For the time being, this commit basically breaks OLives until the next commit (or possibly the one after that). If you were to start it in its current state, you would get something like that:
These stunning visuals indicate that OLives is running in “menu” mode, so I’ll have to ask you to use your imagination for now.
The efforts currently go towards starting/stopping the simulation and all that this entails. To no big surprise that means many small (and some big) changes need to be made, some of which to code which hasn’t been touched in a while. Besides staring into this void for way too long, I’m pretty happy with the progress so far, so soon there will be a bit more to see again. Byeee 🙂
– Add mechanics to lower/raise elevations by tile – Refactor validation for lowering/raising so that both change types can use it – Add new assets for switching between tile based or vertex based changes
Hi! Another big step towards the end of the height map topic, it is now possible to actually edit the height map, albeit per vertex only. Check it out below:
If you have a closer look you will see that the possible vertices that can be changed are limited by the proximity to an object or a wall. It is also not possible to go above or below certain thresholds, I’m pretty happy with the result 🙂
The next step will either be declaring this topic as “done” – or checking out if it is (relatively) easily possible to have a per-tile mechanic, which would for more pleasant bulk editing. I am not entirely sure though if that even makes sense though from a UX perspective. Let’s see 🙂 Bye!
Hello! As promised last time, here’s a screenshot of what the build menu now looks like:
The astute observer will no doubt have noticed that some of the icons look different now, as well as that there are now two entries for raising/lowering the terrain. This is certainly the kind of adrenaline inducing content people come here for.
Now after setting up the basic drawing, wall, object and light positioning, adding new limitations for objects/walls and finally adding the UI the rest of the work concentrates on the main part of the entire topic: actually changing the elevation of the terrain, which will conclude this topic. More to come soon. Byee 🙂
Hi! This time I honestly don’t have that much to add to the actual commit message – which I actually mostly copied from the actual ticket. Except for the bug that is, that was just a bit of a surprise while implementing it. A lot more exciting is/are the upcoming commit(s), which will first add a UI for lowering/raising terrain and then actually hook it up to the mechanics, finally bringing all the previous work together. After that is done, the mechanics will get their usual glazing in game logic including:
Charging the player for them
Enabling/disabling UI elements accordingly
Not allowing to to change tiles/edges on which there is an object or wall
Anyway, there will definitely be a screenshot or video next time again. Byeee 🙂