logoalt Hacker News

klausalast Thursday at 1:12 PM2 repliesview on HN

I think for games like Blue Prince, specifically, it’s not a false dichotomy.

Those are made in tiny teams. You can either spend more time tinkering with the gameplay mechanics and experimenting with the game parts; or you can put on your software engineer hat and make the code better (or, spend even more time to learn how to make the code better in the first place!).

This gets less true with scale of a team, and with 5000 people behemoths you probably should care _a lot_ more about the code; but ROI on improving the code in (relatively! Calling Blue Prince “small” is ridiculous.) small games is very dubious.


Replies

bzzztlast Thursday at 3:22 PM

Of course programs will be worse when non-programmers are in charge of programming. That doesn't mean they shouldn't but lots of indie game attempts fail because the programmer (educated or not) doesn't have a clue about when to refactor and make sure the design of the system matches the intention of the game. You can only tinker until a certain point, after that you're just creating new bugs by fixing other bugs.

ID software once was a small team and they built complex games by writing tight code which was modular and very clear. Lots of their '3d era' contemporaries failed because their engines were sloppy, complicated, buggy and slow.

tialaramexlast Thursday at 2:52 PM

A lot of core game logic is presumably Tonda's work. He's a director, not a software engineer. He came into this, many years ago, wondering if the "easy" tools to make a video game meant he could just make the video game he was imagining, and of course the answer is "Yes, but..."

Blue Prince is (an extrapolation of) that first game, but it looks and sounds like competent people worked on it, not like something slapped together by a non-engineer in a week. However while you can hire experts to make "You know, like cool jazz for a mysterious underground area" or "Art that looks thematically like it was sketched, but also feels solid enough that you could lean on it" it's very difficult for software engineers to "just" fix the software to get rid of bugs because what's a bug? Only the puzzle designer knows for sure what they intended.

[[Spoilers! Do not read if you are still playing or might play]]

Is it a bug that "Swimming Trunks" don't let you swim? No! That's a Dad Joke. They're Trunks. Large locked wooden boxes. They're in the swimming pool, and if your pool has water in it, that means they're swimming.

When I picked a time from my near future in Shelter, it didn't work, that's a bug right? Nope. The Shelter cares about game time, not real world time. Make sure you know the date in game.

OK but is it a bug that being in Clock Tower at the Sacred Hour doesn't have any effect? Um, maybe? It seems as though the software doesn't believe clocks repeat, so only the first time will actually work. Or, maybe the second does too? It's hard to say. Try again?

I need food but somehow I keep digging up keys and money. That's a bug right? Nope, probably means you have made a Contraption which changed your dig probabilities.

OK, so that's also why my Door facings are weird even though I put my Compass-based Contraption in a Cloak Room? That one's probably a bug.

Still, "If you draft it quite late" ought to mean my Music Room has the key right? Well, maybe, what did you think "Quite late" meant?

"I thought after a few hours would do it". Huh. Well, maybe. "OK, what about Rank 7?". Rank Nine would be better, but it might be enough, depends. "I still get no key, are you sure this isn't a bug?". The most likely problem is that you've done Music Room. If so the most likely key to wrongly believe you did instead is Vault, although Station is also possible. Check the other locations.