Time again for another update I guess, not much to report but I’ve been doing some good rework to make just the Texture loading for now be able to happen on a different thread from the update thread or the rendering thread.

So for that I have a threadpool that I think I yoinked from somewhere, which let’s me basically queue up functions or lambdas to be executed in the pool of threads. I can also configure how many threads are going to be in the pool, which I currently have set to 3.

Then I also found I needed a way to reference the future Texture that will be spat back from the thread once it’s loaded, so obviously I looked at std::future.

And then found that std::future doesn’t currently have a way to check if the value is ready without waiting for it, that’s an std::future experimental feature, since the std::future valid (or shared_future, for what I would use this for) only checks if the future is a valid future, not if the value/data was set.

So i rolled my own templated Future Class to simply have a way to set or get data from it, as well as tell if the data has been set or not with an isReady().
This means now all my std::shared_ptr<Texture> will need to become std::shared_ptr<Future<Texture>> so that’s quite a bit of refactoring, which I think is mostly done now.

One gotcha with this though, is I didn’t want my Future’s getData() to return the value, since that would be a lot of copying, so now instead of being T getData() it’s T* getData(), but that means now I have to be careful that the Future doesn’t get decontructed when the data is still referenced somewhere. This is a real problem because right now the Texture data is being passed via standard pointer like this to the Render thread, so there is in fact a possibility of segfaulting here.

I’ll probably look into how to wrap that, maybe my Future will hold the Texture as a std::shared_ptr<Texture> itself and return a std::shared_ptr<Texture> from getData instead of Texture*, that would likely solve the issue because then the Future<Texture> only holds a reference to the Texture that will clean itself once all other references are destructed, so it can stay in memory until after the rendering thread is done with it and then once it’s cleared out of the Update thread and the Rendering thread it’ll delete itself instead of leaking or becoming an invalid pointer that is used in the Render Thread.

That’s the main scoop for now I think, good progress though since most of the errors of switching the TextureLoader to return std::shared_ptr<Future<Texture>> are cleared up now and the getResource functions for that will now toss a lambda into the threadpool. I think the jury is still out on whether or not it’ll all actually work but considering that I already use a similar mechanism to the threadpool for my workqueue stuff, which is actively used, I think the lambdas and threadpool and everything should work, it’s only a little issue with that getData() returning a raw pointer and not a shared pointer and hopefully that’ll mean that now I won’t be bogged down as much doing Texture Loading.

I’ll need to do a lot more of this in the future I think, although I realized that I may not need to do this to all of my types, but it’ll probably help for anything that is large enough since I suspect Disk reading all needs to be dumped to a different thread.
And uh, actually I just remembered I need to re-check what I put into the lambda, I need to make sure that the disk reading part is inside the lambda, I think I left it out in front of the lambda portion…

https://www.youtube.com/shorts/D31SGqZV-9o

Breaditor UI Progress!

Devlog 2022-11-13 continued Godot 4 migration got cutscenes playing again fixed game saving/loading fixed shadows discovered that _ready() works subtly differently now lots of fighting with UI various other fixes

screen-20221113.jpg
You can actually get out of the house and talk to people again! The game crashes moments later when the shop interface attempts to load.

Not a super exciting week to report on; just continued slogging through the update process. If nothing else, this process is helping me reacquaint myself with the code after not looking at it for a few months!

Just a few miscellaneous notes this week…

Godot 4 Changed _ready()

In Godot, _ready() is called when the Node is, well, ready to start its set up (after all its children in the scene tree have completed their _ready() work). It’s where you do all your upfront initialization (usually), so it’s pretty important. In Godot 3, the _ready() defined in every class in your inheritance hierarchy gets called, in order, with your “local” _ready() being called last. This is different from how most function calls work, since they will call the “local” function and you have to explicitly call the super-class’s version by using .whatever().

In Godot 4, _ready() is no longer special (and instead of just using a bare . to call your super-class’s methods, you use super.) so you have to explicitly call super._ready() in your _ready() method. I actually think this is good! Consistency is great! It was just a surprise since that’s not how it worked before, and I only figured it out after some trial and error.

… And Some Other Things

There’s one other weird change that I’ve found, which I’m not as fond of. Classes in GDScript, especially in Godot 3, are a bit weird to work with as a data type themselves. It’s customary to override two particular functions, get_class() and is_class(), so that you can query what something is. They’d look something like

extends Node class_name FooBar func get_class(): return "FooBar" func is_class(class_name): return class_name == get_class() or .is_class(class_name)

which lets you write code like if thing.is_class(TheOneIWant):, allowing for inheritance etc etc.

Well, anyway, in Godot 4 you can’t do that because get_class appears to be special now and you can’t actually override it. I’m not sure if this is intentional or a current bug! Anyway, turns out that the is keyword does what you need now anyway so there’s not really any real reason for doing all of this anymore anyway. You can just write if thing is TheOneIWant and it handles inheritance correctly.

(I actually just popped open Godot 3.5 to see if I could figure out exactly how is works in Godot 3, but for some reason I couldn’t even get my test project to run and print anything at all to the console so if it’s worked this way all along, then I guess this more a note to myself than useful to anyone else.)

UI Continues to Baffle Me

I come from a web development background, primarily in frontend development, so it’s not that UI in general is mysterious to me but it always takes me several tries to get Godot’s UI system to do what I want. I’m glad the UI system is there, it’s quite capable! I just always have to fight it. Some combination of me using it in some bone-headed ways and some interesting decisions on the part of the auto-migration has led me to having to fix a lot of my menus and such to get them looking right again. I’m using the process to try to understand the theme system a bit better and actually, you know, use that instead of having a bunch of manual overrides everywhere. So again, probably for the better! It’s just work.

The Show Goes On

I’m getting impatient to get back to actually pushing the game forward. I don’t know I’ll manage that by next Sunday, but progress is progress.

Have a great week!

[original post on my devlog]

Wow I haven’t posted in so long that I got a prompt asking me if I want to create a new topic since this one is so old. This is more of a “still going” update.

I’ve gotten into a rhythm of working daily on the “metroidvania” (still hate that word but I’ll use it). My current goal is to make a fully traversable map. I’ve been doing lots of design work on graph paper (which is glued together to make a huge map). Then I transfer this design to the mapmaking tool I created earlier. I find designing the map on graph paper is easier than using software…because sometimes I find myself just staring at the screen doing nothing. This doesn’t happen with paper surprisingly. Sometimes oldschool methods still work!

Speaking of the mapmaking tool, I can do more actions with it now such as placement of “things”. A “thing” can be anything from an enemy, to a plant, to a moving platform (complete with a waypoint editor that lets me move platforms in complex sequences). Each thing can also be rotated/scaled/tinted, which allows for more diversity of stuff like plants, rocks, etc. I think the tool can do most of what I want it to do now.

Once I’m done with the fully traversable map, I will start filling it in more with enemies, powerups, etc. I’ve already designed all the powerups and created a general flow through each area with the required progress gates (powerups or other things needed to get past an obstacle). I also know the title of the game now, along with the overall story, but that will be shared at a later point.

One day I may have to start using social media again if I’m at a state where I’m happy enough with what I’ve created to share it with more of the world, even though I dislike social media in general.

This video really sums up how I’ve been approaching game development lately: https://www.youtube.com/watch?v=IN-Uh2VfL8c I find that as long as I just do stuff, instead of thinking too much about what I logically should do next, I get more done.

This is coming early since we’re leaving for a family vacation this afternoon. Which also means I’m not going to have time to finish up the last few things in my current sprint before I wanted it to end, but it’s fine. IT’S FINE.

Getting through sprint 0.1 means the underlying systems of the game are 75% to 80% complete. My current sprints match up with the same content and tasks I did the first go-round with Dawnshadow, so I have a pretty good idea with where I’m going. If my estimates hold true and I keep pace with last time, Epic of Serinor: Harbinger will be wrapped up and ready to release February 2022.

