itch.io

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.)

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

The one thing that feels strange to me would be how you let the player controls the camera angle.

It feels a bit strange how holding the right mouse button (while the mouse or not) basically pause the block's movement in the meanwhile.

Personally, I would have set it with 3 means:

• On-screen buttons to quickly turn the camera 45 or 90 degrees (since the game controls involves the mouse).
• Keys/Buttons (like for a Controller) to quickly turn the camera 45 or 90 degrees.
• Instead of rotating the camera "smoothly" while holding the right mouse button (and pausing the block from going down) over time, I think it would be better to add some stickiness to it. Something like holding the right mouse and moving the mouse left or right a certain distance for the game to, only then, rotate 45 or 90 degrees.

And while the camera rotate automatically (which should only last a sec), I would set the block movement to pause (like it's currently doing when you holding the right mouse button).

Otherwise, I feel like the controls are alright.

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.

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. 

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.

The problem in using AI often comes from the social cognition of what's AI-generated (meaning it's constantly shifting & morphing as time move on).

On one side, you'll find individuals who make a living (or want to make a living) as well as purists who want to maintain a certain level of professionalism and, on the other, you'll find those who mostly benefits from it. It's nothing new in terms of principle of conflicts. For example, did you know that Photoshop on its own has cut around 22 full time jobs in the printing and design industry that were prominent in the early 80's into a single job the may even be part time? Do you see, today, people who complain about Photoshop having taken down all those jobs?

Kinda like how, today, quite a few individuals uses AI to generate content without the skills or knowledge to actually do something decent (hence it always seems wrong one way or another), you had that exact same principle back around 2000-2010 where the web took off and you would see people who (think they) know Photoshop and were calling themself professional graphic designer publicly when they can't even do 1/10 of the actual job. (I'll always remember when I, as a certified graphic designer, had to work with someone who promoted himself as a professional graphic designer, but yet didn't knew anything about DPI, PPI, CMYK or Pantones and yet he had to produce something to be printed in 2 colors at a press and was completely lost.)

The problem isn't about just using AI or not, but about if you can actually use AI properly or not. Today at least, if you use 99.99% of whatever an AI regurgitate from your prompt as-is, you're not using AI properly and, hence, you'll most likely be hit by whatever you have missed or didn't do properly way harder than anything else.

Take for example any games that made use of AI that was hit hard for it. What made people complain about the use of AI? It wasn't the fact that AI was used, but the fact that there was clear garbage left from when an AI was used and someone didn't do his/her job at cleaning things up. Even more when you're charged almost a hundred dollar for the product, that's as bad.

If you think that you can controls & correct whatever AI regurgitates at you in the few days available for a DevJam, go for it! It's only a tool after all. But like if you were to make typos (written mistakes) any mistake made by the AI that aren't fixed will be like a slap in the face of whoever tries your game later and that will bite you back way more than if you were, from the start, doing something that is clearly coming 100% from you.

In short, everyone who submit something an actual game receive 1 course on gamedev.tv of their choice for free.

There's no prize for the top or something, except the satisfaction of having made something popular.
Being part of the group (or having made something yourself) that made it to the top of this kind of open contest is also a great piece to add to a CV/Portfolio if you wish to land a job in the video game industry.

For a while now, every year GameDev.tv has launched this DevJam/GameJam for a free course for all participants who submit an actual game.

They have many great courses for Unreal, Unity and even Godot for various things. Be it for learning how to use an engine or up to the advanced stuff like Multiplayer as well as gameplay-based courses (like how to make a RPG, a RTS, a FPS, etc.)

Considering that the GameJam has this rule :

Assets - Use only assets you have permission for (your own, free, or purchased). If you didn’t create it, you must list it in your submission;

Having things prepared in advance like potential animations, prefabs/systems, codes, basic setups, etc. isn't against the rule.

For those who don't know the term prefabs, it a word that means pre-fabrications and those are packages containing stuff already built which may include script, models, animations, collisions, etc. made for a specific game engine.

You simply have to consider if what you wish to prepare in advance comes into the spirit of a game jam or not. It's not like there's a Jam Police that will knock down your door because you prepared a few things in advance for the sake of making sure such things work once implemented into the actual Jam.

For example, nothing is wrong (especially for people who have never done it) with creating a project earlier to implement basic functionalities like a working settings menu and testing out if you're actually able to export and run the project as something like an HTML5 web project.

This is a gray area in the world of Game Jams that are remotely managed.

The only Dev Jams that have actual limitation with what you can start with are the Jams that require you to be physically in a specific place by providing the PCs, software, space, food, etc. to work on the Jam as it runs. Basically, in those Jams, everyone uses the same tools (PCs + software), have the same environment and more. This is simply impossible to manage with remotely managed Jams because, for example, I might have access to software you don't and can't access to anymore and the one next might have a Desktop PC with 3 screens that can do things a LOT faster and efficiently than the other next one who work from a 4 years old gaming laptop that starts to show its age.

