Project Planetarium

Who are you?

Aspen - Project Lead, Programmer, Pixel artist, Sound Designer.

Hey! I'm Aspen, I've been programming and making games for many many years in basically every engine there is... But never felt the drive to finish one, until now! I consider myself very experienced in the engine we're using (Gamemaker Studio 2.5) and have confidence we'll be able to make this game a reality. I also run the Tumblr account, so assume it's me behind the wheel as a default. Thank you for checking the game out!

Alec - Concept artist, Character Designer

H a l l o I'm Alec, I like writing and drawing and painting and designing shiiiiiiiit. I adore world building and have frequent bursts of creative possession in which I conceive and birth the greatest ideas and concepts in a mere moment. Otherwise, I can be a total dumbass and completely useless. I'm good at colours 👌 I have been a 85% a home-brew DM for about 2 years now and that is the greatest proof of my ADHD-given God powers of creativity. Slay.

What a cool guy!

Design pillars

Immersion. Above all else, I would like roleplay (casual or serious) to be natural and well supported. I would like players to find engaging with the world, and it's characters to be very personal.

Innovation. Tropes such as "You spawn in a green forest and can walk left or right" will be actively avoided. Biomes will have generation that presents more unique movement opportunities. Such as geysers in rock pools launching players high up, or giant twisting vines that hold up chunks of land to hop between.

More quality less quantity. Planets will be significantly more content-dense than Starbound, and perhaps controversially travel between them will be more difficult/expensive as well. This would encourage players to take advantage of all the resources presented on each planet, instead of hopping from one to the next. This would also encourage us throughout development to give each planet as much love as possible. Each planet should feel like a 'miniature terraria world'. Though actually achieving that is easier said than done.

Meaningful content. Procedurally generating creatures from 100 different pre-set monster parts could technically produce limitless alien creatures for players to encounter. But in both No Man's Sky and Starbound. I find this novelty to wear off quick, these creatures are not manually, meaningfully crafted and beyond an unusual appearance and some shallow gameplay changes... They do not create much of a memorable experience for the player. In my opinion, anyway. I would rather hand-craft every creature and make them all significantly unique and interesting. That's not to say procedurally generated creatures won't ever have a place in the game, but they certainly wont be as prevalent as others games.

Okay well... What's finished?

Fundamental lighting shaders akin to Starbound.

Some world generation brushes and basic commands.

A text mark-up language (heavily optimised), and game chat.

Extensive custom debugging tools

Hard and soft-loading of chunks to save on as much memory and CPU usage as possible.

Complete unloading, and compression of chunks on top of the previously mentioned system. As well as a live-saving system.

Setting, Story baseline, and conceptualization of the first 3 playable species. Each species will have a different starting planet, and immediately different playthrough.

Designs and cultures of several additional unplayable races.

Character proportion tests, sprites and sketches.

First-pass on collision functions.

Weighted Tile variance and tile connections.

CONCERNS

Multiplayer. While I have made an online multiplayer game before and it's definitely doable for this game, it would require some practice in a one-off test game to be fully confident. It would also take a LOT of time.

There's obviously some pretty bad stutters... This is caused by loading multiple chunks all at the same time. One or two chunks per frame has little impact on FPS, but if 5 or more chunks enter load distance on the same frame (very common) they are all loaded at once, causing terrible lag spikes!

Thankfully, this is very fixable. In the future, chunks will be added to a queue... each loaded individually one at a time.

Honestly making this entire system went extremely well... too well. Surely there's a horrific memory leak lying in wait for us to discover many months from now... I hope not!

Anyway, I plan to vigorously scrub everything we've written looking for further issues, just in case.

So apparently compressing and saving world data is a lot easier than expected, and decently optimized. I even tested including what is basically "NBT data" in quite a few chunks, and they saved correctly as well.

I think the system could use a few tweaks, but after that I have so much faith in it I doubt we'll be changing it ever again.

Saving is so efficient in fact that world changes can almost immediately be written to disk as soon as they are made, without stutters. In short, that means losing progress to a crash is almost impossible.

Well... Not quite... I imagine if you used an unreasonably large nuke or something the game would take slightly longer to save those changes. But is the player really going to have that power?

Granted, we don't load this data yet, nor do chunks actually unload when they've saved yet. But those problems are so small in comparison that I'm not worried. Optimizing an entire planet's worth of content when not in use has been such a daunting task, and it's finally done...

For additional context, A chunk averages about 300 bytes. Though this can be significantly smaller and occasionally larger, depending on it's complexitu. A Megabyte (MB) is 1,048,576 byes. That's 3000+ chunks PER Megabyte.

Chunks are 16x16 tiles and can have 3 layers. The test above assumes they have tiles on all 3 layers with slightly unfavorable complexity.

Text is currently drawn character-by-character, each frame. So multiple paragraphs of text can be surprisingly expensive... We can fix this in a couple ways.

Only draw text that is confirmed visible on screen.

If all of the text in an instance is stationary... We can basically take a screenshot of how it looks completely drawn, and use that instead of typing out each character one at a time again.

Let's talk about point 2 using more technical language.

We'll check if a block of text is unmoving (no shaking or wiggley text), if it is... Then we create a surface and draw all the text to that once. All the text belonging to this block, that is.

Then, we keep the surface in a variable and whenever the text attempts to draw it just uses the surface image instead.

Some people might try saving the surface as a sprite. I don't think that's a bad idea. But as far as I understand, sprites use up more memory than a surface alone.

The downsides to using surfaces are that they are 'volatile'. Which means under certain circumstances they can be suddenly erased. But I consider this a good thing... One of these cases is when you alt+tab away to a different window. The surface will automatically clear and free up some memory, if you're not looking at the game window there wont be text. Simple enough!

At worst, there'll be a minor lag-spike when alt+tabbing back to the game window. Orrrrr... We have a terrible memory leak. That's definitely possible but only if I mess up.