• she/her

Recently appeared on this plane. Last seen: Posting (in a serif font) and/or casting spells. my icon and header image are turned around on purpose actually its not like i dont know how to fix it or anything. my age is private information but if you feel the need to know it presume i'm somewhere between 18 and the age you are and treat me accordingly


geometric
@geometric

you should not be a 10x engineer or whatever, you should be focusing on the vision and ideas and emotions that make your project interesting and beautiful and touching. some of the greatest indie games of all time have absolutely nightmarish codebases because the creator was rightly focused on the player experience


YellowAfterlife
@YellowAfterlife

And really - unless you work in a big team and can afford a departure the from the actual work, you should consider whether you really need something to be done in the fastest/most elegant way possible.

Even if the solution is a bit of a hack, you can always come back to it later if that ever becomes an issue.

And indie games are often small enough that "come back to it later" becomes "keep this in mind for the sequel" if the game is well-received.

Once finely put into words by a friend, "While you're optimizing your Entity Component System, folks are shipping their third GameMaker game".


You must log in to comment.

in reply to @geometric's post:

makes me think about how sometimes I'll write a shader or do some code or sprite that's really good

TOO good

so I have to make it shittier because I'm like, is this what I want the standard of the rest of what I do on this game like? and the answer is, haha nooooo

This is why i never release albums. By the time I’m “done” I’ve managed to make a song good enough that it makes the older parts of the album feel not good enough. And then the cycle begins anew lol

code is different because the player experience can be identical whether your code is a mess or not. Everything else you listed is player facing and its improvement will be felt in the end product.

sure, it can be identical, but i think it's wrong to say that it generally will be, personally my experience with code tends to inform the stuff i can do with gameplay, visuals, etc. it fundamentally changes my approach to development, and so influences pretty much every aspect of the game. without code experience i might not think to implement my player movement in a specific way, or to write a specific shader that influences the visuals of my game without the significant experience i have with code

also like, even if those the disciplines you listed were inherently more important to player experience than code (which as i said, i really don't agree with), i still don't see why that'd mean being "good enough" at them to finish your game isn't still the way to go, as you said you should be focusing on your vision and ideas, which doesn't necessarily mean great art or writing or anything specific, it all depends on the game

god, 100% agree. i'm all for striving to make things faster and less computationally expensive, but in my eyes video games are almost completely at the "art" side of the spectrum, and for that reason i think any technical means justify the end of it existing at all. it's not a coincidence that some of the best games are this way. i dont care that your rendering pipeline takes 0.2ms to render, i just want to see the little dude move around funny.

there are some parts of the code you should take the time to do right. The more unrelated systems that need to interact with a thing, the more solid you'll need it to be. If it's a system that's at the core of the entire game, one extra day of planning today could prevent a month of frustrating bug whack-a-mole that gets in the way of you adding the stuff that matters. But if it's just one enemy type or one weapon that's self-contained? Churn that thing out in ten minutes by whatever means you can! The worst thing that can break is itself.

i broadly agree with you that gamedevs get way too stuck on trying to make everything bulletproof, but learning when to be careful is very important wisdom too. It mostly only becomes an issue in larger projects though... and everyones' games are too big, which i suppose is the real problem!

in reply to @MrMandolino's post: