Engine progress again

I’m back at in on the UI stuff for my game engine.

My september jam didn’t get very far, will probably pick it up again at some point, but I’ve been distracted by VR stuff again, and interested in potentially making my engine have OpenXR support sooner than planned, but of course I’ll need a working editor first, so I’m working on the UI pieces.

2022-10-09_14-38.png
I added a combo box and a Text box to my UI widgets, I’m still trying to figure some things for the text box, since for some reason it isn’t working, but the combo box operates well as a dropdown.

And here’s an example of the problem, using the same input callback, my own console that I rolled myself captures every character input, but for some reason the Nuklear UI textbox only gets every 3rd or 4th character, and its unreliable which it gets.

2022-10-09_14-44.png

Once I have those widgets all working properly I think it’ll be time to get an actual editor of sorts together, get model loading going, and then get onto the level saving/loading and asset packaging pieces.

Oh and I just noticed that if I sit in the engine long enough, the stupid thing segfaults.
My other project was to learn Vulkan in Rust, which I just might pick up instead of this engine since I’m running into so many memory issues.
Like I have no problem debugging mem issues, but it sure seems like I might have a higher chance of making a working engine if I go that route instead of this. But that would be another complete rewrite, and I’ve been enjoying this iteration. Not sure I feel like completely re-writing and starting from scratch in Rust, so we’ll see.

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]

Today’s update!

In the last two weeks I’ve:

Fixed some bugs in Breaditor Been working on a event-driven C++ UI system Been learning unique_ptr<> for the first time to deal with fixing ownership/lifetime issues for said UI system! Lost 5 lbs (idk does that count?)

@bengrue I do get on discord every once in a while to see what everyone’s up to.

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, here’s another weekly update.

I started blocking out some other rooms. I made this forest / plant zone underneath the “castle” zone:

some new rooms

Still super rough, and it will probably need to change as enemies and interactive objects are placed, and game progression is figured out. Anyway, having fun trying stuff out.

Trying to keep to decorating things with a limited amount of tiles, conveying the general texture / theme of stuff with a couple small repeating patterns. The forest uses about 3 main tiles:

foreground “grass”/“bush”/“leaf” tiles background tangled knot of roots/branches background vines/branches

Then there’s a couple blocks or bricks over that, but they’re less common in the central rooms of this area.

In designing the rooms, I tried to make sure every area has multiple exits and distinct areas that can be reached. I’ve been trying to make branching paths that have you weave through multiple rooms, so you need to figure out how things connect. It’s pretty basic so far though. There’s no key items or collectable abilities yet, so it’s pretty easy to “solve the maze” heh.

I still don’t know how I’ll fill in the rooms yet, but it’s a start.

Also started mocking up this HUD, just tossing something very basic in:
idevenk_1.png

Since it’s a “fixed-screen” platformer, I thought a static full-width HUD probably makes the most sense. I was originally thinking of a HUD that repositions itself depending on your spot, but realized those are a bit annoying. And hiding the HUD isn’t really an option unless player health is communicated some other way, or you have a life bar over your player (ugly). And a fixed, floating HUD like Mega Man is more fitting for a game with a scrolling camera and fairly tall corridors, it doesn’t really work here. So static HUD it is!

To compensate for the 8px of space used by the HUD, I scrolled the camera up a half-tile (4px) which seems to work ok. And it saves the need to edit all existing rooms to be 15 tiles tall instead of 16. I prototyped scrolling the camera slightly as you navigated but found it a bit annoying in practice to see it pan every time you go. So a fixed half-tile offset seems to be an ok compromise.

Still seems like I’m in recovery mode, but every couple of nights, I poke at this prototype for an hour or so. Wish I could eventually figure out where this is headed, but it’s still nice to make minor progress somewhere.

I also got my second shot on the weekend. Aside from a bit of a bruised/heavy feeling in my arm, and being a bit drowsy afterwards initially, there weren’t really a lot of other side-effects. After the 2 week recovery mark passes, this may mean more changes, as it will be possible to do a little more outside of the house. I’m still pretty hesitant about being too ambitious with that though, since lots of people still aren’t vaccinated yet, and the new delta variant, etc. Also it may mean working outside of my house a couple days a week, and I have mixed feelings about this. We’ll see.

Anyway, catch you next time!

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.