Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[King Zultan]

You seem to be making massive amounts of progress in very little time, I don't get how you do it as programming seems like magic to me.

[delphonso]

Some of this is stuff I've already done (migrant movement isn't too different from Sewer Kings combat plus the state system of the fish/Sleeper). A lot of this is totally new territory though, which is why it's pretty janky - and will need to be rewritten a few times. Mostly I'm trying to think a few steps ahead and build a flexible enough game infrastructure that I can handle stuff like a campaign later.

The guy who made Delta V said something like 'Game dev isn't hard, it's just thousands of simple tasks you have to do.' Which is pretty true, I think. It's a big list of problems with pretty simple solutions. The speed comes from me just not making any more problems with my solutions.

I got two hours of sleep last night and so will likely not work on this over the weekend. I'm doing some 'research' by playing some other RTS games. 0AD, for example, is very technically impressive, but a bit exhausting overall. A lot of resources and the tech trees are complex in a way I don't find rewarding.

[delphonso]

Okay, so the input bug was an easy fix - it wasn't actually a global_position bug, it was an event.position bug - it's already fixed and now means you can click around whereever.

This will likely be my solution for pawns moving about and bumping each other. Tomorrow, I'll either try to get a working version of this, or build on my existing code to allow for the challenges of Task 2.

[delphonso]

Okay, I promise I'm done with Task 1.

It's here!

So basically all this does is fix the annoying camera bug, and add a very shitty pathfinding (technically steering/avoidance) behavior to the migrants that I stole from this tutorial. This code was written by moonmen and it's a joke that this is intended for kids. It does use an interesting function of the engine that allows you to throw raycasts without instancing them, which I should probably learn how to use. However it is not particularly reliable when it comes to avoiding moving objects such as other units (I think this is one of the improvements of Godot 4). Overall the migrants are less likely to get stuck, but still do occasionally get stuck when jobs are finished and they have nowhere to go - this is fine, as it is also how it works in Starcraft (though it looks less glitchy when the SCVs do it.)

I didn't solve the issue when you spawn multiple dudes on top of each other - but oh well.

I also ensured the UI is above the migrants - previously you could get the migrants to walk on the UI because of how they were instanced later than the UI.

Important lessons were learned, and now to move on to Task 2.

This kids can code thing is actually driving me nuts and I'll try to better communicate what I'm doing in the next posts - because who knows if anyone will use this as a tutorial at some point.

[King Zultan]

Looking good so far, can't wait to see what's to come.

I didn't solve the issue when you spawn multiple dudes on top of each other - but oh well.

Is the issue where the guy flies off into space when you spawn a second one?

[delphonso]

Yeah. The two (or more) pawns can be spawned in the same spot, but as soon as they move, they're going to do collision checks with each other, and apparently being perfectly inside each other doesn't have a good solution, except freaking the fuck out.

[Starver]

If you don't want to do "is one of these spawned aready in collision with another, if so then deal wth that as a special case of rearranging the newcomer" (or, possibly, give it an immunity until things change), which is probably the best special-purpose on-spawn handling situation, then you could just make every standard collision check:
1) Add a randomised/cyclic (sub-unit) vector to element, to reduce clashes (if they clash because of this added jiggle, it shouldn't be a 'fatal' one and it just adds a little 'personal space' impetus to nearly-touching pairs).
2) If your system does an inverse-square repulsive 'force', jump in there and cap it at the "exactly touching" amount (or even refacor it to non-inverse-linear?)... i.e. refactor so that zero_distance=zero_repulse (and quantum-stacking, for the moment), and a steady increase of push, nothing tending towards infinity or max_Int...

TIMTOWTDI, depending on your preferences.

[delphonso]

Apparently I solved the grid issue in a single line of code. All the more time and energy to make the game better.

Quite simply, I'll just check where the mouse is, then use the engine's snapped() function to snap it to the nearest point that is a multiple of whatever cell size I tell it. That cell size is stored in a Vector2, so I need to provide it with an X and a Y value. So a 4,2 is a rectangle that is 2 pixels tall and 4 pixels wide. The size of the grid that I want is stored elsewhere to make it easy to change whenever I want. Here the grid is 64, and I put it to half as it felt better. I can also add an offset by just adding another Vector2 to the end of that - get_global_mouse_position().snapped(Vector2(grid_size,grid_size)) + Vector2(32,32), I will probably do this otherwise the building will snap to 0,0 - which puts it at the top left corner of your screen and only 25% of it is visible.

I originally made a function to give myself a big list of all the acceptable positions to place the buildings, but that's really unnecessary - this is a simpler and more efficient solution. The biggest hurdle now will be again in the pawn behavior - they'll need to path to the desired building location and put it together, without getting stuck inside.