I guess you're writing about the Android build which is obviously a tiny fraction of the other build in size. To explain it in an easy way, a common practice of Android games is to release, initially, a launcher and then download the latest version of the assets. This is mostly due to Google's policy when handling game on the Google Play as Google handle games larger than 125MB differently than games smaller (but it doesn't count post-download size). Larger games are all packed in a single list while the rest is shown in the genres properly. Considering the low visibility of 99.99% of the games on the Google Play store, the last thing any publisher want is their game to also be tied to a single less desirable list.

Even if the APK on ichi isn't restricted like Google, making a version that has everything from the get-go would mean building a different version of the game just for ichi and that's a waste of time.

Thanks GameDev.tv for making this possible for another year contest as it's my favorite JAM.

I have participated for the last 2 years and even if my entries were scored low, I never felt bad about it as, in this jam, everyone is a winner.

The 2 previous years, I submitted a project using Unity, but this year I'm going with Godot. Not that I have anything against using Unity, but as I have been working on a (relatively) big project with Godot for since November of last year, I'm quite warmed up for it. 

For those who might wonder, the reason why I moved to Godot for that project of mine has nothing to do with what happened with Unity during their new license PR fiasco last year even if the timing might seems related (it's not). It's something I had to decide as a part of Unity EULA that has existed for years might not be favorable for this project of mine which uses a business model that kinda exists, but not in the form that I'm giving it. I even attempted to contact Unity Tech. to see if there could be something done and they ignored me. So I decided to play it safe and move to Godot for the sake of this particular project. I couldn't stick this project with Unity's or even Unreal EULAs considering it's a project that, if it succeed, could change a part of the face of the financial aspect of video game development, as a commercial enterprise.

So, for this JAM, I'll be using Godot 4 this year.
I got a few ideas of what kind of gameplay I'll be making for the Jam (depending on the theme once it's revealed).
Due to my part time job at a busy general store, I'll be only working on this ~3 days worth out of the 27, 28, 29 and 31 of May so it gonna be short and intense.

Remember that the UE editor itself is around 15GB which is mostly libraries for various elements inside a game like audio libraries and shader/render libraries. When you build your game, the assets inside your project folder don't includes what's required to run a game and the UE engine has to includes everything required for your game to run without the editor. It's normal that the engine folder is around 220MB by default and could be even bigger if you used some crazy tools in the editor. There's also the possibility that some of the assets which you see as only a few MB were converted into some form of RAW format and this result with files being 3x-4x the original's size.

Well, I got a good news and a bad news.

The good new is that I have made a lot of progress in my project for the jam and had a lot of fun working on it.

The bad news is that I couldn't finish the project in time. I'm at about 95% done, but I'm facing some really bad code incoherence from fixing the remaining 5%.

There are also minor some positioning issues for certain UI/Graphic elements to fix and I can't reach the point where the game is functioning properly as a game.

If I had 1 more day, I could probably finish everything, but not in the bit-more-than-1-hour remaining. Especially since I have not done any build debugging. (For all I know, I could be unable to build a client/game to submit even if I rush/finish everything.)

The main culprit of this bad news is, surprisingly not that I chew more than I could eat, but it came from an major issue with Unity 2020.2.X (especially present on the version I used 2022.2.16) live compiler being totally unreliable and slow as hell.

The issues I faced during the last 3 days with the Unity editor were, to say the least, abnormal and this never happened with any version from 2020.1 or prior. From the editor's UI not updating from selection (and, sometime, throwing an error of bad cache) to the point where the compiler would take 30+ seconds to compile the script in the project which is not even 3000 lines of codes (on a PC that has a LOT of computing power). To be able to work relatively fast, I had to litteraly close the Editor approx. every 2 hours, go into the project files and delete the content of the "Library" folder and reopen the project. After about 5 minutes or recompilation, the Editor works normally again by that point for about 1 to 2 hours and, then, slowly get slow.

Imagine if changing 1 line of code in your project was always took 30 secs before you could test it out. If you change a line 20 times, you just lost 10 minutes waiting and that doesn't includes the time you actually test the damn thing out.

At the moment, this give me the idea that Unity 2020.2.x is not properly optimized for using it in Dev Jams of such short length or, at least, not in my case.

Here's a final view of what the project looks like :

Will I finish the project? Most likely, but it will requires a lot of work to untangle all that spaghetti codes I have wrote for the sake of testing things fast.

Good luck to all the others!

Been working on the Jam's project for about 6 hours today.

It advance quite well, but as I watch time moving forward and what is done, I'm not 100% certain I'll be able to submit the project in time.

Side note: It's not visible in the screenshot, but that 3D map can be rotated around.

Long story short:
• I have implemented the path/movement system with waypoints as well as the keyboard & mouse and Touchscreen/Pen inputs based controls.
That was the bulk of today's work because I had to implement a waypoint system that allow new additional waypoints to be added and/or replace and/or removed while keeping the existing order of waypoints and all.

The way the controls work is that the player place waypoints put pressing/clicking on the world. Each time a press/click is done, a waypoint is added and the path between active waypoints is updated. If the player presses/click really close to an existing waypoint, this remove the waypoint from the path. The number of waypoints is based on a certain module (which can be ranked up) starting at 2 by default and up to 7 at max rank. If the number of generated waypoint exceed the module's capacity of the Rover, the oldest waypoint is removed.

This was a bit of a headhache to implement because I had to implement a system that allows not only connection between the existing waypoint and the Rover, once in the map, but also between the hidden objective (not visible in the image above) that has been discovered. (So, if a discovered objective is pressed/clicked, a it becomes a waypoint in the Rover path. If a regular existing waypoint is pressed, it's destroyed/removed. If an objective is pressed, it's only removed from the waypoint list, but remains on the map until it's acquired by the rover by reaching it.)

• I have also reworked a few visual elements as well as the visuals so that stuff are much easier to see.

• Only one 3D model remains which is the Landing craft (starting part for the Rover as well as a permanent charging station).

• The time factor has been fully implemented. The game run on a 24-hour time factor where sunlight is available between 06:00:00 up to around 20:00:00. During the night, while it's possible to move the Rover, the power consumption (unless upgraded and still) is a double edged sword. Between 11:00:00 and 13:00:00, the sun up high and there's barely any shadows. I did implement a bit of a cheat where the sun truly stays still for 2 hours, but at the cost of chipping the scale on the rest of the sun-lighted part of the day. It's possible to turn off the Time advance (nothing moves) by toggling off any of the 4 bottom buttons, but setting it at 1X(NORMAL) is actually more or less the same unless in extreme circumstances of last-call around the 19th hour. After all, at 1X(NORMAL), you control the Rover in real-time meaning that it will take a real-time 14 hours from 6h in the game to reach night time.

• 75% of the Rover system is finished. The 25% remaining is related to the landing craft and the sunlight/shadow detection and the inventory and scan system.

One things I have not yet implemented visually is the size of the map in real measures. Each cube/square you see on the map is 1 squared distance unit. I have yet to decide if it's 1 km² or 1 mile². The elevation also has an importance when deciding the Rover's path. Each square represent the average elevation of the area and that's another thing that can get upgraded because the higher the elevation, the slower the Rover will climb (and the opposite is also true where the Rover will move down hills faster.) It's not a linear deceleration, but more like a parabola, hence it might be faster to move around an hill on a smooth elevation than to climb an hard-pressed elevation, but at the same time, that smoother hill could be in the shadowed part, hence comes the dilemma of choosing which route to take, how fast it gets there.

Here a few details about the upgrade-based gameplay element about the Rover.

• Battery Capacity: The rover has a battery default capacity that allows it to cross shadowed area for 2 in-game hours before powering down.
It can be upgraded internally to 200% and it's possible to extend it by 30 minutes with Battery Cells (each take 1 slot in the Rover Inventory)

• Storage Capacity: The rover has a default Storage Capacity of 2 slot and can be upgraded to 7 slots total.

Currently, the slots can be filled with :
+ Sample (By default) - Each Sample objective requires a slot when transported back to the shuttle.
+ Battery Cell - Upgrade the Battery Capacity by a flat 25 units. (this represent 25% of the default Battery capacity)
+ Solar Panel - Upgrade the Battery Recharge speed by 3 units / hour under sunlight. That recharge rate is not affected by mobility (unlike Solar Cells).
+ Robot Arm - Double the acquisition speed of Samples. Acquiring a Sample, by default, takes 30-60 minutes. (The time is semi-random based on a few factors.) During Sample recovery, the Rover consume slightly more energy than usual, hence this part not only might allow 1-2 additional sample to be acquired in a day, it also save half of the energy its consumes.

• Solar Cells: When in sunlight, the rover recharges its batteries. By default it recharges at around 5% (if immobile) or 1% (if mobile) per in-game hour. This can be upgraded up to 200% which means that, in 10 hours (instead of 20) without moving, the Rover would be fully charged.

• Radar Antenna & CPU: (Not yet visible in the UI above) It's possible (and required) to launch a scan from the Rover position at the cost or power. The Radar has a recharge rate of 6 in-game hour, but can be reduced to 1 in-game hour by upgrading the Radar CPU. Just in case some wonder, it does recharge during night time so even at the start, you can launch 2 scans easily. Upgrading the Antenna raise the range of the scan. By default, the range is 5 units in radius around the Rover and can be doubled by adding upgrades.

• Motor Drive & Gears: This is the upgrades that allows to raise the max speed (Drive) as well as dropping the deceleration (Gears) when climbing an hill.

• AI Optimization: This allows the Rover to use less power in general. This drop the power usage of everything, hence it's an Ace-of-All-Trade, but even maxed, the gain is still lesser than something like a maxed Battery or even 2 Battery Cells.

All that might seem overkill for a Dev Jam of 3 days, but it's mostly internal data management with a few UI icon here and there which is why I think I'll be okay, but again something might not work as I intended so it's not 100% guarantied.

Really good work (especially in how fast you made it)!

I know I wrote that I wouldn't be giving updates, but I think that I have reached a nice look for the satellite-like look

At this moment, everything related to the map itself is done. The coordinates, elevations, location of the hidden things to discover and the Sun-based light simulation are all implemented. The screenshot above shows how the shadows appears. Currently, it's possible to generate a small, medium or large terrain map. (The one in the screenshot above is a medium sized terrain map).

The part that remains to be implemented (or finish) are 

• The Rover and its relevant features.

• The gameplay mechanisms.

• A game menu. (if time allows it, a save & loading system)

I looked at your code and made my own little version of it :

using UnityEngine;

using System.Collections;

public class Spawn : MonoBehaviour

{

    public static Spawn Instance;

    public GameObject objectToSpawn;

    public float spawnFrequency = 1f;

    public float spawnPadding = 0.1f;

    public int maxObjectsOnScreen = 5;

    private float nextSpawnTime = 0f;

    private int objectsOnScreen = 0;

    private float _Delta;

    private GameObject[] SpawnedObjects;

    private bool SpawningEnabled = false;

    private void Awake()

    {

        Spawn.Instance = this;

    }

    private void Start(){

        //Create an array for the Spawned Object cache that will hold all Spawned Objects references in the scene.

        SpawnedObjects = new GameObject[maxObjectsOnScreen];

        SpawningEnabled = true;

        StartSpawnEvent(spawnFrequency);

    }

    private void Update(){

        _Delta = Time.deltaTime;

    }

    private void StartSpawnEvent(float SpawnFrequency)

    {

        if(SpawnEvent!= null)

        {

            StopCoroutine(SpawnEvent);

            SpawnEvent = null;

            //By stopping & setting the existing Spawn Event reference to null, you clean any reference Cache.

            //This ensure that the garbage collector can clean anything from it.

        }

        SpawnEvent = SpawnCoroutine(SpawnFrequency);

        StartCoroutine(SpawnEvent);

    }

    private float SpawnTimer = 0f;

    private IEnumerator SpawnEvent;

    private int CurrentObjectCheck = 0;

    IEnumerator SpawnCoroutine(float SpawnFrequency)

    {

        SpawnTimer = SpawnFrequency;

        //This while() only  allow the Coroutine to run while the Object on screen is lesser than the max allowed.

        while (SpawningEnabled && objectsOnScreen < maxObjectsOnScreen)

        {

            SpawnTimer -= _Delta;

            if (SpawnTimer <= 0f)

            {

                //Spawn Timer is ringing. Spawn a new Object.

                for(CurrentObjectCheck = 0; CurrentObjectCheck < maxObjectsOnScreen; CurrentObjectCheck++)

                {

                    if (SpawnedObjects[CurrentObjectCheck] == null)

                    {

                        //An empty slot has been detected.

                        //This function will add the object and adjust the relevant quantities.

                        SpawnNewObject(CurrentObjectCheck);

                        //Break will stop the for() loop because you want the timer to restart before checking and spawning any other.

                        break;

                    }

                }

                //Reset the spawn timer back to the frequency.

                SpawnTimer = SpawnFrequency;

            }

            yield return null;

        }

    }

    //Small note: When you got a value that you will reuse often, but not simultanously in paralel, it's better to cache it.

    private Vector2 RandomViewPosition_Holder;

    private void SpawnNewObject(int ObjectID)

    {

        if (SpawnedObjects[ObjectID] != null)

        {

            //It's almost impossible that something remains in the reference since you just looked it up in the coroutine.

            //Still, just to be on the safe side, you don't want to leave any remains of lost data in the cache.

            Destroy(SpawnedObjects[ObjectID]);

            SpawnedObjects[ObjectID] = null;

        }

        RandomViewPosition_Holder = new Vector2(

            UnityEngine.Random.Range(Camera.main.ViewportToWorldPoint(Vector3.zero).x + spawnPadding, Camera.main.ViewportToWorldPoint(Vector3.right).x - spawnPadding),

            UnityEngine.Random.Range(Camera.main.ViewportToWorldPoint(Vector3.zero).y + spawnPadding, Camera.main.ViewportToWorldPoint(Vector3.up).y - spawnPadding));

        SpawnedObjects[ObjectID] = Instantiate(objectToSpawn, gameObject.transform);

        //From your code, I guess this is a 2D game, hence why you fill the world Y (elevation) with the view Y (height on screen) as, otherwise, it would have been different.

        SpawnedObjects[ObjectID].transform.position = new Vector3(RandomViewPosition_Holder.x, RandomViewPosition_Holder.y, 0f);

        //You can use the ++, but I prefer to use the += for the sake of clear definition. For example, if you were to spawn 2 object, you can just change += 1 to += 2 and so on;

        objectsOnScreen += 1;

    }

    public void DestroyTargetObject(GameObject targetToRemove) {

        foreach(GameObject obj in SpawnedObjects)

        {

            if(obj == targetToRemove)

            {

                //Object has been found in the Array of Spawned Objects

                Destroy(obj);

                objectsOnScreen -= 1;

                //You can set some kind of checker here if you want to limit the maximum number of object spawned in a match.

                //For example, cache an int and add to it here and once it reach a value (meaning X object got destroyed), the player won.

                //That's why I added the SpawningEnabled boolean as a condition for the spawn to occure in the coroutine. Setting it to false stop the object from respawning once destroyed.

                StartSpawnEvent(spawnFrequency);

            }

        }

    }

}

With that code, the spawning will only happen when it's possible. With that code, when an object is supposed to be destroyed/removed from the screen, you only have to call something like Spawn.Instance.DestroyTargetObject(this); or replace the "this" by the object reference if it's done from another object's script. As long as "this" refer to the SAME object as the one you instantiate, it will be destroyed, removed from the list and a new one will be created in its stead (unless, as noted, the SpawningEnabled bool value is set to false.)

With the theme and limitation, it took me quite a while to finally decide on what to do within the limited amount of time allocated to this Jam.

I initially had one idea about a game where you're controlling something like a creature that gets damaged/burned by the sunlight and you got to cross a field with spots of shadows around to reach your den. As it would burn, it would gain more speed and could cross the light faster. I thought it was a really interesting concept, but I ended up scrapping it for another idea because of the time restraints. Just the creature alone could take a week to make and animate if things don't go the way I want and I'm not even covering the field to cross. It can really be an insane time sink-hole. (But I do keep this idea for something outside of the Jam.)

Then, I went into a different way and decided to do something that is heavily UI-oriented project so that I can remove a LOT of requirement on the animation/3D side. From that came my final idea for the project that I will be submitting to the Jam which is called Deviation.

To make it short, Deviation is a game where you control a rover across a randomized map on some planet. Think of it as an arcade version of the Discovery on Mars. In terms of gameplay, it's more of an RTS game than an action/platform game because you set the inputs/controls first, then send the information to the rover which will execute them.

The trick/challenge is that the rover has a battery which drain as it time moves forward or as it uses its few "abilities". It recharge under the sunlight so you got to plan its path in consideration of the shadows and time of the day. If its battery is fully drain, you loose contact with the rover. That's my take on the Solar theme of the Jam where the Rover requires solar energy to recharge and be able to complete it commanded tasks.

It's kinda like the vehicle used by Watney (Matt Damon) in the movie The Martian to cross Mars, but unlike in that movie, there's no human to restart the machine once it's turned off.

To fulfill the limitation of Failure is Progress, I implemented the goal of the game being that you need to use the rover to scan for stuff on the planet's surface. Whenever you find something, there are 2 possibilities: 1 is a point of Data Collection which gives small but guarantied reward and the other is a Sample Collection which requires the rover to return to its starting point for a bigger reward.

By reward, I'm talking about Funds raising. It's a bit like the principle behind NASA's funding on a much simpler scale. The more you discover, the more funds you get to raise for the next time you send a rover on an expedition. The more funds you raise for the next expedition, the better equipment you can put on the rover.

This means that the game has an upgrade system with ranked stuff that enhance the rover capacity. From battery capacity, charging speed, radar range, etc. The rover also has a storage capacity which allows either the addition of modules (for a flat stats bonus) or, by default, a sample storage. This means that you can't just send the rover all around the samples points, but may have to plan multiple return trips if the rover's storage is limited.

This might sound complicated and extremely time consuming, but the trick for fitting within this Jam's time constraint is that the visual will be that of a satellite data image made of raised cube for displaying the relief of the planet surface. For this Jam at least, you won't exactly see the surface of the planet nor the rover itself. It's all UI-based on a limited 3D representation of the planet.

This will be my only post/update on my participation until the end in this Jam because... well let's just say that I will surely not have time to write updates. ;)

Yes. Prior to May 19th, you can do any pre-preparation you might need such as looking up for potential references, thinking about possible setup/design, etc. But you got to remember that the theme and, sometimes, the bonus theme/rules (gives bonus points) can go completely against your ideas, hence that's why you shouldn't get stuck with 1 great idea, but just some general brainstorming.

Think of it as the time used to practice by making a bunch of cakes or looking up recipes and techniques around prior to a cake contest. Knowing which tools you're need during the contest is kinda essential unless, like me, you go in blind (for an additive personal challenge).

A good list of example of stuff you can prepare ahead in this kind of Jam:

• A list of Public Domain (CC0) musics files OR musics you have, yourself, made. (No remixes or any derivative works that is too close to any existing copyrighted musics.)

• Pill up a bunch of animations files that could be useful. For example, you can download a bunch of animation from mixamo.

• Preset of stuff you have already build in concept such as codes or systems.
While some big Jam might refuse that you bring in your own pre-made codes, this kind of Jam allows you. It even gives you an example of what you can bring in with the package it gives for free that includes some basics for some games. If you got some codes that works for something you want to make during the Jam, nothing is stopping you from copy-pasting the code right away.

On May 19th, the theme and bonus theme/rule will be given.

From that point, you start working on the actual implementation of the game itself so that you can have a working client by the 29th.

Before the Jam close on the 29th, you'll have to publish a working client (.exe file) into itch.io. This allows you to submit the project to any active Jam you have joined. (It's all in the itch.io publish menu.) This Jam also requires that you share the build (project files) which it's highly recommended that you separate the 2 set of files in different .ZIP containers so that people can download just the game if they want.

This is also why you can't use copyrighted stuff in the JAM (unless you own the license for redistribution which, 99.9999% of the time means that you made it yourself.) Even free stuff online can be restricted on the redistribution of the work hence you got to look up for stuff specified with the CC0 mark (meaning it's on the public domain and free to use, re-use and redistribute or use in commercial works).

