Print

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

[delphonso]

I also have a weird desire to make Simon, which is not really a standalone game by any means, but could be put in the same "game" as this and maybe some other stuff. I don't know where that chain of thoughts will go. Warioware?

You know that'd be pretty cool to have a game filled with mini games, you'd even be able to use all the other small games you've made for it.

For some reason the first thing I thought of was Space Quest III and the arcade game you could play in it. Astro Chicken was its name, I think.

We'll see if my work-computer turns into a Wario-Ware thing. I love a good old fashioned "game in a game". Hell, I think that's why I played the Yakuza series at all.

So, uhhh....


Dwarf Fortress Fan-game RTS?

After using AI to generate that image of dwarves fighting a cyclops, and coming off a recent discussion with a friend on the dwindling RTS supply, I think this is the project for me:

A dwarf-fortress themed RTS. The mechanics and what's special? Right now, genuinely nothing, because I gotta learn the new engine, baby and also have never made an RTS.

Let's get started with the basics:



We'll need 3 types of objects: A command center, a worker and a resource node. I played Starcraft a lot as a kid (it was the only game I had for quite some time), so a lot of my references and influence will come from there, despite the game being more similar to Warcraft, I expect.

So, the command center serves the following functions:
a place to generate new units
the place where units drop off collected supplies.

The workers:
collect resources from a resource node
carry it back to the command center
continue to work without direction

While resource nodes:
stand there and look pretty.

So, let's get to coding.

Quite simply, the resource node does nothing but keep track of how many resources it has, here-on referred to as 'metals'



In the editor, the metals node is a simple object. A sprite with a collision box and an area around it with its own collision box. I also add it to the group "resource".

Groups are not a new feature, but are something I only really just started using. They're similar to "classes" in computer science terms, but in practice are just a way to identify and group nodes. If you have a bunch of objects all over a mario-like game, for example, you can have a group of "hazards" and a group of "platforms" and have the player always walk on top of platforms and die if they touch a hazard. It's pretty straight forward.

The command center itself has no code, really - I didn't even make it a separate scene, and just baked it into the "world" scene. It is very similar in structure to the resource spot. It has one extra element called a Marker2D, which is just the new name for Position2D - a position on the map where I can spawn new units from.

The workers are called Migrants right now, and are pretty straight forward State-machines.



They can Idle, where they just stand there, they can move - which allows them to walk in a straight line toward their target, and they can collect which would be them mining for metals or dropping off at the command center.

You'll notice this new guy "await" - it's the new version of yield in Godot 4, and seems pretty smooth. Here it's just waiting 1 second.

All the direction information happens when the pawn gets close to a building. It's all here:



I check what group the nearest object is in, which should always be whatever the pawn runs into while walking, but could become an issue if there are buildings in the way.

Cargo is dropped off if it's a command center, and you head back to the resource. If it's a resource, cargo is collected and the value of the resource spot is dropped - then they target the command center.

I use a placeholder called "last_target" so they can remember where they last collected resources and use home as a permanent storage place for the command center. After dropping things off, they head back to where they came from, to collect more. If the resource is depleted when they get there - they just idle.

With all that done, basically all that is necessary is player input, and that's where things got tough. This all changed quite a bit from last version, and I also heavily relied on Tilemaps for my last few games, which are also completely different.



You can see I was getting pretty desperate by the time I figured it out...

So here's what's happening... When you click on the map, we need to figure out what you clicked on.

We check to see if it's the command center by grabbing the command center sprite and getting the rectangle that it fills. get_rect() returns something that looks like this: P: Vector2(-16,-16), S:Vector2(256,256) P is for position, and is a local variable - so since the sprite is anchored to the parent at the top-left corner, P = 0,0. S is for size, if the sprite is 256x256, then you'd get what I have in the example there. Here's the issue - Rect Objects can change to a different format: Rect(x,y,height,width) which is the same, but the values are separated. Different operations in the code can convert the rectangles to either format depending on the operation - which, my brother in Christ, is something I did not know and spent about 40 minutes confounded by.