I also found this game by browsing OpenGameArt. It's opensource and more in-line with my desires. Not a big fan of the overall design, but I'll definitely look at the code for solutions, and play a bit because it does look interesting. The sprites are on a CC0 license, so I'll probably use it as placeholders for now.

If you don't want to do "is one of these spawned aready in collision with another, if so then deal wth that as a special case of rearranging the newcomer" (or, possibly, give it an immunity until things change), which is probably the best special-purpose on-spawn handling situation, then you could just make every standard collision check:
1) Add a randomised/cyclic (sub-unit) vector to element, to reduce clashes (if they clash because of this added jiggle, it shouldn't be a 'fatal' one and it just adds a little 'personal space' impetus to nearly-touching pairs).
2) If your system does an inverse-square repulsive 'force', jump in there and cap it at the "exactly touching" amount (or even refacor it to non-inverse-linear?)... i.e. refactor so that zero_distance=zero_repulse (and quantum-stacking, for the moment), and a steady increase of push, nothing tending towards infinity or max_Int...

Aye, solution 1 was something I did immediately (position.x + randi(), position.y + randi()), but decided against it as it replaces one issue with another. Solution 2 is certainly possible, but manipulating the build-in physics handlers is a bit too much for me.

I'll likely just figure out a way to check for units, or perhaps shuffle old units out of the way instead. 0AD has the units come out in a queue that goes to 5, then starts a new queue. This seems to be standard, and I'm sure I can figure out a way to do it if I've got a clear mind and a bit of focus.

TIMTOWTDI, depending on your preferences.

This is one hell of an acronym, but hey TIMTOWTSAC.

[King Zultan]

I'm lost as to what the acronyms stand for.

[Starver]

https://en.wiktionary.org/wiki/TIMTOWTDI (Because it can be said as an acronym, I tend to use it in favour of the initialism 'original'.)

I hadn't yet decided if the other was "...[Say/Spell] Acronyms Correctly", or something else, but clearly at least *I* had been understood, despite myself...

[King Zultan]

Now that I look at it again after reading that it makes total since.

[delphonso]

https://en.wiktionary.org/wiki/TIMTOWTDI (Because it can be said as an acronym, I tend to use it in favour of the initialism 'original'.)

I hadn't yet decided if the other was "...[Say/Spell] Acronyms Correctly", or something else, but clearly at least *I* had been understood, despite myself...

Can't believe it's Tim Toady and not more like Tic Tac Toe - Tim Tow Tdii (Tea). My was "There Is More Than One Way To Skin A Cat."


Anyway.

ahem.

It took me about 4 days to get any work in at all and then I did all the work.

Things left to do:
Allow Migrants to build buildings.
Work out the logic for tech-checking.

Everything else is done or will just be recycled code. So let's discuss what was done:



Here's the controller, right now - it uses the same methods to determine where you clicked - checking the sprite size. Until I find enough issues with this that I need to change it, I'll never change it.

The info_dump.clear() thing need to be removed, just from some testing before. I actually will quickly edit the code file now.
Also, I just didn't determine any controls for the mouse, so to "click", you have to press the up arrow. Look, this is early days still.

Instead of doing any of the checks in the controller, I left everything in a "bottom-up" configuration. You click on the command center, for example, and it calls a function in command center that is named "info_pass()". This means I need to build that function in everything that can be clicked (which is determined by the click_allow group). Luckily, the game will crash if I click on something that doesn't have that function - so it's easy to test! The info is stored in info_dump, which is called by the controller's parent: the camera. We'll talk about that in a bit.



The command center is pictured above - the info_pass() just sends up those same variables we've seen before, which have a few variations this time. Cost of things is stored in the global, and I've also included a fan-gamey thing where fort (and migrant) names are generated upon instancing. The tech option is just a string, but the global will keep track of whether the tech has been researched or not. I'll need to add that logic in later.

So, we can see that the command center, when asked to info_pass will make info_dump look something like this:
info_dump = ["Smallhands: Mountainhome", "Hire Migrant (200)", "Research Military"]

So how do we use that information?

Unfortunately, I'm a monster.