If you're uncertain if you can use certain assets in this JAM, just explain and ask the person who made the asset if it's alright to put the file in your project that will be distributed for free. If you got a positive answer, it's all OK. For example, someone might agree to the redistribution if credits are given. As such, you can include a PDF or .txt files containing the credits mentioning the requirement for the crediting in using the asset. (This is often the case on free content offered on the web. It's often called CC with Attribution. CC means Creative Common)

This is also why it can be a good thing to start looking and loading up a bunch of musics file ahead, unless you truly plan on making it yourself during the JAM or unless you already got a good source of CC0 or CC with Attribution musics on hand. ;)

This is the example I have made for the GameDev.tv Game Jam 2022 last year:

https://creations-maxo.itch.io/bahoo

I'm in...

...and there's no way out except through death.

If I count the 2 Jam which I didn't completed due to some unforeseen situations, this would be my 5th.

If you're very new to game development, I would suggest to download and look at the starter kit given for free ( https://offer.gamedev.tv/jam-starter-kit/ )

You can check it out even if the jam isn't started and test things out with it for practice. Then on the time when the Jam start, you can just start anew with it, again, but at that point you might have a better idea of how to use it. ;)

Personally, I'll start from scratch, but unlike last year, I'm not thinking about it at all until the theme is revealed. I want to do a pure 10-days Jam from a blank state of mind.

