Play game
Raiders Of The Alaments (Prototype)'s itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Overall Fun | #33 | 1.746 | 2.667 |
| UI | #34 | 1.528 | 2.333 |
| Sound/Music | #36 | 1.964 | 3.000 |
| Art | #37 | 1.746 | 2.667 |
Ranked from 3 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
Leave a comment
Log in with itch.io to leave a comment.
Comments
Hello! I was one of the streamers who took part in Feedback Quest, and I'm here to leave some comments I had while playing.
When I started this game, I was excited. It reminded me of Starcraft, though it seemed like it would only be about collecting and building rather than fighting. Then as I looked more, I did see there were aspects of needing to defend your base. I don't mind this idea. However, during my attempts to play the game I felt very frustrated at certain things.
To start, I constantly had issues of droids getting stuck. This sometimes happened in the field, but more often it happened in the warehouse. I would have to manually recall the droids one by one and hope they free themselves to keep playing. This is an issue that REALLY needs to get fixed, because in my opinion it makes the game unplayable. My top suggestion would be to make it that droids have no collision with other droids and instead can move through them.
I also felt it was awkward to use full menus to control units instead of a system of being able to select a unit and then right click on something to order the unit to do something with that thing. I would recommend looking at games like Starcraft for ideas on control, because you can easily change that big menu to be a set of buttons with icons that indicate different tasks.
Gathering and building felt very slow due to how little a droid can take at a time. In my opinion, only gathering should be slow. Droids should be able to pick up multiple items during building.
I also could not figure out the importance of temperature. If temperature has a big impact, then either there needs to be something told to the player at the start for what temperature does or there should be a big warning when dangerous temperatures hit that advise the player on what to do.
This is the #1 title in the event that I'm excited for. I do hope you'll make changes and fixes and bring it to a future Feedback Quest.
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
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?
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.
Nice prototype, it shows quite a lot of promise! I wasn't able to build a geothermal power plant, the frame was on top of the droid building and I couldn't assign a droid or decommission the building. For some reason, after setting the game to fullscreen, when I add a profile the game reverts to windowed mode.
I found the droid building menu very useful to control my individual droids (harvest, explore), but I wonder how tedious it could be when there are a lot of droids to control. The ability to select several units from the list to give them an action could be useful.
Awesome work, keep at it! 😁
Thanks for giving it a go. It is steadily getting there. I have an update in progress that has greatly improved building placement. Once that is available (on itch) I will also do a demo vid on YouTube. However, I want to get the save/load game functionality done first, as that will also help with testing the game.
As I pointed out in the description (on the game page), a lot of buttons do nothing at the moment. Decommission is one of them, as it will need the corresponding additions to the droid state machine. After placing a building, all you need to do is use the building menu to assign an idle droid to build it, or use a droid menu and assign it to Build instead of doing something else.
I am also dependent on further development of the Godot Engine itself (I do not have the experience to help with this, unfortunately). Once the droids start doing something, the behaviour can go wonky because the navigation server still needs a lot of dev effort to improve the behaviour of navigation agents (the droids in this case).
I totally agree that assigning multiple units to a task will be a good thing to implement, but that is a long way down the list of things that the game needs... However, using the droid barracks menu for multiple unit selection is a great idea. I hadn't considered doing it that way. Getting good feedback like this is why I joined this jam!
By the way, to make Full Screen stick: make sure you have a profile created, then after choosing Full Screen, you need click Save Changes to save your preferences. Maybe I should disable the preferences until at least one profile is created.