Mini Jam 131: Solar

Hosted by ZahranW, KingW · #minijam

Entries

592

Ratings

Overview Submissions Results

Community12

Screenshots Submission feed

Mini Jam 131: Solar community

Finally started to work on it... after quite a bit of brainstorming!

A topic by CMaxo created Apr 28, 2023 Views: 202 Replies: 7

Viewing posts 1 to 7

CMaxo1 year ago(+1)

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

Untiited1231 year ago

I need help on my game

Untiited1231 year ago

it's my first game / game jam and here's my code "

using UnityEngine;

public class Spawn : MonoBehaviour

{

public GameObject objectToSpawn;

public float spawnFrequency = 1f;

public float spawnPadding = 0.1f;

public int maxObjectsOnScreen = 5;

private float nextSpawnTime = 0f;

private int objectsOnScreen = 0;

void Start()

{

// Set the initial spawn time to be now

nextSpawnTime = Time.time;

}

void Update()

{

// Check if it's time to spawn a new object and if we haven't reached the max objects on screen

if (Time.time >= nextSpawnTime && objectsOnScreen < maxObjectsOnScreen)

{

// Generate a random position within the camera view

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

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

Vector3 spawnPosition = new Vector3(x, y, 0f);

// Spawn a new object at the random position

GameObject newObject = Instantiate(objectToSpawn, spawnPosition, Quaternion.identity);

objectsOnScreen++;

// Update the next spawn time

nextSpawnTime = Time.time + spawnFrequency;

}

public void ObjectDestroyed()

{

objectsOnScreen--;

}

" it lags when I start it because too many things spawn, I use unity

CMaxo1 year ago

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

Untiited1231 year ago

this is c#

CMaxo1 year ago

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)

CMaxo1 year ago

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.

CMaxo1 year ago

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!

itch.io

Mini Jam 131: Solar

Finally started to work on it... after quite a bit of brainstorming!