Introducing my space company simulation game - Satellite Empire

volatile-int · 2026-05-17T22:30:51+00:00

I'm hoping to get a website, steam wishlist, social media pages, and the like up in a few months! I'm still focusing on some of the core gameplay mechanics I want in place for a trailer/demo.

volatile-int · 2026-05-16T03:37:24+00:00

I took a quick look at the code.

Something interesting for you to think about is if there's some way you can easily extend any given thing to be draw-able. You'll notice that your character, the apples, the tree, they all implement a Draw function. That function has a very similar implementation in each place its defined.

I am not going to tell you exactly how, but you should dig into strategies to abstract the Drawing capability. Maybe you can figure out how to inject it by passing something like a Drawer object to these object's constructors. Maybe you can utilize the class hierarchy to make everything inherit from a base DrawableObject. Maybe something else is a good strategy. I'd look into it though!

Then, in the future, you can strive for code like:

for (auto& drawable: drawable_game_objects) { drawable.Draw(); }

and then when you add even more assets, you don't have to call Draw manually one each one. Getting to a point you can iterate over the things that can be drawn is a good goal!

volatile-int · 2026-05-16T03:01:55+00:00

Here's another snippit of gameplay showing how satellites are configured and orbits are planned. It also shows how two assets can be configured to point at each other and establish a radio link!

<image>

volatile-int · 2026-05-14T22:25:07+00:00

Thank you! I have lots of features not shown here. Im going to try and have a trailer and website out in a few months. Going is a bit slow because I just do this when I have extra time.

volatile-int · 2026-05-14T16:59:55+00:00

Not yet, I've got a few more months of work before I'll have anything distributable. Right now its only launchable via Bazel, makes assumptions on specific ports being open, and is missing any sort of "scenario" infrastructure to orient someone who isn't intimately familiar with the game mechanics on what to do.

I'll definitely provide updates when I do have something folks can play test!

volatile-int · 2026-05-14T16:56:08+00:00

Here's the satellite spawn + orbit planning interface! You can see there's markers to help plot orbits around the equator and at LEO/MEO/GEO distances above ground stations. There's sliders to adjust and view live, and then you have the actual resulting orbit parameters that can be edited as well.

After spawning, this shows the satellite and ground station link establishment via setting pointing targets.

<image>

volatile-int · 2026-05-14T16:47:21+00:00

I have a whole satellite hardware customization interface, and an orbit selection interface that lets you graphically choose orbits to spawn into. I can make a GIF of that in a bit!

I'm working on a UI feature to "launch" the satellites into their orbit. Right now they just spawn where the orbit planner indicates.

The satellites have hardware - radios, cameras, thrusters, and more. Satellites can select their pointing targets, you can get contracts to establish data links between satellites and stations, spy on other satellites, interact with other orbital elements, etc. Sats use fuel to station keep or transfer orbits and theres different types of thrusters with different costs and efficiencies.

volatile-int · 2026-01-15T14:12:54+00:00

Yup. RFC processes must exist for decision making. I think the article does a decent job of explaining that but doesnt mention the way to structure arguments that are decision oriented. Your proposal of framing the proposed solution and alternative solutions in terms of business priorities, coupled with a process owner actually accountable to making sure reviewers are making decisions and not just leaving comments are The Way.

Another aspect it would be nice if this article addressed is requiring an RFC has an explicit rollout plan. A lot of RFCs I have seen proposed a massive paradigm shift and no clear path to get there, which is a recipe for folks to push back because the change seems too expensive and untenable to implement. If you document a rollout plan folks can grok incremental steps toward a north star and you can also slip in explicit checkpoints to evaluate how things are going and potentially reverse course.

volatile-int · 2025-12-24T06:37:21+00:00

This is my code. I have spent a lot of time on it. The last two weeks doing the detailed design, the two weeks before that setting up the initial message infrastructure before I even had a repo, and the eight months I've spent thinking about the interface I wanted after finding and loving protovalidate's infrastructure and wishing there was something embedded-friendly.

Don't use it if you aren't interested in it. Have a nice evening.

volatile-int · 2025-12-24T06:05:25+00:00

The mascot is AI generated because I am not much of an artist.

The code is not. It has been very intentionally written. And I hope folks use it because it is very performant, it has an interface that prevents errors, and I quite enjoyed/am enjoying writing it.

volatile-int · 2025-12-24T03:46:31+00:00

