Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Spyros

14
Posts
1
Topics
5
Followers
A member registered May 12, 2020 · View creator page →

Creator of

Recent community posts

(2 edits)

Good catch! Found and fixed it. There was a race in the onboarding tutorial logic where the next tip's listener wired up *after* the action it was waiting for had already happened. Only affects the boot → sensors → uplink tip chain; nothing else uses this pattern. Will roll out in the next demo build. Thanks for the report!

The game is so complex that these(hopefully not breaking) errors will happen from time to time. It gets especially complex later so I absolutely want to be fixing everything I can as best as I possibly can.

(2 edits)

No worries, I have actually already added a reference about this in the DOCS of the game, it's a very good point. I added this to the Components page in DOCS (not live in the demo yet)

**Each call is a new instance**
`get_component(id)` is a factory — every call creates a fresh wrapper, like instantiating a Python class. For machines tied to a physical entity (rover, smelter, generator), wrappers all read and write through the same backing data, so it feels singleton-ish in practice — setting a value from one wrapper is visible from another.
For purely virtual components like the `transmitter`, each wrapper is independent:
```
# Fails — two separate transmitters, only the first is connected:
get_component("transmitter").connect("earth")
get_component("transmitter").transmit("weather", 42)
# Works — one transmitter, used twice:
t = get_component("transmitter")
t.connect("earth")
t.transmit("weather", 42)
```
Wrappers are just objects — make one, make ten, each is independent.

Thanks for the feedback and helping me make the game better ! Appreciated !

Yes, totally got you, they are not static or singletons, they act like class instances pretty much. But you are absolutely right, i should probably make that more clear in the DOCS. I will add sth to clarify it a bit better.

Hi! Thanks for trying the game.

The transmitter behaves like a regular Python object — every `get_component("transmitter")` call returns a *new* instance. So your script creates two separate transmitters: the first one connects to earth, the second one (used for transmit) is a fresh instance that hasn't connected yet.

Fix is to assign once and reuse:

t = get_component("transmitter")
t.connect("earth")
t.transmit("current_temperature", get_component("thermometer").get_value())
(1 edit)

It's not a mistake, it's actually the correct way to play it, but notice that the DEMO progress bar above is based on terraforming. Full game will of course be completely open, you would be able to do whatever you like. For the demo, If you want you can always start a new game, it should be easy to copy the scripts you already made so that you can see the remaining demo features. 

Yes, it will absolutely be released on steam and other platforms as well if people ask for it. In fact, the Steam page is currently being reviewed and I expect it to be up in a 2-3 days or even earlier. The steam link is in this page, below, and it will be accessible shortly, feel free to wishlist it there if you like. The full release will probably be around August/September.

Hi, thanks ! 

You need the autofeeder research to move things to inventory/bins/warehouse etc. It's a required research for transporting items, but it's fairly easy to get early.

Notice that the info tab is a presentation of the rover's fundamentals, but the DOCS have the full API specification. 


That said, the rover is designed to be a more primitive vehicle. The pioneer is more granular on purpose. For .cargo on the rover you get count() and capacity() — there's no per-mineral readout because it's a single integrated bin, your script just tracks the id of what you are carrying. Pioneer uses racks that are way more versatile and intended for the first line of transportation in the game

Yeah the demo has an ending based on terraforming, but I feel like it has a good amount of content available and also one can go slow on the terraforming to test various things slowly. I just had to have some sort of an ending that makes sense :) The full game will be available in 2-3 months though so hopefully people can enjoy the rest of the game, it gets very deep later with outposts,drones,smelting, fabrication etc..

(2 edits)

Hi thanks !! You mean you want to see the scripts you have written ? They are all there ! Nothing is lost. They are in the code tabs of the components that use them and you can also create and save variants and notes about any specific script. Let me know if I can help find it, feel free to join us on Discord, we are chatting about the game and things that will be added in the future etc..



I have actually worked on a feature that displays all scripts and allows managing from a dashboard, to make it easier to check previous scripts at any time, and manage it in one place too

Thanks much ! Appreciated :)

Happy to hear ! Have fun !

(1 edit)

There is a Manage button in the the cards of components click on it and the window of the script comes up (info/code) tab

It is the transmitter component (check DOCS)

it should be like :

transmitter.transmit("xenogenetics", [values])
for a given contract.

Feel free to join our discord I can help faster, I am usually around, and we already have people joining and discussing about various game scripting etc..

(3 edits)

Haha, that's how programmers rest from programming, don't we :D ? Thanks for the kind words, I tried to make it as detailed and as scalable as possible. The idea is to give the player the tools to do whatever they like in this world. It's completely open to them how they can interact  with the components and there is really a ton that a player can do however they like in  the late game.

It is a custom interpreter indeed, it's not actual Python but it behaves like it yes :)

Thank you so much, I am so glad you are enjoying it :)

(2 edits)

Hey itch — just published the demo for my game Code: Terraform.

It's a programming/automation game where you write Python-like scripts to terraform an alien planet. You don't click to mine. You write the mining script. Solar trackers follow the sun because your code reads the clock. Drone fleets fly because your code dispatches them. Scripts run while you plan your next move.

The demo runs in browser, and it is pretty lengthy, you will get a chance to look into many systems, including terraforming, harvesting, earth contracts and even planet map mining, which is a deep simulated system in the full game, including smelting/fabrication, earth orders, automation drones and many more. It is an ambitious project, I hope people will like it :)

There is also a pretty deep story in the game. It's not obvious at first, but it gets obvious as you play. It's a bit of a sinister plot, things are not really what they appear to be..

If you check it, I'd love to know what worked and what didn't .

Discord: https://discord.gg/hUrK2MRn8s

Steam: https://store.steampowered.com/app/868160/Code_Terraform/ (steam page is pending review, so it will be available in a few days)

Play here: https://hthought.itch.io/code-terraform

I aim to release the game probably about September or so but I definitely wanted to get some opinions/ideas about the direction.

Thanks !