The GameDev.tv Game Jam is one of my favorite Dev Jams!

Thanks a lot to make it happen again this year! :D

That's not yet in the game. Lots of the stuff you see in the UI is not working yet.

Also, there's no saving/loading feature yet. All stuff you do is only applied until you close the game.

You do remember that you originally started this itch.io page to fund the development, right? You do remember that you initially started tis page and told people that by buying it on itch.io, they get early access to new features, right?

A copy/pasta of your own words even at the moment:

Get earlier development builds now here on itch (even earlier on SubscribeStar), or add to your wishlist on steam for more complete stable releases soon!

Saying "Not every update is worth playing, especially if it's content you want" doesn't apply here since the itch.io builds released are still broken/incomplete (barely in an Alpha stage). It's not even about content, but functionality at this point.

What you did is switching your business model from originally being "Development being funded via itch.io" to "Development being funded via subscription" as you know people do appreciate your work enough to pay a monthly fee (you have numbers related the number of sales on itch.io) for it and as you know that they wouldn't pay said monthly fee if you don't give them some monthly candies, hence you abandoned the "development builds" side of itch.io and turn it into basically a sub-Steam release.

As an independent developer myself who work with the same tools are you, I just can't agree with how you have handled this on itch.io.

In fact, you might not know about it, but there are laws in Canada, US and the UK (at least) which protect consumers from exactly what you have been doing, though you're still in the gray zone (but close of being out of time). You can't legally ask for payment for a promised product in development and then, later, offer an upgraded version of said product still in development onto any other platforms/markets/buyers without first equalizing both products equally toward your original payers from the first market/purchases.

