Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(4 edits) (+1)

Apologies for the delay in replying, but I have deliberately delayed my reply so that I can share some good news with you.

So, thank you very much for the enthusiastic feedback. Very much appreciated. I played the main StarCraft campaign quite a bit in the original release. I have to confess that that is one of the inspirations for Raiders Of The Alaments.

I have just uploaded Build 0005 of the game, which includes your suggestion to provide warnings about temperature effects.

On the menus front, please bear in mind that this is still a prototype. My long term objective is to improve the interface elements. For example, using icons for adding buildings, instead of the current building menu. Note that using right-click doesn't actually save you any clicks, it is just how some other folk do things.

The droid capacity of carrying one unit is deliberate (frankly I copied the concept from Surviving Mars). I have adjusted the amounts of resources needed for the buildings so things move along a little bit more quickly. Also, in future there will be other things going on at the same time, such as dealing with various creatures, neighbouring demon lords and so on, which will make the game feel more lively. This first round of prototyping is my first foray into making a game like this, so I wanted to use this phase to make a solid start with the basics: that is the building construction and operations plus the droid mechanics.

And yes, I will bring it back again to another Feedback Quest when I have the next version to share (which will be a more complete demo instead of a prototype). However, that could be quite a while...

Anyway, please have a look at the main game page and the devlog for build 0005, and I hope you have another go at playing the game.

Edit: Forgot to say, I had already made changes to the warehouse before I read your post, so that the droids don't get stuck as much. They mostly only get stuck now when the time is running at 2x or 4x. In most cases, you can fix it by going back to 1x speed briefly. It that doesn't work, it is necessary to try somthing else, as you have been doing. The warehouses have more room, but need redoing so the droids have even more room to manoeuver around each other. Droid movement is also dependent on the navigation sub-system in the Godot engine itself, so things should also improve when there is some dev effort in that direction.

I'm very happy to hear all of this! Since you plan to keep the droid carrying capacity to one, I do think having some lower requirements on buildings will work in their place. I'm gonna grab a copy of the new prototype and give it a whirl right now! :D

I will note, I have been trying to think of other things that could help alleviate this problem of droids getting stuck. I do have one idea, but I'm not sure it would go with your intended design.

My suggestion would be that the starting warehouses are all one huge warehouse with four entrances on one side and four exits on the other. When a droid is making the journey back to the warehouse to either deliver or pick up a material, once it's a set distance away from the warehouse it will be assigned to whatever entrance door has gone the longest without being assigned (with the first times being down the line of doors). Since the droids would always be going straight through, they technically should never have a singular jam (which I have seen happen usually when they're trying to exit. I even saw this in the new prototype at speed x1 D: ). Meanwhile, by assigning the door once it hits a specific range, it should ensure that no two droids will reach the same door at the same time since if two droids hit that range about the same time, they should be assigned different doors (mind you, I do realize it's possible, though likely very rare, that two droids could hit the range at the exact same time. I think the solution there would be to randomly select which one to set first). Now if any jams happen, it should be outside of the warehouse by these doors rather than inside.

I'm not as familiar with the Godot engine as I'd like to be, so you'd be the one who could tell me if all of this was doable.

If you need anymore input/feedback or even want help testing, feel free to hit me up. I'll link both Twitter and Facebook pages for you (since it may take me longer to notice stuff on itch).

https://twitter.com/hythrain

https://www.facebook.com/hythraingame

(+1)

Thanks for trying the game again.

I wasn't going to update the prototype again, but I had a sudden inspiration on how to mitigate the droids getting stuck in the warehouses, and I think this is now solved.

Build 0006 is now uploaded with the "stuck droids" fix, if you feel like giving it a go yet again.

The problem was that the Navigation system was sometimes sending a droid the "wrong way" through the warehouse as a way of avoiding droids coming the other way. If a droid was already moving in the correct direction through the warehouse, they would bump into each other and get stuck. I have simply placed an invisible object so as to make the inside of the warehouse less attractive (to the Navigation system) as an avoidance route. I tested it by using all 8 droids to build the same building at the same time, and none of them got stuck. There might be corner cases where they still get stuck, but this solution will do for the prototype.

As for droids colliding elsewhere, I am a hostage to the Godot devs. As they are all "agents" within the Nav system, they should not be bumping into each other like that. There is dev effort in this direction planned, so hopefully things should improve in future.

Thanks very much for the test/feedback offer. It will be a while before it happens, but I am very likely to take you up on that.

I also watched your uploaded stream of the game on YouTube. It was a very odd experience watching someone else play my game. But... it helped me understand your point about the menus and I have taken that on board for the future. I am not sure I will be able to do what you have suggested for everything, but I will give it a go where it makes sense. Creating this game is still very much a learning experience and it will be good to experiment with alternative ways of doing things.

I get this feeling that my own personal excitement for this is spilling into you and boosting you, so I'm gonna test this new build right now! :D

"I tested it by using all 8 droids to build the same building at the same time, and none of them got stuck"

I would recommend testing it with all the droids doing different things in different directions. This is usually what I've been doing when I get stuck droids. I also wonder if it's possible for them to catch on the wall when they're going in and out. I have noticed they tend to hug the wall rather tightly and catch a bit when going in. I remember seeing single droid jams in previous builds, and usually when these happen it's when the droid is trying to go out. I'm wondering if the walls inside the warehouse are causing these single jams?

Also, I just realized you made it that the middle mouse button can be used to turn the camera for different angles. Can I recommend adding this to Q and E as well, where Q moves the camera around its pivot to the right (thus turning left) while E is the opposite?

(+1)

So, as I said, I am a hostage to the nav system in Godot for further droid behaviour improvements. And yes, I am aware of them bumping into walls etc, and they do sometimes getting temporarily stuck. Just have to live with it for now.

Yes, Q and E sounds sensible for left/right camera rotation. Unfortunately, this is not as slick as using the mouse, as for some reason doing this recognises the key press delay from the OS (I have tried it in my two other games that are on itch). However, I have now stopped work on the prototype, and already started on refactoring and adding new/different functionality for a proper demo version. It will take a long time before the first build of that is ready. As well as adding missing functionality, I will also be radically changing the UI/UX functionality - I have thought about that quite a bit since your first bit of feedback and I think I know where I want to go with it now.

Thanks for all the useful feedback. This is what I was hoping for when I joined this jam.