Status
SteamPeaks
ChartsSalesUpcomingPatchesNewsCalculator
New on SteamEvery app, DLC and depot the minute Steam creates itAppsEvery app on Steam, newest change firstPackagesSubs and bundles, and what each containsDepotsDepots, manifests and install sizesTagsSteam's user tags and the games under themDevelopers & publishersCompanies and their cataloguesTechnologiesEngines, SDKs and anti-cheat found in the filesChange historyEvery PICS changelist as it lands
SignalsNineteen readings of the whole catalogueCompareAny games side by sideRecordsAll-time peaks and the days they were setReportsWeekly and monthly write-upsAlerts & newsroomWatch a game, get told when it movesSteam statusIs Steam up, right nowWeb API explorerTry the endpoints in the browser
NewsSteam's own announcements and the sales calendarCalculatorWhat a Steam account is worth, and its pile of shame
/
Sign in
/
SteamPeaks
The ultimate resource for Steam data.
ExploreChartsSalesSales and festsUpcomingPatchesNewsRecordsTrendingSignals
DatabaseAppsPackagesDepotsTagsDevelopersTechnologiesChange history
ToolsCalculatorCompareSearchAlertsSteam statusAPI
SiteMethodologyFAQDiscordSupportSign in via Steam
Not affiliated with Valve or Steam. Game names and artwork belong to their owners. All times UTC.
PrivacyCookiesFair useStatus
Star IliadNewsDev Log #09: Little Design Decisions
Community

Dev Log #09: Little Design Decisions

Star Iliad · published 2 Jun 2026, 00:46 UTC

All newsPlayers around this dateRead on Steam

When creating a game world, you have to tackle various design questions.

We're familiar with the big front-facing design questions - things that require clear intent and are likely to be listed in the game design doc. They'd be questions about the game’s core genre and tone, the gameplay loop, the story, art style, and so on.

But there are other design decisions to make - "little" ones that are almost invisible. They're not likely to be listed in a design doc. Maybe the designer doesn't even think about them consciously...

Then every so often, an inciting incident occurs - a little exchange alerts you to the fact that something you assumed was agreed upon by everyone was, in fact, not. In those little exchanges, the little design questions announce their presence and demand an official, consciously recognized, decision.

Today, I'll talk about some of these little design questions.

(Note: Chinese Translation of this devlog is available! Courtesy of Baojie)

Little Design Question 1: Will there be blood?

The inspiration for today's topic came from a real exchange. We were working on one of the bosses, a brutal one, that would try to crush the player and any intruders. So, a dev mate proposed that the stages should have drainage holes so the blood could drain away. Which I thought was really morbid.

I proposed we simply didn't need to have drainage holes at all - no need to invite the imagery. In fact, do we even show blood? 🤔

