A downloadable game for Windows, macOS, and Linux

A first person shooter created by Cadoink and KillerX. Battle to the objective on the same map multiple times, except each time, something will go missing. There are a variety of weapons you can find across the map, and health packs if you take some damage.


Developed and tested on Windows 10. Please let us know if there are any issues with the Mac and Linux builds of the game.

Created for the Godot Wild Jam #31.

StatusPrototype
PlatformsWindows, macOS, Linux
Rating
Rated 5.0 out of 5 stars
(1 total ratings)
AuthorsDelpire, KillerX
GenreShooter
Made withGodot, Blender

Download

Download
AstrayDisciplineWindows.zip 85 MB
Download
attributions.zip 96 kB
Download
AstrayDisciplineLinuxPatched.zip 102 MB
Download
AstrayDisciplineMacOsPatched.zip 88 MB

Development log

Comments

Log in with itch.io to leave a comment.

Doesn't work properly on my Linux machine. First of all, the screen size is wrong. I'll attach a screen shot.

After I click the play button, the game crashes. Here's the crash log: https://pastebin.com/qt7cUqby

And here are the mono logs: https://pastebin.com/u91cBnd8

(+1)

Thanks for the information! Didn't have a linux box to test on and was just hoping it would work! Looks like our use of System.DateTime isn't supported on Linux (at least based on the exception).

Not sure yet about the screen size. Worked fine on Windows, I'll have to do a bit of research for Linux.

Thank you for at least giving it a shot! Not sure if I am allowed to upload a fix for our Linux build, I'll reply if I can fix it.

Deleted 3 years ago

Do you happen to know what your Linux Screen resolution is? The default of the game is 1024x600. The main menu was fine on a Window's box, and on a Ubuntu VM we tested on.

elektito - I have updated the Linux build if you are still interested in giving it a try. DateTime should be removed, and I added a fullscreen toggle and resolution selector on the main page you might be able to use to fix the screen size issue.

If that doesn't work, I probably won't be able to update again, and until I have a linux box, it'll be hard to test.

Thanks again for letting us know. Next jam, we'll try to be performant enough to run in HTML5. 😅

So I gave it another go. The menu screen is still as before and changing the resolution effect or ticking the full screen checkbox has not effect at all. My resolution is 1920x1080 and I use a rather fringe tiling window manager (StumpWM). I doubt that has anything to do with this though. To the game it should be as if it's running in a normal fullscreen size window with no borders and frill.

After clicking play, the game did not crash. So your fix is working. Unfortunately the game is unbearably slow for me (I estimate 0.5 fps, I kid you not!). Checking nvidia-smi, I don't see the game using the GPU at all (game process not listed, and no activity seen), although CPU usage is not too high either.

Well I'm at a loss. I just don't have a linux box to test on. I assume you aren't running in a VM right? It would run extremely slow in a VM without hardware passthrough.

Graphically, everything is low poly, and we only have a small number of simple shaders. Our big performance hit is a screw up I made in the collision shapes. I fixed a large number of them, which got both myself and my team mate back to a solid 60fps on Windows. This was all done before we submitted.

I have no idea why fullscreen nor resolution doesn't work at all on your Linux box. Even in Windows it was a pain to get working, but we have it working consistently.

Our biggest lessons learned is to start creating an HTML5 export early so that performance doesn't stop us from having a web build. I think more people would have tried the game. We're super proud of this project, and it runs great on our machines! 😅I'm sorry you won't get the opportunity to try it out.

Nah, I'm running on metal, no VM. I doubt this is something in your game code (like the collision shapes issue you mentioned). Like I said, for some reason there's no GPU usage at all, the game process isn't even mentioned in nvidia-smi. I had something similar to this when I had mistakenly deleted all 32-bit nvidia libraries and turned out everything in steam is 32 bit. But your executable is clearly 64 bit, and I've got that issue sorted out in any case.

Anyways, if there was anything I can test for you in Linux do throw me a message. I'll do my best to help. Otherwise, I hope you enjoy the jam as much as I am right now!

Thanks for the update and the offer. We had a great time with the jam! Pretty bummed to see how fickle it is on Linux (who knows what's going on with MacOS 😓). I just now got in contact with someone running Ubuntu on bare metal, and the game is working great for them, so that boosted my spirits a little bit. 

I have essentially no experience with Linux desktop, just a bit of server side stuff. The game is targeting GLES 3, so maybe your box doesn't have support for that? That could explain why its not hitting the hardware, though its kind of strange you weren't seeing much CPU usage either. Maybe there is some driver issue?  Regardless, it seems to work on Ubuntu as long as its marked as executable in the file properties, so there is at least some kind of Ubuntu support.

Thanks again for the back and forth. I appreciate the effort.

Got a suggestion, not related to my previous comments. The binary you're distributing for Linux is not stripped (i.e. has debug symbols and stuff). Running strip made the game executable 20 MiB smaller. I don't know if this is something you can ask Godot to do on its own or not (likely yes).

In Godot there is an option to export as debug or not. I unchecked this, but maybe there is another setting somewhere.