I'll give you some tips based on your way of versioning your project:

v.X.0.0.a are released version, meaning that once it reach v.1.0.0, you have reached a stable final build. This is what you would call a "Steam release".

v.0.X.0.a are development versions, meaning they are steps where features or content are added or heavily modified. Any changes in those are supposed to be distributed on itch.io as per your own original promises. You could also release a pre-Release on Steam with this version, if you're confident (though Steam has specific rules, even since the fiasco of the Greenlight, regarding development time and they don't allow what you're currently doing with itch.io.)

v.0.0.X.a are fixes and minor modifications that may change some part of the game. It can also includes minor content addition like some festival content. For example, an additional option in a menu or new settings, etc.

v.0.0.0.a are minor fixes for oversight errors. For example, typos (mistakes in texts), or some other small corrections.

Remember that, on Patreon, you're at v.0.3.1.c (from the your Patreon news update) and, here you're still at 0.2.8.a and the 2 versions are quite different state of the same product. Your original promise on itch.io when you introduced the Patreon/SubscribeStar funding method was that itch.io would receive the same update as the Patreon/SubscribeStar, but 1 month later. v.0.3.1.c came out on July 18 2022. Even if you decided to completely change anything in the project, you're already not following your own promise on releases to your itch.io buyers.

Even if you're thinking "but I don't have that version of the game anymore", the builds files are still available. You got no legal ground on leaving your buyers from itch.io out of the loop like you did.