This is bad and I should feel bad (but I don't.)

Let's go through this line-by-line.
first, home (I have no idea why I named it that) grabs the info from the info_dump, if there is one.
The buttons on the UI are then all cleared and reset.
If home has multiple bits of information, those are placed on the buttons and the buttons are enabled. There's an exception here for the resource nodes, which pass a number up (i.e., not a string) and that info is placed on a button, but it doesn't look like a button.
If there's no info except a name, then just the name is displayed.

This is not very modular and also I'm not sure if I'm a big fan of all the work this method would require if we have like....4 playable factions.

Anyway, there's where I'm done.

I added a randomization level to the map - which will come with some issues, but oh well. This just throws a command center and 8 metal nodes around the map.



Finally, here's some examples of the dwarf names and fort names that are generated. Finding fort names was easy (thanks for the Hall of Legends), but finding the dwarven names is lacking. Does anyone know of a list of dwarven names? All else fails, I can use legend mode.



(Dwarven names are just the first few dwarven words, but dwarves don't name their kids things like "spring" or "angel", so some seem a bit off.)

[King Zultan]

Having randomly generated names for the dwarves and forts is pretty cool.

But is Urist included in the list, since it is the most important dwarven name it should be there somewhere?

[delphonso]

Having randomly generated names for the dwarves and forts is pretty cool.

But is Urist included in the list, since it is the most important dwarven name it should be there somewhere?

Thanks! It's easy to do and also helps remind me that this is a DF fan game, because right now...well it's mostly blue squares.

Urist is now on the list. I'll scrub through legends and make some documents of all the name components.


Alright. Let's see what I've been up to:

Spoiler: GIF (click to show/hide)

So first off, I added some sprites from the Wyrmsun project (it's neat, but not incredibly impressive). The sprites are open source, but still, I'll want to replace these at some point. As you can see, the pawns still have some shoving issues, but are mostly much better. That's because of this:

Code: [Select]

func _on_area_body_entered(body):
[...]
        elif body.is_in_group("unit"):
if body.target == target and body.state == body.State.IDLE:
state = State.IDLE

Basically, if you run into someone who is going the same place you are, and they're stopped, you stop too. This means that the first pawn is really the only one who stops where you ask them to, but they don't get stuck in a long line, thanks to that steering algorithm they've got. It actually feels very good.

Unfortunately, this only works on-body-entered, which doesn't pop if you started within each other's personal bubbles. I'll need to add a fix to that. (It's later in this post)



I also didn't add any stopping logic when I was testing their ability to go mine - so they just sucked this metals vein down into the negatives. There was also an issue with running the mining in the process. We've run into this in basically every game. yield() doesn't work in process, because it keeps getting called and overwriting itself. I believe this was fixed in Godot 4 with the new "await". I fixed this just by avoiding yield and using conditionals and a counter instead.

Spoiler: GIF (click to show/hide)

Here you can see that the behavior is all working well - this was actually pretty easy. Just fine-tuning the same algorithms from before. However, there's a few differences. Namely, that counter.

Code: [Select]

        [...]
elif state == State.GATHER:
if counter > 3:
if work.metals >= 50:
work.metals -= 50
cargo += 50
elif work.metals > 0:
cargo = work.metals
work.metals = 0
else: state = State.IDLE
target = get_home()
state = State.MOVE
counter = 0
if counter <= 3:
counter += delta
elif state == State.DROP:
if counter > 1.5:
if cargo:
glob.metals += cargo
cargo = 0
else: state = State.IDLE
target = last_target
state = State.MOVE
counter = 0
if counter <= 1.5:
counter += delta

Here's the state machine which is done in the process. Instead of using yield(), we're just using a variable called counter. It's just counting the "delta" which is roughly 0.013 per frame, I think. The 3 and 1.5 is roughly half-seconds, but I'll fine-tune it as I keep going.

The variable "work" here is just a container to keep the last-entered body (i.e., the metals node the migrant is working on), which means I can do this in the process instead of in the body-entered function. Likewise, get_home() is a new function that just checks for any resource-dropping places on the map and choose the closest one.

This is great because it allows for this:

Spoiler: GIF (click to show/hide)

This sort of behavior would be necessary for having multiple command centers or for "drop-off" buildings like are used in 0AD and many other RTSs.

The migrants also have an ignore range now. Basically, if they're here, they're close enough.

Code: [Select]

       elif state == State.MOVE:
if (target - global_position).length() <= 16:
state = State.IDLE

This '16' is the same size as the migrant's radius, but will need to be tweaked to deal with mixed units. I'm not sure how to go about it, because if I make it too big, the pawns clearly aren't going to where you tell them to, and if it's too small they bump each other trying to get to the spot. Maybe I can use counter here as well to count-down until it's okay to IDLE. We'll see.

I found this name generator: https://www.d0rfforge.com/
Which either I can use on my own or use the same method (literally shipping the language raws with the game) to determine names. I'm undecided as of now.

Progress is speedy, but slowing as I polish and fine-tune what is already here. There is no waste, though - all is useful in the grand schemes.

[brewer bob]

It's nice to see the progress. That GIF with the pawns moving and stopping is quite captivating.