So, here's my easy solution: reset the P to the global_position of the sprite's top-left corner. There's a couple issues, though. That size value is unmodified. Inside the editor, you can scale up or down these sprites, but the Rect that is returned by get_rect does not take that into account, and modifying the Rectangle changes it to the second format, which makes assigning it to the correct global position just a bit more inconvenient. It's a pain in the ass and I don't want to deal with it at all - and I shouldn't because There's Got To Be A Better Way!

I'll figure one out, but this is functional and enough work for today. But wait! - if this is such a pain in the ass, how will you handle selecting units?

Heh, here's the trick kid...

I won't.



We add a button to spawn new migrants if you have 200 resources.



Press the button and get a new migrant - they're already fed the information they need: home is where the heart is, and go find a random resource node.



Heh. It's too easy.


Also it looks like shit.



-=-=-=-=-=-=-=-=-=-=-=-=-

ENJOY!

Click is the only control.
There's a Zultan Approved Windows 32-bit version too.

FAKEEDIT: After uploading I remembered that Godot 4's HTML exports are still fucked, so instead, there's also a linux export there, if you want to play.

[King Zultan]

It looks really cool but I can't play it for some reason, a thing pops up and says I have the wrong Vulkan version, not really sure what that means.

[brewer bob]

a thing pops up and says I have the wrong Vulkan version

Have you been watching something that has someone else than Nimoy as Spock?

[King Zultan]

a thing pops up and says I have the wrong Vulkan version

Have you been watching something that has someone else than Nimoy as Spock?

I don't think that's the problem as I've only watched the original Star Trek, so it must be some other thing to do with Vulkans.

[EuchreJack]

Nope, not working.

[King Zultan]

I to got that when I tried it in the browser.

[delphonso]

Yeah the browser one is known to be borged borked, but the Windows one is supposed to work. I'll read up on it tonight and try to get a working version out.

Edit: we didn't get home until nearly 9 and I've got work tomorrow, so I'll miss this for a night.

[delphonso]

Or I'll miss it for several nights. Look, I'm a busy guy.

I've got a solution I'm satisfied with, for now - still need to better systematize and optimize it, but I'm good with this.

Code: [Select]

var command_rad = 72 (size of sprite)

func _input(event):
if event is InputEventMouseButton and event.button_index == MOUSE_BUTTON_LEFT:
for centers in get_tree().get_nodes_in_group("command"):
if (event.global_position - centers.global_position).length() <= command_rad:
print("command center clicked!")

This simply subtracts the center position of the object from the position of the mouse click. If the length between them is less than the size of the sprite, you must have clicked on the sprite, and thus, have selected the thing you want to select. This is good, and works despite re-sizing, as I can use some code to get the size of the actual sprite just once when starting the game.

Okay, I'm working on the exporting thing now.

Zultan, try downloading the zip I've put up there now, as it might work?

Also, EuchreJack, do you happen to use Firefox?


Exporting issues:

You can now export Godot to HTML, again - but it requires a special header that Itch only supports outside Firefox (for now?)

Exports for Linux, Mac and Windows should all still work just fine, but all require some set-up first. I'm a bit wiped to try and figure that out now, but will work on it. If it's really too much of a pain, I'll downgrade myself back to 3.5 until it's easy-peasy again. The Vulkan issue could be a driver issue, which I might be able to fix by changing the export engine, as I tried in that export there.

[King Zultan]

Zultan, try downloading the zip I've put up there now, as it might work?

Also, EuchreJack, do you happen to use Firefox?

I no longer get issues about Vulkens but now it's saying my Opengl doesn't support 3.3 whatever that is and I've never been brave enough to figure out how to do something about it, guess I'll be missing out on this one. Not sure why it's an issue now I've been able to play all the games you made before this one.


Also I was on firefox when I tried to play it in the browser.

[delphonso]