Vector art takes me longer than 8-bit pixel sprites, though. Especially since combat’s animated now.

Screenshot of Sai finding a fleeting shadow

New Progress

Implement resting routine Add damaged animation Add incapacitated animation Pass animation processing from battle handler to individual combatants Add incapacitated handling to battle for Sai and ally Add all Shadowed Citadel map events Add ally death processing to combat Draw ability icons for raptor arts Implement Shackle/Shatter switch and functionality Draw cultist combat sprite Add Change Rows functionality Draw saurian menu sprite Draw ability icons for saurian arts Draw saurian map sprite Draw saurian combat sprite Draw tiny bat combat sprite Implement permanent animation for flying entities Draw megabat combat sprite Implement ability effects Draw hopper combat sprite Save wyrmsblood chest contents at game start Access saved contents from individual wyrmsblood chests Script wyrmsblood events for Shadowed Citadel

Issues Resolved

Heal effects can overheal past exhaustion Enemies that kill Sai give their full XP award during the next fight Weapons missing from damaged and incapacitated animations Ally not removed from party after death Raptor missing damaged animation Success rate on Shackle seems suspiciously high CTD if Sai shatters ally, but only from front row

Hi! It’s been a while! I haven’t posted in a while, I might try to write a proper full blog post at some point. But for now, I thought I’d do a little “Happy Holidays” post and share something neat I’ve been working on:

2b33b46d-3599-43b5-97cd-7a80ef3c32a2-image.png 56e02c3b-0638-4381-aa79-412679de0515-image.png 56a43063-de48-48fd-bb91-b847224fcf8b-image.png c75631d5-5808-46bd-bcae-5ccb3ebb6cc6-image.png 4591cb37-ab84-403b-b149-da78824b9d2e-image.png6e6c1ac3-c16a-4b37-a3f3-73b93c49035b-image.png 2c09a9d8-0408-4b03-ab74-5b4f91c85f06-image.png 91e369a9-24e8-47f5-9110-349fb6371d97-image.png e3f53eb0-b77a-4fa9-9bf5-00c0432d870b-image.png

These are screenshots from an in-the-browser version of Verge 3, running a few games I’ve tested/gotten working with it. It’s built on top Emscripten, and targets a WASM binary. Only tested in Chrome, but should probably work in Firefox too – needs a fairly modern browser to support the features it needs to run, like audio worklets. Some of these aren’t even compatible under the newest Verge, so this was simultaneously a project to port to the web, and to add compatibility configs to Verge so that it could open older versions.

Try it out: https://make.vg/v3wasm/wip-2022-12-22/ (fingers crossed the bandwidth for this isn’t going to be too heavy and melt down my poor server, these are pretty big downloads, but we’ll try it for now!)

The source branch is here: https://github.com/verge-rpg/verge3/tree/ovk-wip-3.2-wasm-2022


 

