Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

First, the project I'm working on is made in Godot and it been a really long time since I worked with GDScript. (Required with Godot 4 to make a WebGL build)

I'm finished with all of the behind-the-screen logic as well as the main menu & the general visual design on the GUI side, but have yet to work on the core gameplay loop.

The game has 100% functioning saving/loading  for both settings & player profiles menus, proper memory allocation & scene transition management, advanced graphics settings and some other stuff. (Also, the musics and use interface SFX are implemented.)

While my project is 3D, it has a retro feel to it because its settings is about space exploration in a similar style to the NASA Apollo program during the late 60's, but with a twist to it. There's a huge emphasis on its User Interactive graphics (GUI) as it's a game about resource and risks management, but at the same time it's a relatively simple game, gameplay-wise.

I'm planning on taking 2 days for the main gameplay loop and around 1 days for making the 3D assets still not done.

From the sound of it you've spent a lot of effort in the systems.  I'm only just working on my player state controller, still loads to do, today has had a bit more procrastination than I'd of liked, some of it unexpected, but if I can spend about 4 to 5 hours a day on it for the rest of the jam I should be OK, the 2D graphics I've made won't be anything special, there might not be a lot of "polish" in the end but my core objective is try and get a decent amount of story into the game this time.  New for me, but we'll see by the end if it works ...

The game I'm making for this Jam isn't a brand new idea, but it's based on one that I have previously though about for a past DevJam that I couldn't complete because, back then, I had barely 2.5 days of free time out of the 10~ish days. For this one, I had the 3 first days during which I couldn't put as much time (if at all) as I wanted, but that leave the remaining 7 fully open. Also, the idea/concept have evolved within the months since I originally had it with more realistic & realizable goals than what I originally had.

It's just that the theme of this jam coincidentally fit way too well with that old idea/concept I had to let it go while said idea doesn't really fit well for a commercial game in today's market or, at least, not the "Lite" version that I'm working on for the Jam.

The game I'm working on as a "Lite" version for the Jam is played primarily via 2 menus: 1 menu where you upgrade a machine and one menu where you have limited time to order the machine to do something after which it will attempt to do what you ordered with a day & night cycle. Depending on the machine's successes and failure, you acquire funds which allows you to upgrade the machine further to survive longer and so on and forth.

Basically, the game I'm working on is something akin to a NASA Rover simulator on a unknown planet. You have a limited window, each day, to give orders to the rover to move around and collect samples or discover new things (which gives you credits for upgrading the next one once this one breaks down). It's basically RTS walking simulator where your goal is to find hidden treasures while you slowly die as you move around with randomized events that, for the most part, goes against you (with a really few exceptions).

Each play-through is done on a randomized 512x512 sized micro-sectors board and the rover can only travel a limited amount of sectors per day on top of actually requiring you to give it order to do something (unless a certain upgrade is added) to interact with things. For example, if you give it an order to travel in a relatively straight line as far as it can within a day, it will damage itself over the distance (its wheels durability drops down) and while it might discover something along the way, you'll only find out about it the next day during the limited-timed "input action" phase and you might have to ask it to move back on its tracks to the discovery to actually analyze it. Hence, the gameplay loop is about choices & results of those choices versus the risks of actions or even inaction. 

I am doing this like a guerilla fighter... after reading your post, I just realized i don't even allow save/load... and this morning I just realized my player is taking damages but it has no game over mechanism even at 100% damage LOL. But i am enjoying every moment of this process, guess this is the charm of a game jam :)

(1 edit)

Small Update - I just finished the introduction (which includes a Tutorial).

Yes, I know... I'm kinda shooting myself in the foot with by adding a freaking tutorial to a DevJam that last only 10 days, but the gameplay is so much straight forward that it's going relatively smoothly... except that for some reason I hit myself against some insanely stupid problems along the way as I find tiny little systematic problems that seems so small and insignificant and, yet, I put hours in fixing those.

And, ironically, many of those tiny problems comes from the game engine I selected: Godot.

For example, when you start a new game in this project of mine, you get a relatively small introduction which ask for the player's name. Obviously, it doesn't have to be the actual player's name (it's simply the save profile's name and I also use that name in a few spots here and there and communicating with the player.) Well, at a first glance, you would think that it's really easy to do: add a LineEdit node (text entry field in Godot) in the 2D scene (2D menu in Godot) and read whatever the player enter in that LineEdit node...

But here's the kicker: Godot has barely ANY implemented method of restricting what the player enter in the LineEdit's field. For example, a player could enter a name like " " or "    " or "_ _ | _ _". Yeah. Those are underscores and spaces. You can restrict what's typed with a RegEx search for special characters, but what if I want to allow space between letters (never at the front or at the end of the name)? I can check the name characters as it's typed in, but what if it's copy/pasted?

And that's only one of the many tiny problems I have found myself tackling.

Ho... Also, just because I can and because I just love hitting my head against a wall... I also added... localization to my project because why the heck not? My project can be played in English and French (my native language).