The [Experimental] is only available from the various subscriptions-based site such as
https://subscribestar.adult/momoirosoft
https://www.patreon.com/momoirosoftware

The [Experimental] version is supposed to turn into [Public] 1 month after it's being release, but as in every cases since this project was launched here, there's unplanned problem that pushes back and deadline are rarely met.

The latest news (you can read about it on both site above) is basically telling you:

"We don't know what we're doing and we're learning. Thanks for sending us money while we constantly change our project on whims because some stuff sound cooler than what we made up to now so we constantly scratch our work, never reaching anything concrete!"

Would be great, but as there's no news on the Patreon page regarding the supposedly planned release from 2 weeks back and as I'm not a Patreon myself, I can't tell what is going on either way. I'm just exchanging the information that is displayed on the public page of the Patreon's page.

Has the Experimental new version been released as planned? Dunno. Last public news was that it delayed 1 week (it was supposed to be released around the week of 29th June). Considering the "no news", it's possible that it got delayed again for an extended period of time. (https://www.patreon.com/posts/bigol-post-new-68395876)

If the Experimental Patreon-1-month-exclusive release was delayed, then it's also delayed for the 1-month-later release here.

The few updated news are given only on the Patreon page. The new update is/was supposed to be released for Patreon fan's 1-month exclusivity last week (or this week). We, on itch.io, gets the updates (called "public") 1 months after the Patreon (called "Experimental")