(Okay, there is blood splatter sometimes, but they're all non-red - and only for the "zombie-ish" monsters)

Blood splatter, when it comes out, quickly evaporates. They don't fall to the floor and pool. In general, enemies don't leave behind a body, they evaporate in a puff of smoke.

Little Design Question 2: Will we have bathrooms?

On a similar note, have you ever thought about how some games feature bathrooms and some don't? Take Zelda Breath of the Wild. You could follow an NPC all day, watch them run around town, do their chores, return home and sleep. And nowhere in the entire day's schedule do they use the bathroom. In fact, you could scour all of Hyrule and not find a single toilet.

That must've been a little design question the designers decided upon at some point. The last occurrence of a bathroom in Zelda was Skyward Sword, and there was only one.

I think I agree with such a decision. Why even invite such... imperfections into the game world? Our characters don't need to poop 😌

(The house in RE7. If the game is in the horror genre, chances of a bathroom increase to 99%)

Little Design Question 3: Can Platforms Float?

In Mario, platforms can just hang in the air and that's not considered unusual. Mario's world is pretty cartoony, so floating platforms feel right at home.

On the other end of the spectrum, consider Prince of Persia. Notice how the pole that the Prince is swinging on has to jut in from the background or how the wooden platform has support beams anchoring it to the stone wall? Everything has to be contextualized.

Star Iliad follows the anchored platform rules, so platforms and breakable blocks need to be contextualized too. In the below picture, the breakable blocks below are fine to have, whereas the breakable blocks floating in the sky would be considered no-bueno.

It might seem like a small decision, but floating platforms have a lot of ramifications. The presence of a background removes dimensionality from the scene, which hurts visibility - and so requires the art team to use very specific lighting to make sure things are still visible.

Anchored platforms also subconsciously convey information to the player. For example, if there's sky above the player, you could safely conclude that there's nothing hidden above you since platforms can't float. The way we design the environment guides the player's eyes.

Little Design Question 4: Do ammo pickups make world sense?

That enemies drop ammo - that's likely to be documented in a game design document. But what about if it makes "world sense"?

In Phoenotopia, you have this green gauge that governs sprinting and attacking. So it's kinda like "Stamina". However, later you get other tools like a slingshot and bombs - they also deplete the same green gauge. So, I guess the green gauge can be considered "general resources"?

That did bother me 🤔

A popular alternative is to have separate bomb and arrow pickups ala Zelda - make the other tools be governed by a separate resource counter. But now, defeating enemies, breaking pots and cutting grass may need to drop bombs and arrows. Shops will sell you restock. So, this is a design choice that has game world economy affecting gravitas!

And it's not the case that by having separate ammo counters, the lore for replenishment gets tied up nicely. Consider Metroid, where fly monsters will drop missiles and bombs on defeat. Needless to say, that makes no sense.

(Maybe the green gauge to replenish bombs and arrows isn't the worst thing...)

I thought Hollow Knight Silk Song did an elegant job with this. Enemies would drop money or "shell shards" depending. If they were once sentient and looked like they would have used money, they dropped money. And if they were more animalistic, they dropped "shell shards" - which was the currency for sub-weapons. There'd even be a little animation to show Hornet crafting sub-weapons when on a bench. You could tell the developers really respected the internal rules of their game world.

Little Design Question 5: Do Abilities make "world sense"?

Similar to ammo pickups, how best to frame abilities?

In Zelda, abilities come from tools that you possess. You have a "Bow", therefore, you can shoot arrows - that makes sense!

But what about when the ability doesn't fit neatly into an "item" package you can hold?

Then it gets a bit trickier. In Phoenotopia, we framed abilities the player learned with technique scrolls. But it would feel weird if the player got a piece of parchment and then could suddenly somersault, so we do a fade-to-black with training montage sound, to imply the passage of time. That's us feeling beholden to the game world's lore rules.

That's all well and good for cartoony worlds, but in more grounded settings, it gets tougher still. I found Resident Evil 7 had a novel solution. To boost health and gun action speed, you literally get steroids to boost your abilities - it even comes with a cutscene of the character injecting himself. That's dedication!

(What if Star Iliad featured powerup injections? A sketch explores this awesome future)

Closing Thoughts

And that concludes a slice of some of the "little" design questions we'll think about.

Devs spend many more hours sweating over the core gameplay loops and balancing combat stats, but it's perhaps these tiny, unimportant questions that define the game's soul. They mustn't be slept on!

Next update comes end of July. Thanks for reading!

More from Star Iliad

Other announcements

All news
Community1 Aug 2026Dev Log #10: Fast TravelA rare trip has come up. An old friend is getting married, which has necessitated I travel to the other side of the world. So on that note, let's talk about "Fast Travel" in video games. One might be tempted to think it's an easy question: "How soon should we have it?" But actually, the design space for Fast Travel can be quite vast. Some games choose to not have it at all - then there's the qu…Community2 Apr 2026Dev Log #8: HP vs HeartsStar Iliad uses a "Heart" system to display player health - which is a marked change from Phoenotopia's “HP”. Today, I'll explore why that is. Did we consider other health systems? And is using Hearts simply a cosmetic decision or a major change that will shape the game design fundamentally? ( Note: Chinese Translation of this devlog is available! Courtesy of Baojie ) (What if, like in classic…Community31 Jan 2026Dev Log #07: The META of Blog PostingHappy New Year! New years invite reflection. Today, I’ll reflect on dev logs themselves. More specifically, why do we write them? What are they for? And why do I have writer’s block? ( Note: Chinese Translation of this devlog is available! Courtesy of Baojie ) A Quick History I started my first blog post about 12 years ago. At the time, game dev was still foreign to me, so I lurked on game dev…