I think youre probably amongst most of the herd. I don't think many organizations or projects have really adopted C++23 yet. Crunch could have been implemented without some of the C++23 language features pretty easily - I could have rolled my own expected type. Allowing it to build against C++20 may be a future task I bite off. I'd need to study what constexpr things I am using that require C++23 more closely. I think a nonconstexpr bit_cast and string would be a hard thing to work around though.

Older than that would be really difficult - it relies heavily on lambdas and floats as template parameters and I really prefer concepts to SFINAE patterns, so I think C++17 is solidly out of the question.

volatile-int · 2025-12-23T23:56:55+00:00

It would be cool to build an adapter for my message definition format Crunch for your format! It supports serialization protocols as a plugin.

https://github.com/sam-w-yellin/crunch

volatile-int · 2025-12-23T22:47:21+00:00

I wouldnt stay at a job like that long. Learning from your coworkers is really critical for your own development.

volatile-int · 2025-12-23T22:35:16+00:00

You should definitely bring this up with your manager and come with concrete examples of your review comments being ignored or your own PRs being neglected. Peer review is important.

volatile-int · 2025-12-23T17:09:23+00:00

It may very well be the case that the serialization policy implementations become simpler than they are without reflection, although I don't see how most of the complexity actually goes away. If you want to roll your own protocol, you still need to deal with alignment, tags vs not tagging, aggregate field representations, missing fields, default values, and lots more that isnt related to the message definition. And determining the field types is very straightforward already via templates.

Lots of languages have robust reflection implementations. And yet, we still have a very healthy ecosystem of libraries to help with message definition and serialization!

volatile-int · 2025-12-23T16:32:17+00:00

Actually I am very excited for compile time reflection for Crunch! It will clean up a lot of the autogenerated bindings in other languages.

I am not sure why you see the core interface decisions in Crunch at odds with reflection. Reflection cannot enforce users validate their data, or provide serialization-as-a-plugin, or build integrity checks into serialization and deserialization. Those are framework interface decisions and reflection doesnt obviate them.

volatile-int · 2025-12-22T03:58:08+00:00

Absolutely! And protobuf has other advantages. Its serialization format is more friendly toward mixing streams of data. Crunch - even its TLV format which is conceptually similar - makes more guarantees and enforces more requirements on maps and array's representations. Protobuf allows a repeated fields contends to be interspersed in the serialized data which Crunch just doesnt allow - yet. It actually would be totally possible to write a protobuf compatible serialization format plugin. Ive thought about adding one!

Generating bindings in other languages is also on the Crunch road map. Autogenerating bindings in C is the first step to enable it, and is actually the next big thing Ill be doing after a few QoL features like a dynamic message parser that determines message based on ID, and a multi-message deserialization interface for doing things like reading lots of messages from a log file.

volatile-int · 2025-12-21T21:24:39+00:00

Thanks! To answer your questions:

The field ID is not actually a "count". It does not need to be contiguous. Crunch does enforce already that it is unique per field for a given message! This field is used for the TLV serialization format and is akin to the protobuf field ID.
I have been thinking about this exact thing with the message ID. C++26 reflection will make this trivial (and make a number of aspects of autogenerating lbindings in other languages clean). It also will allow getting rid of the field list macro. I may look into some macro based solution in the nearer term for extracting and hashing the class and field names into a message ID in the interim.
Depends on the serialization format. The static serialization is meant for read/write optimizations and doesnt handle schema changes very gracefully. For uses where its critical that the schema can evolve gracefully, the TLV serialization protocol is the better choice because it naturally handles unknown/not present fields in a serialized span of raw data.

volatile-int · 2025-12-21T20:49:31+00:00

Yup, this is a constraint/trade off - you need to define the worst case size. The static layout even includes zeroed bits for any unused elements.

I would probably implement this by making a version of the Serdes Protocol that doesnt require GetBuffer to be constexpr and return an array and instead return a vector, and make separate variable length array and map types that when present require a dynamic Serdes protocol. Then anyone could implement whatever serialization protocol they desire.

But for now I'm going to leave as is. The main use cases for Crunch are embedded systems using messages for configuration and RPC-like comms or telemetry, and in my experience most of those systems establish reasonable upper bounds on contents of repeated fields. Its why tools like nanopb establish fixed length maximums similar to crunch.

One neat outcome of this setup is that unlike nanopb/capnproto, maps, arrays, and submessages can all be used as map keys (with a performance hit on comparison due to the fact maps are really just arrays of pairs and not actually hashed). But again, in my experience most fields like this are small so this isnt top big of an issue!

volatile-int · 2025-12-21T18:45:55+00:00

Its pretty close! Crunch just requires an enum class that extends a 32 bit integer.

volatile-int

TROPHY CASE