To put things in a clearer way, there's now a "experimental" stage and "public" stage where only Patreons fans (a.k.a. subs) have access to the experimental stage and, if we follow the point given on the Patreon's page, the public (those who purchased on itch.io) gets access to the "experimental" stage 1 month later when it turns into "public" stage.

That's, at least, the point that seems to be explained on the Patreon's page:

[Experimental], [Rough] and [Release] builds of our original games at least a month before public releases.

then later, it's written :

Public builds don't do the current visuals and features justice but you can play them on NewGrounds and Itch.io!

If I'm wrong, then I'm sorry. That's all that I could find.

Thanks a lot for the comment!

Yeah, I couldn't add audio feedback to the souls burning up or making it (nor add an effect it) which was planned to be added by the 2 last days of the Jam during which I had a lot of "fun" fixing some problems within the sequences of the rings and the not-finalized scoreboard. (If I didn't worked on those rings, there were quite a few problem whenever a soul was hit on the side by a moving ring.)

The biggest issues I had with the audio feedback for the souls was around having one that is neither too silent nor too loud because, sometimes, you could have 6-8 souls either burning up or saved within a single second. As such, I couldn't just add a "playOnce" whenever a soul was removed, but had to properly implement some ways of culling out overlapping feedback to a reasonable limit.

The commercial mobile version I'm currently working on has all those design and audio issues fixed. :D

I wouldn't say that I learned something new, but more that it reminded me that you should never believe everything will work fine even if you made it dozens of time in the past and it always worked. I tried to implement a saving/loading high scores system in my game which is literally just saving 3 Lists of 10 integers and because I tried too hard on making the high score "secure" in a certain why I'm normally used to use, I couldn't make it load it back in even though the save was successful. there was some error code popping out telling me that the list was not created (while it truly was as I could access it internally) and due to lack of sleep and having wasted 5 hours on debugging the crap out of that broken system, I scrapped the score board for the Jam.

To give an idea of how much I'm normally used at managing this kind of system, I have made a save/load system for an action RPG that save the data of 8,999 NPCs and 1 player and the whole system is quite solid in a way that makes data injection pretty much useless. (The save file can be edited, but even that comes with back-checks when the files are loaded and even saved.) And yet, in this case, I failed at being able to save and load (and use the data in-game) of 10 scores.

The answer will depend on how many people are working on a single project, what are their skills and knowledge and what tools are in their hands for the Jam.