As I take a break now and then on this project, I'm constantly wondering: Am I really working on a DevJam or am I not?

The good news about all those tiny problems that I'm facing and overcoming is that the solution I make will work universally with any other project made in GDScript Godot so it's not like I'm wasting my time. I have extended (written over) a dozen of nodes types (type of in-scene assets) to work better with various tiny bits of behavioral patterns I'm hitting myself against.

The one thing that I know I won't have time to do is adding full controller support. While I did instinctively implement controller support in the menus, I haven't gotten into implementing it in the actual gameplay loop and I know I won't have enough time for that within the next 3~ish days. Controller support is a pain to implement in most forms of RTS anyway (especially from scratch).

I also decided to not work on any sort of advanced beautification of the UI/Menus.

What I mean by beautification? Well, that's things that has 0 impacts on actual gameplay, but look nice. For example, it can be the transition between menu or having the menu have a really short animation as it opens and stuff like that. Right now, the menus goes "poof! open-sesame" instantly and I'm keeping it that way because setting up the menu in Godot to allow animations in the UI would be just a pain in such a rushing time.

LOL I kinda feel the same, I started an on screen overlay tutorial... then it introduced new bugs into my already playable game... spent another hour then end up stripping it down to just text tutorial guide... I don't have time to work on more as I have to work tomorrow... but just like you... i was like why don't i put in french... as I am in Canada and it is one of the official language which I am still learning ... Anyway, half way through it... realized french keyboard is different ... LOL I already had enough issue dealing with navigation on both desktop/mobile controls for my game so I gave up that too... looks like you have achieved all that I wanted to do! 

I see your game is a Windows game. Would you be able to work on a web version so we can try? 

Thanks ^_^

(1 edit)

Ok, it clear that I won't make it for the 5PM deadline today. Just to make it clear, I was working on the project to be released on WebGL/HTML5 (which is also one of the reason why I hit my head against a wall many times because I'm not really fond of GDScript in Godot 4 compared to C#.)

Long story short, everything was fine... until I started dabbling into the deeper stuff.

First, the project was named "HELLO-NEW-WORLD" which is a mix of of a play of words with the "Hello World!" program and the fact that the player's role is to control a remotely-controlled machine (a ROVER) on a unknown world. The player's whole "connection" with the planet is through the ROVER feedback.

For example: Main Menu and settings :

By the way, that planet & moon in the background are animated (rotations with winds & clouds & dust moving around it) 


Works 100% fine! Musics & Sounds works great!
For the music, I have soundtracks from a group that I have purchased licenses from that sounds like a simplified version of the Interstellar (one of my favorite movies of all time) movie's soundtrack.

The story... all done! Simple story where the player is introduced to the game's settings via message (like below) and has a tiny bit of humor. 


And this is where things crumbled down HARD.


Long story short, the menu is divided into 3 lanes.
Lane 1 (left) is where you select parts of the rover you want to change.
Lane 2 (middle) is where you select either a permanent upgrade or a part to insert in one of the available slots of the rover.
Lane 3 (Right) is where you see the result of the selected part as well as a (kinda) preview of what the part (or upgrade) looks like.

The game has 8 primary stats and 3 secondary stats.
The game loop works fine, but I couldn't work on the implementation of the stats to affect the parts of that loop.
(Things were too fine for a while and I should have stick to a non-stats-based gameplay and instead expends on the gameplay loop.)

With all the work I have put in the that menu above, the main game (controlling the rover) is bare-bone and the environment is incomplete (which lacks in objectives and obstacles).

Even if I have failed to finish for the DevJam, I got to say that there's some really nice things in this so I'm not throwing it in the garbage. There's a crap ton of stuff that I would actually want to put into this game (with more time needed obviously). For example, I did a really quick job with the 3D models for the rover's instance. You don't see it on the screenshot above (it only show 2 parts), but I made 24 possible parts (all of those things in the middle that aren't permanent have their 3D part instance when installed). I didn't had time to put proper animation into it at all (like robot arms and lights & blinking things, etc.) I would also prefer if I could make the part adapt better to the ROVER's body (instead of being square like above). Thinks like actual links/wires/connections between the rover's parts and such.

Also, I would most likely burn that menu above and rebuild it from scratch (for a 4th time), but this time, I would put the menu in better "layers" with something like a separate tab for the upgrades, a proper dedicated ROVER customized menu and a pre-mission launch menu (which, right now, there's NONE! you press _LAUNCH and you're thrown on the planet immediatly)

Also, that Tutorial... well, I couldn't finish it because that freaking hellish menu above couldn't work properly due something I coded to avoid certain issues... which ended up creating their own issues (basically erasing the purchase and part installation, without refunding the funds wasted.)

I hope you had more success than me. :P

What sort of display were you planning for the rover interface?  For the jam, you could have cut the upgrade system for working on the rover interface to allow for a game loop of sorts and then added the upgrade system later if there was time???

From the screenshots you posted, it looks really nice, I am definitely interested in looking at it when you finish it.  I imagine you had planned some kind of resource analysis, gathering and management to lock the rover customisation behind game the gameplay of exploring the planet(s) with a rover?