Thanks to the work already done by Andy Friesen on v1wasm + v2wasm (Verge Archive: https://andyfriesen.com/verge-archive/) a lot of stuff was already figured out. This builds off that, makes some improvements, and also solves more problems unique to V3. I’d eventually like to merge it in with the rest of the Verge Archive page.

It would potentially be neat to cut a new desktop build when this is done, too.

Basically, I undo the trunk changes after Verge 3.2 that removed VC in favor of only Lua + some other sweeping ‘kill legacy code’ changes that didn’t pan out. In hindsight, it was probably overambitious, and also didn’t anticipate that running old versions of Verge would become increasingly harder in newer OSes.

I added a bunch of compatibility stuff to deal with incompatible versions of system.xvc – the sad part is, Verge 3 had a version in its system.xvc, but not once did we bump it as we changed the format. I guess the assumption there was we’d never want to run an xvc from an older version with a new one, you should always redistribute it with the verge.exe it was meant to be played with, and we’d always have source access to generate the xvc. But that doesn’t really work as great if you want to play those old versions years later, after the source was lost, and the version of executable they came with is maybe not working that well in newer Windows.

There’s also some compatibility for compiling VC code, re-adding some language features that were previously removed, allowing a way to override the built-in library functions in user code (min, max, abs redefinition problems come up a lot), and ignoring duplicate definitions for some stuff (some games redefine things more than once, and it used to compile because it would ignore the second definition).

Another thing is this uses SDL 2 instead of 1.3 like it used to for its SDL backends. This means it builds against something that actually has long-term support and unlike 1.3, SDL2 has a native wasm build provided with Emscripten.

The Linux and Mac ports could benefit from the SDL 2 migration, if they were dusted off. The Linux build will no longer need X11 to do MessageBox since SDL provides its own implementation now, joysticks support hot-plugging in the SDL build. I implemented some window scaling stuff for the SDL version that previously was only done for the GDI windows version. Additionally, the WASM build of the game has an interesting thing where it will auto-escape slashes + lowercase all the paths you pass it as part of opening a file – it would be cool if we had a mode to let desktop builds also do this, so Windows-only games can be portable without changing the original game.

One thing I’d really like to see is a way to run games from .zip. Then it wouldn’t need to prepare a manifest.txt (a file listing used by the web version can preload the files), since the listing could be taken directly from the zip directory structure, and the browser could fetch less things + have slightly more compression. (maybe not a big deal in light of GZIP’d http responses, but still, could be worth looking into). The other advantage, is the paths don’t need to be lower-cased. And overall, more games could be run as-is directly out of their archive, aside from potentially needing verge.cfg edits.

Anyway, posting it in case so other people can check out / potentially help continue the effort! I’m going to be busy with holidays, and may need a break from this project. Still, I’m impressed what was possible in such a short time. I started this a couple weeks ago + plugged away at it on nights/weekends and a little bit on my break.

Seeing this engine suddenly run these old games in the browser is kinda magic, I hope it can keep being improved!

Sorry about the downtime; there was a server reboot and I hadn’t set up the site to come up without manual intervention yet. Whoops.

Loretian! You should join the discord, would be the easiest way to chat, and share files, hah! Invite link is https://discord.gg/5EVb3w7

More NES emulation…

We didn’t like how this other RPG game was rolling random encounters. It happened on the first step too often. Very annoying. I think there needs to be some kind of step counter setup with a minimum value… I don’t know how many games do that. Is it possible they have arranged the statistics so that low rolls are less common? I haven’t checked this in a while.

This game has 4 terrain types, and up to 4 encounters per terrain type; on top of that it is organized into zones in the world map (thus further-away zones have harder encounter sets). There is only one monster per encounter, so encounter type = monster type. The data is organized this way:

struct EncounterDataForWorldZone { byte chances[4][4]; byte monsters[4][4]; } EncounterDataForWorldZone encounterData[N]; //N zones in the game, N unknown

Now, for each step, the game gets a random number R from a flat distribution. It then considers chances[currterrain][0] = C as a C/256 chance of getting the encounter on that step. We see if R is less than C and do the encounter if so. Otherwise C is subtracted from the random number, so the next chance C’ from chances[currterrain][1] is a C’/(256-C) chance. And so on.

Generally the chances near the beginning of the game where we were testing, is, I dont know, 16-20 or so. So it’s easy to see why we get too many encounters… and why they can happen on the first step so often.

My first thought was to use the old “turn it into a normal distribution” trick by changing a 1d256 roll into a 2d128. This biases more normal rolls in the middle at the expense of rolls in the tails. So we did this for a while, and it felt okay… but we weren’t testing the whole game, and I got nervous.

Let’s take a simplified scenario where we have 2 encounter chances, each of value 64. Now the original way it was done, each of those would be a 64 in 256 chance (1 in 256). Well, kind of, because of how the subtraction happens in the algorithm. Anyway with two dice, there’s fewer ways of rolling the smallest 64 numbers than there are the next 64 numbers (just like there’s only one way to roll a 2 on two dice but there’s many ways to roll a 7). And yet since they’re adding up to 128, the new probability distribution is centered on 128, and the absolute probability of an encounter is still the same! All we accomplished was to bias the selection to the later encounters. This would change the character of the game in a way we don’t really have time to test and scrutinize.

So my romhacker came up with a better idea to add a tiny bit of logic to only do encounter checks on every other step. This way you won’t get them on successive steps under any circumstances, and we get the other desired result of just generally fewer encounters–precisely half as many, without having to grapple with the really thorny problem of how to do it, logically speaking, without affecting the design of the game by biasing certain encounters. Actually after a little more iteration we developed an approach to run it with any divisor so that I could give another option to reduce encounters by half again (so a divisor of 4) from the emulation menu, so people would feel a bit empowered to be masters of their own destinies instead of frustrated by the fixed design. (There’s also a cheat to disable encounters entirely)

So it’s been a few weeks, and luckily this time I actually do have some progress to report! The mockup from the above post has now been fully implemented. The movement buttons are clickable (if you’re crazy enough to play it that way), and in that bottom right multi-purpse section as well are sections for using keypads to open code-locked doors, and my personal favorite, lootable chests. With the convenience of rightclicking to auto-add to your inventory:

lootchest.gif

As for the map area that used to be in the bottom section, I may repurpose it to be a more general “wireframe” area map of whatever deck you are on, but this hasn’t yet been fully decided. Of course that area is still used for log entries/objectives, and stats as well. As a quality of life feature, you can also now use the mousewheel when reading logs!

There are still a couple features that need to be re-added to the pygame port, such as the air pressure system for hull breaches, and the “smooth” movement which transitions when walking between squares of the map. This will be an optional feature since not everyone prefers that look, though it does make more clear especially in videos which way the player is moving. Long term, one big feature to still add is saving and loading, which is a bit more complex than just saving player stats because the world is not static. But I have a few ideas on how to handle that.

All in all, it is already starting to feel less like a tech demo and more like an actual game. Hoping I can keep up the momentum!

Just a small update that’s 2 weeks late.

My fiancee’s younger sister (there’s a biiiig age gap between them) is only 14 and an AMAZING artist. In school she’s in a program where she’s been doing some pixel art and has fallen in love with it. She’s ridiculously good at it too.

Unfortunately, I don’t have any of her pixel art, but I do have a few of her pieces screenshotted.

alt text

I remember having a conversation with her last year about her playing with Godot a bit in school, and she was given all these links so that she could do stuff at home. But, they didn’t have a computer at home. Out of the entire family, I think she relates to me most because she loves games, loves the idea of game development, is, again, a fantastic artist especially for her age, but just never had the resources at home to pursue it outside of school hours.

Well, I upgraded my computer last year, so I had some spare parts. For her birthday this year, I bought a couple of other parts and ended up building her, her very own computer. Her Mom then bought her a monitor, and now she has a nice little PC setup she can mess around with.

Last night she showed me some of the stuff she was working on and it was really cool. She’s played some of my old Verge games and other projects, and was picking my brain about a game idea she had. She already has the main character designed, showed me the pixel version she created, and it looks really good. I was really blown away. Not only that, she was telling me about the style of game, ideas she had for mechanics, and we kind of brainstormed together about what it would like/how it would play, etc. It was a lot of fun…and I remember thinking at her age was probably when I first started becoming interested in game dev, so it was just all around a cool thing.

She asked if I would help her make this game, if she did all the art, would I be willing to help her with programming and making it come to life.

I definitely did my best to set expectations for her…game dev is hard, it takes a long time, we might not finish it (as is our way), she may lose interest, etc. etc., but that I’ve been looking for a project, and would be happy to spend some time putting stuff together for her and helping her bring a vision to life.

So, hopefully for the next post I’ll have some screens to show you, because I think you’ll all be pretty impressed with her work.

Now, I’m excited too.

Time to stop losing.

I’ve been working on a game I titled “.V4MP1R3”. It is a single player, 2D, story driven game. I do not have any combat defined at this time, but I’d like it to be open ended and strategic.

vsc1.png

vsc2.png

The main inspirations are:

Shadowrun (universe) Cyberpunk (universe) Shadowrun SNES (lots of gameplay/gamefeel) Shadowrun Genesis (shares a lot of the same grittiness/gamefeel) Tibia MMO (Oblique 2D perspective) Ultima VI (Oblique 2D perspective) Fallout (excessive looting)

This was also made for a gamejam semi-hosted on discord and I submitted around the end of September deadline. So version 0.0.1 on windows was birthed here: https://drive.google.com/file/d/1b7FPniLAQ5r9lTYaxR9lwF-b6z_bCW01/view?usp=sharing

I plan on doing another release at the end of the month to keep up momentum. Until I have a newborn to care for which is coming up really soon!! 🤣

@bengrue said in Test test test:

https://www.youtube.com/watch?v=dQw4w9WgXcQ

https://www.youtube.com/watch?v=dQw4w9WgXcQ

I think it comes down to what are the most irritating things to have to work around. Because anything I wanted to do, I could. It’s just ugly sometimes.

I think the biggest one for me would be having access to real floats. I ran into integer rollover issues trying to get good precision in Dawnshadow’s damage calculation and had to break it up. And regeneration effects regenerate health unevenly. Again, I could have designed it better (and may yet) but it was one of the more aggravating bits to get working properly with only ints.

Member functions or the ability to pass structs as arguments would have been occasionally useful, but they’re not critical since everything is public. I made good use of two of the more recent additions to vc, specifically dicts and varargs. Those were very useful.

And make sure to warn people if order of operations ever gets fixed. I know that I coded some things with the assumption Verge would read it left to right.

Worked for EA several years, got some health issues because of the stress and everything. I have mostly recovered, currently at a temporary job, and working on a new project, more ambitious than previous ones, but using some nice tools to organize my work (https://www.worldanvil.com). It’s titled “Record of the Dragon Goddess”

It’s about a world created by a Dragon God, and how things don’t go as he expected. The story follows the actions of his two offsprings, Amaxis and Draxenath, as perceived from the mortals’ perspective. I have been working on an “Interview with the Dragon Goddess” as a form of introductory series of texts.
Record of the Dragon Goddess blog

I hope to join you on Discord soon.

It’s this one.

MLK day!

Week 9: Not Much

This week I took time off from my personal projects and basically worked a lot and focused on Path of Exile.

As a part of that, I did build a small simulator that modeled the damage output of the Path of Exile bleed mechanic, but it’s not something I plan to share with the world. Here’s a screenshot:

858077a5-1de7-4222-9fa4-a4f66d5344b8-image.png

Next Week

More of the same, I predict. I’m taking a brief break from game dev. But I wanted to continue posting here so it is easier for me to transition back into active dev work.

The Verge3 docs you uploaded are perfect, thanks so much!

June devlog time!

During the month of June, I submitted The Mangotronics Employment Collection to Steam for review. I was finally able to get whitelisted for a Steamworks publisher account after a bunch of annoying back-and-forth, setting up a business bank account and all that fun stuff. Here’s the bulleted list of my accomplishments this month.

What I Did:

Got a Steam publisher account Added 3 new games to the collection (signed 2 more contracts) Did a lot of planning and re-prioritization of tasks Updated the web site & published 3 minor updates to Itch.io Integrated the Steamworks API into the existing project Added achievements and Steamcloud support Submitted to Steam for review

What I Need to Do:

Monitor the results of Valve’s review process Make any necessary changes and resubmit Add another game and throw feature creep out the window Marketing marketing marketing… Testing testing testing… Press the Publish button

The planned release is for July 22nd, and I’m stoked!

I’ll follow up to this post with details on the above accomplishments hopefully before then.