The transition to Godot 4 included a rendering engine overhaul. Vulkan is the frontrunner, but there's a 'compatibility mode' which uses OpenGL, though obviously the OpenGL version is different than what I was using in Godot 3.5. Some of the details are too technical for me, so this might be a bit fast and loose on credibility.

I'll see if I can get the browser one to work, as it should work on any Chromium-based browser (read, literally all of them now).


Edit: "Godot 3's HTML5 exports are more compatible with various browsers in general, especially when using the GLES2 rendering backend (which only requires WebGL 1.0)."

The headers issue is one of those tech issues that is so simple to programmers that they can't communicate it to people like me. Alas, I'll keep trying for tonight. If all else fails, I'm at a good place to switch back to Godot 3.5 - almost everything I'm doing is in-code, and thus won't be horribly effected by the shift to 4 should I choose to do so later.

[delphonso]

Ughh....

It's too late for me to explain the code.

Come...closer...

I need to tell ya something....



I fuckin' did it.

Feast your eyes

(left click to select the migrant, right click to move it/send it to a resource. No migrant spawning, I've got to go to bed.)

[delphonso]

Jesus fucking Christ I accidentally closed this whole post...

Quick version:

Take the click, subtract it from the sprites, if within radius, you clicked sprite.



Select_node is slap-dash last night. flash_resources is good, and I'll try to do something similar with the other functions - probably something with signals that the ui can catch.



I used classes instead of groups this time, but I think I'll use both - probably classes for inter-unit interactions, but groups for player-input. Sprite radius is taken by this same line everywhere.



You can see it in the migrant as well. Most of the values are the same, except the "my_title" thing which is tossed back up to the UI.



Metals can only flash their resource, which I actually quite like - I'll make the text bigger, give it a background, and probably use .show() and .hide() instead of this.



Also the body-checker is rewritten to be a bit better, however there is still an issue with walking past resource nodes that are empty while you're on your way back to one that isn't. I put those in there intentionally on the map, but forgot to program them around it.



I skipped over a lot because I already wrote this once and FUCKED IT UP. Basically, the structure underneath everything is way better. Controls are their own node, allowing me to scrap them quickly and iterate. It also allows for swapping out to AI easy, and using different control schemes for camera and actual gameplay. Aside from the file-structure, I'm trying to keep everything as autonomous as possible.

-=-=-=-=-=-=-=-=-

I'm very excited by this project. Like, far more than any game I've worked on so far. I'm excited to make something for the DF community, and I'm excited to make a Starcraft-like. I find myself thinking about the code and how to improve it as well as keep it flexible to emulate things from Starcraft (special scenarios, etc.)

Here's what I'm thinking of as my goals:

Task 1:
Add a command center and resource node.
= Builder units collect resource when directed to a resource node.
= Builder units path back to nearest command center from resource node.
= Command center can make more builder units. Ensure units do not spawn on top of each other.

Almost done! Will probably finish tonight.


Task 2:

Create a template building, builder unit, template barracks and combat unit.
= buildings are simply a button (perhaps even without a UI) that produces a unit. Ensure units do not spawn on top of each other.
= Click a unit to assign it a building task. Unit paths to the building location and builds it. Unit moves out of the building to avoid hiding/clipping.
= Place buildings on a grid of some sort, to ensure no overlaps.
= Click a unit to direct it to move somewhere.
= Click and drag to select multiple units, and direct them all to move somewhere.

Task 3:

Structure building and unit upgrade tiers.
= Make a template building, make a template research station, make a template barracks.
= The research station can not be built without a building and a barracks.
= The barracks only produces one type of unit, unless the research station is present, then it can make two types.
= The research station can upgrade the stats of all units on the field.

I think when I've done these 3, I'm on to the content-creation side. Making the factions (two just to start with), and the units each faction can have, as well as their upgrade tree. Maybe when those 3 are done, I'll make a separate thread - if I feel there's enough of a game for it. Hopefully this is something that actually looks done and is commercial quality in a year or so.

-=-=-=-=-=-=-=-=-=-=-

Compared to the fishing game - which is a game I want to make because I have an itch that is not scratched, this feels much different - this feels like something I'm making as a gift, and that has been a different experience entirely.

[King Zultan]

That newest version to download worked for me, but I wasn't able to play in browser.


I'm liking it so far and your plans for the future sound really cool even if I'm not that into RTS games it still sounds like something I'll play.

[delphonso]

Try it now!

Task 1 is complete, I'd say!

Bugs:
Controls are fucked, because of parenting - alas, I'll fix it next time. If you can't click something, move the camera to the top-left.
Spawning multiple units spawns them in a stack on top of each other. Clicking them and giving them orders makes them fly off into outer space.
Units do not pathfind. Good luck out there with your mosh pit outside the command center.


Write up...tomorrow, maybe? I need to get more than 5 hours of sleep a night.

[delphonso]

Alright, so here's where I'm at:

I'm quite satisfied with what I ended up with in really, 3 nights of work, one of those nights completely redoing what I did the other night. It's buggy and looks like shit, which is my aesthetic. I'm also fully willing to delete this completely and start from scratch for Task 2. Before getting into that, let's talk about the additions to the code since last time.



Instead of immediately instancing the controller, we instance a new scene which is just the camera. I'm separating the camera and controls so that one could spectate 2 AIs fighting without needing a whole new control scheme. Here's the issue, though - since the controller also has the GUI, the controller needs to be the child of the camera. For some reason, this completely fucks controls.



Controller is added as a child to the camera, and the controls are simple - pressing WASD or the Arrows puts you 20 pixels in that direction. Because the camera's location is technically the top left corner, there movement math seems off - it's possible to go 20 pixels outside the world map (2048x1200), so we just subtract 20 from the width limit.

As for the controller bug - I think it's probably related to how the camera operates. I wouldn't be surprised if the camera doesn't move, but everything on the map moves instead - meaning the coordinate system is a bit borked and will need a rewrite. But hey! That's why I added camera controls anyway - to see if there's anything that needs tweaking. You can see that if you click the command center, for instance, then move the camera over to the right, if you don't move your mouse, or move it to the same spot, you can click the command center despite it not being there. It's storing the coordinates based on the window, not on the map itself. I'll fix it.



The command center gets a new function to spawn a migrant. I spent well over an hour trying to get a method for testing if anyone is already there. I'll watch a video on how other people do it, or check the source code for 0AD (an open source RTS that is a ready resource). It's really only an issue because two units in the same place will go into superposition and be unable to do anything because their positions are not where they appear to be.

I find it quite satisfying to see the little guys walk back and forth, and to see the metals number go up, but there's still a lot of work to do!

Such as:

Task 2:

Create a template building, builder unit, template barracks and combat unit.
= buildings are simply a button that produces a unit. Ensure units do not spawn on top of each other. [1]
= Click a unit to assign it a building task. Unit paths to the building location and builds it. Unit moves out of the building to avoid hiding/clipping.
= Place buildings on a grid of some sort, to ensure no overlaps. [2]
= Click a unit to direct it to move somewhere.
= Click and drag to select multiple units, and direct them all to move somewhere.

Issue [1]:

I still am not sure of a good way to do this. I'll need to think on it a bit to formulate a good solution - every RTS manages it, so it can't be that hard. A cheap way is to spawn them at the mouth of the building, then send them to path to a point nearby, which would push other units out of the way. Speaking of which, I'll also take another crack at pathing for the pawns this time.

The good thing is, if I can solve this, the second subtask can probably use the same process as well as the grid.


Issue [2]:

The grid is an interesting challenge. I think it's actually quite easy - just give a parameter of say 64x64 and snap the sprites to that grid. If I do that and make the buildings smaller, they couldn't possibly overlap - though it'd be good to do half-stages like Starcraft does and detect where a collision might occur. I may also be able to do some pathfinding with the grid.

Keep in mind the grid will have to be done programmatically, because tilemaps are fully different in Godot 4 - and if I ever want to move up an engine, I can't rely on them. I might do a bit of programming tonight! We'll see!