Both have their PROs and CONs.

2D allows faster implementation of the environment, basic physics and is far easier and faster to produce a good correlation between the gameplay and UI as both uses a similar kind of rendering method.

3D allows faster animations, details' adjustments and allows an easy access to complex physics.

For example, I made a 3D game for the jam : https://itch.io/jam/gamedevtv-jam-2022/rate/1539775

I could have worked on a 2D version of my project, but I would had to put more time in the animations than what I did in 3D. While some part of the game would have been easier to implement in 2D, the perspective of the game would have been affected in a bad way. Ironically, the commercial release I'm currently planning for the project I submitted for this Jam will actually be looking a lot more 2D as I'm not restricted by time anymore.

Here are 2 tricks to overcome the issues with bad memory allocation:

• Run the game in private mode. This ensure that, when you close the tab/client, all memory (which are allocated in a closed memory box) gets properly cleared from the system' memory. In the case of a game with a saving feature, you will not be able to save anything though unless the saving feature is connected to a server (which I doubt anyone had time to do it in 10 days). It won't help with issues about GPU though, but will help with issues with CPU and general memory allocation.

•When closing the browser after playing, open the task manage (CTRL + ALT + DEL) and check if it's still opened in the background and look at what is taking all the memory. There could be something that was launched to run element in the WebGL codes that doesn't close properly.

There are other ways,  but that's generally the 2 things anyone can do with ease.

Thanks a lot!

Indeed, it needs a lot of polish, redesign and better planning and I'm already taking notes about how to make it a lot better. (I planned on taking 2 days off from any work that I can avoid, but my brain is just telling me "Nope. I'm working whenever I feel like it!")

I'm thinking of making this into a mobile game, which obviously has a very different kind of screen size and input source/design than how this PC version ended up as. Long story short, the game view will be quite different, but the general concept of the game which is about souls of the departed moving toward the Totem to be reincarnated will remains. The biggest issue I had with the input I implemented in this 10-days version is how inconvenient the whole 360 degrees ring is when it comes to selecting them and rotating them. It would be an even bigger nightmare on a 8"+ mobile device (as not everyone has a 12" smartphone). Hence, I'm planning on having the view set like a side-scrolling view making it looks a bit like Plants vs Zombies, but with a reverse where you goal is to make the things reach the goal end while, on the road, there are trap-like things you can move around. The ring-like setup would remain, but not on a multi-leveled-overlaying setup like we see in this PC version. the step-like setup is just a nightmare to manage with the soul moving up and down on each.

Souls will have an actual forms (types) and various types would have various "abilities" (good or bad).

The totem will have customization which will affects small parts of the game like the chance for certain types of grounds pieces or traps or even affects ghosts' behaviors. (An example I got recently would be that each Totem's piece with the gold material would raise the speed of conquistadors' type of ghosts or something like that.)

As you can see, there's a lot going on about the commercial version of this project that will start soon. Hope you'll like what's coming up!

Thanks again for your comment!

While it's not my first Dev Jam, it's the first I have worked solo for 10 days straight in the middle of Freelance work and, for 1/3 of it, while having a full time job. I worked around 78 hours in various stuff and jobs this week. I just slept around 6 hours right after submitting my project for the Jam.

If you want a good idea about what to do at the end of a Jam, here's what I'm currently doing:

- I ordered a bunch of food. Enough for 2-3 meals. (Note: I'm living alone. You might have to limit it to a single meal if you're in a family)
- I'm sitting playing on the PC or watching movies/shows for the next 48 hours
- IF my customers contact me, I work, but I do nothing else work-related.

I don't touch any game development or web development for the next 48 hours and limit my work to the bare minimum.

I'm finally done with the project or, at least, I reached a point where I consider the work "passable" for a 10 day Dev Jam.

https://creations-maxo.itch.io/bahoo

I haven't slept in the last 24 hours. Started working this by around 11h00 am yesterday, had a bit of other freelance work late, returned on this after, had major issues with simple stuff that normally works like a charm (stuff I made like dozens of times in other projects). Ended up scraping many features for the sake of reaching the deadline. If you open the Source files (requires Unity 2021.3.1f1) you'll find remains of plenty of stuff tried to make work until just a moment ago.

By this point, I'm just too tired to think about it anymore and as I know I'll have work again later and I can't tell if I'll wake up soon enough to work on it later, I decided to end it here.

While there's a really limited selection of Totem Songs and it's truly repetitive, I have to admit that there's something in this that made me actually like play-test it multiple time... well only when things worked obviously!

It's too bad that I couldn't work on adding more tracks. Half of the Totem vocals are only playable with 2 (last) song ?? and ???? which are meant to be "2 vocal random 1 effect" and "4 vocal random with 2 effects".

Well, I'm off to get some ZZZ!

See you all around later... or someday!