It's a shame you didn't pull it together in time, but if my imagination us accurate with what you have already been making it sounds like the kind of game I'd enjoy.

My full idea for this project (outside of the Jam) would be similarly to the "jobs simulator" you see around where you do a number of task each day and you get the result by the next (in-game) day.

The game loop for the jam was "kinda" done in a beta-early-sense, but it only felt like a chore to do, not like a game at all. Basically, you have a limited amount of time (with a timer) to look at what the ROVER has detected on a 2.5D map and you give "task" like "move there", "scan that", etc. The map is randomized in elevations and hidden discovery. (It's a 3D map, but displayed in a isometric view.)

The stats you see in the menu are relative to what the rover can do: how fast it moves, how long, if it recharge during the night, how long it takes to scan anything, how far it can find anything, etc.

The upgrade system is kinda required to make it so that doing it more than once gets more fun. Each discovery gives some budget and that budget can be invested in upgrades which makes the next run with more potential. (In other words, it's ultimately a Rogue-Lite.)

I think one potential good way of changing the project will be to make the UI less "concentrated" and more "Tab-based". For example, it could be a fake-like PC desktop when the player interact with the software "installed" on it. This would allow additional elements like conversation with management (of the in-game company who hire the player), access to past logs, better data caching and management between the menus (instead of trying to run everything at once), etc.

Then, for the gameplay loop, instead of a 2.5D map, I would actually prefer to generate an actual "story" with the actual rover. Being able to replay the "previous" day live with something like a time lapse setup like if you watch a video, but with actual access to everything the rover actually has: a view of each camera installed, radar/satellite scans and more potential tools (like seismic charges, X-Rays, etc.).

For example, even if the tool onboard the rover doesn't find something to put a pin on, maybe the camera caught something that a player can notice. (The replay system wouldn't actually save footage data or anything, but would use a mix of seed-generated environment mixed with actual forth and backward calculations with timestamp-like nodes and events.)

I would also think of expending the shopping experience in a different direction. Instead of unlocking stuff and buying it at a fixed price, something like having multiple brands and sellers offering different prices for different quality of items.

And then, the way to "loose" a rover would be better defined. In the jam, I was looking at cheating a bit and making the battery consumption slightly above what can be regenerated. Your rover gets disconnected if less than 2 wheels and/or tracks remains or if the battery hits 0.

I think that the battery is important, but that it should only be a "game's done" if it lacks ANY rechargeable features and, as such, the durability should play a much bigger role. Component gets damages by X or Y reason and battery can break down, solar panels gets easily damaged by certain type of environment (or weather event) and wheels gets damages as it rolls around. So even if the battery is drained, that rover shouldn't be "done with", but instead should simply "stay put" while other potential source of data keep recording if applicable. (For example, you may buy and deploy a satellite and while the rover is "offline", the satellite keeps recording, or at least, you can access the satellite view of things during a limited coverage time.)

Then I would see that the rover customization and simulation would be more advanced. For example, various "scanning" and "analyzing" methods and tools (which can also break down). If you don't bring the right tool, even if you find the "hidden" resources, you can't gain anything from it.

And another thing I think I would add is multiple "life" (or rovers). For example, being able to send multiple rovers at once and when one's down, you can deploy another and so on. (There could be option on the deployed satellite to add more rovers) Only once all rovers are down that you move on onto the next "mission".

And lastly (and really important if I push this onto the serious board), dynamic planet biomes is a must. For the JAM, I limited myself to a Mars-like environment, but I would like to see something with lots of different biome: sand, water, volcanic and even vegetation. Not to an extreme like No Man Sky (with creatures and lots of generated stuff), but at least having weather, temperature-related behavior (ice, vapor) and ground-related dynamism (like water, lava and mud). Having things like snowstorms, sandstorms, rain, eruption and even tsunamis would be really cool (especially if you can move forward and backward during the event. You could see the "end" coming to the Rover before communication is cut.)

That's a rather big idea, lots of different and complex elements, if you manage to build it all.

Sounds like the focus would be more on the "job" as you say, more on the player conducting the role, than the behaviour of the Rover, not played many games like that, but could be an interesting experience so long as the learning curve for a new player is appropriately managed.

Good luck.

Wow Wow Wow... that's a whole lot of stuff you want. Sounds like something fit for an AAA game though.

I think it does have something as an interesting base. What you can do though if you want is to feed these ideas to AI and ask it to tone it done (giving it the amount of time you want this game to be live) and ask it what stuff you should do to get the bare minimum and still entertaining (if it is not entertaining, it is not a game right?)... but importantly ask it to give you ideas on now to design such that the foundation you build for the game jam provide sockets for you to plug in new features/functionalities later.  I think AI will be very good with this in terms of limiting your scope of development.

But man, that design is dope. I think thought the one where you goes crushing down (that complex UI part) perhaps there is a gem hidden there that need extreme creativity to reduce all that into simple /intuitive game play experience.