FloncDev / exquisite-exoplanets

Our submission for the 2024 Python Discord Code Jam - "Information Overload"
MIT License
0 stars 0 forks source link

Lore #11

Open FloncDev opened 1 month ago

MilaDog commented 1 month ago

The idea about farming planets sounds good. Keeps in theme with the naming of the groups for the Code Jam.

Then, as briefly discussed in the VC, you start on a base planet, mining resources that can be sold to earn currency. This currency can be used to buy features from the shop to improve your script, such as a single ability to update your script, script cooldown reduction etc. As this occurs, you start earning more money. Once you reach a currency milestone, that marks the end of level 0 (because we are programmers) and you can move on to level 1, which is a new planet with new (and some old) resources, a new base script.

One thing to think of is if the currency will stay the same or if there would be a new currency for that planet? However it is done, in order to reach level 2, the use of planet 1 would be needed.

Currency also does nto have to be a thing. You could also replace the currency for XP and islands unlock at different XP levels. Raw mined materials would be used to upgrade the user's "factory".

Just some brainstorming.

i-am-unknown-81514525 commented 1 month ago

could upgrade/new base script could just reference as upgrade -> decrease the use of operation count to complete the function new -> a new function that available to user

or we doesn't actual need the user to code that much

bensgilbert commented 1 month ago

If the user can upgrade/improve their script with (xp) points, there's no point for the user to code efficiently. Instead, for each planet, we could assign a task similar to those sites where you can go to practice small test questions like algoexpert, edabit or codeacademy.

We could present a little lore behind each planet like "We need you to write a script to find the first n prime numbers given a starting number m". We can then run their script with different randomly generated arguments and each time it runs they get a little xp making it an idle game which is what we planned.

If for whatever reason their script breaks for some given arguments (an edge case for example) then we can say the script broke and needs fixing so they'll have to go back to that planet and fix it.

We could also introduce the idea of maintaining a script like how farming/mining equipment needs to be maintained, we could do this in the form of upgrading the same challenge or something similar. This also solves the issue mentioned in #10 where we can't communicate with the snekbox environment during runtime, since the user codes a function we have a defined input and expected output

This can even possibly be presented as a teaching tool for python which might win over the judges 😄

FloncDev commented 1 month ago

If we want it to fit with the theme even more, we could have the challenges involving large amounts of data - or maybe producing large amounts?

i-am-unknown-81514525 commented 1 month ago

Umm, in this case we could just purely apply snekbox then since we don't need real time communication

i-am-unknown-81514525 commented 1 month ago

And maybe the challenge is a buff to make it easier to progress, but still possible to progress without

i-am-unknown-81514525 commented 1 month ago

Well, maybe our task for #10 is to create a challenge and might use other language binding to make it solve quickly on validation (e.g. rust), and the runtime of the script determined how much it would buff (run in multiple attempt and first/second best would be counted depend on how many attempt we run)

bensgilbert commented 1 month ago

That's a good idea, looking over the excalidraw at the "machine overloads user" section, there's "spam, DDOS, compressed/dense, complicated and calculation". Here's what I'm thinking

User works for a generic resource gathering company They get assigned a planet which has a coding challenge They write a robust script to solve the challenge The script will be run at periodic rates to earn xp/points

When the script runs it will be tested with:

An added feature that I would like is that we have different tiers of the same challenge so the user can upgrade their script that way

i-am-unknown-81514525 commented 1 month ago

And we can then just map it to be a optimization script which a (imaginative) base script exists and running in a lower rate, and you need to try and build a faster one to get higher rate of output

i-am-unknown-81514525 commented 1 month ago

We just need to make it so the performance of the script doesn't linearly correlate to what you get, but maybe somewhat inverse exponentially

bensgilbert commented 1 month ago

If the user can upgrade/improve their script with (xp) points, there's no point for the user to code efficiently.

Are we keeping the upgrade system then? I kinda liked the idea because it gives the user something to spent their credits on

i-am-unknown-81514525 commented 1 month ago

Maybe thinking as upgrade script upgrade the processor, it just increase the multiplier but didn't change the script

MilaDog commented 1 month ago

It also does not have to run run periodically. We would test the script against the different challenge tiers, noting which tier gets passed. From there, can computer what that user would earn for that script at that planet. Then, when coming to the cooldown between the script running, it would be $x per cooldown, (eg: $5/30min). Then the user can decrease this.

Then we would have a command like /bank <planet>, which stores the time of the last bankout and the time at which the command was invoked. That can be used to determine the amount of currency they have earned. Of course, we would have to keep track of when during these two time periods the user bought upgrades to improve their script, which can potentially be solved by having a field storing what has been earned so far, so that when a user upgrades their script, it takes the last bankout time and the time at which the script was upgraded, calculates what has been earned, stores this, then updates the bankout time with the time the script was updated. Then when the bankout command is invoked, the remaining earned currency is calculated, added to the previously earned currency, given to the user, and then reset. The process would start over again.

Elektriman commented 1 month ago

I see a problem with the concept of making coding "challenges". We will have to make a lot of challenges actually chalenging which is difficult when a lot of the best algorithms for many tasks are already documented. Which mean that it will be very easy to min max your gameplay and it will become boring real quick. To counter that, we could add some randomness into the planet generation of resources and don't tell the player about certain rules of the game right away so that they can discover them and improve their algorithms.

for example, we could have a planet with forests and fossil energies, but if you collect fossil energies before the forests, it will actually degrade the amount of vegetation you can collect because the fossil industry needed to destroy part of the forest to set up extraction pumps.

To collect resources I was thinking every planet would have a percentage that would represent a chance of getting a certain resource every game epoch, decreasing overtime. When you first arrive you have 87% wood but as you collect it it becomes harder and harder to find some wood and you decide to abandon the planet at 30% because the operations also cost you money. This means that to be optimal you need to implement yourself when to stop for each planet. Different materials would have different ways of decreasing that percentage and rarer materials would be harder to find and more expansive.

FloncDev commented 1 month ago

I think for the coding challenges we could do something in the style of advent of code - and I don't think algorithms being well document is such a big problem since if a player does decide to look it up, they are just decreasing their own playtime and enjoyment.

I do think that your idea should be implemented though, makes the game more interesting and balanced.

i-am-unknown-81514525 commented 1 month ago

well, the code challenge is like a side quest, you don't require it to progress, and the multiplier should be limited. But ye, it would be nice idea if we could make some specific random data for each user need to optimize themself, but that would be difficult on how to interpret it mathematically

i-am-unknown-81514525 commented 1 month ago

and an idea could the material could be re-new (very slowly) to make it still possible

i-am-unknown-81514525 commented 1 month ago

We could have some generic challenge for global multiplier on a specific action/credit, and specific challenge that only optimal on 1 planet for the specific action/credit

i-am-unknown-81514525 commented 1 month ago

But still, the scope of the script is quite important to be discussed with

Elektriman commented 1 month ago

I think I found a good balance where you need to complete mini code challenges in order to extract a resource, which then will be subject to randomness. I don't know what you guys think about the part where you have to manage your fleet of harvesters so that you can make money. I think it could be more challenging and interesting. This will also able us to lock the machines to forage better resources behind a paywall

i-am-unknown-81514525 commented 1 month ago

Well, what I mainly concern about is how to interpret stuff mathematically so it only run single time on snekbox, instead of having to expose API and constantly running it

i-am-unknown-81514525 commented 1 month ago

for the basic challenge, it is simple, just generating prime number and validate it against a quick solver, but for specific one, I actually have no clue how the question could be asked