artemis

art "semaphore" everfree

serotonergic daydream

prismatic swarm

fractal multitudes

evershifting

theta delta ampersand

bi/pan/poly

this user is a furry


Do you talk to the computer as if it could hear you? Does it ever talk back?


posts from @artemis tagged #ramble

also:

everfree predecessors - the hunt (2015)
the hunt (2015)
everfree predecessors
00:00

hey volume warning this is louder than other stuff we post (if you have listened to our other stuff here) because im not going to add even more compression artifacts to this 128k mp3 to normalize down the gain.

this is the first full track we ever made. it's pretty cool honestly? at the time i think we were really iffy about sharing it because we assumed we couldn't be proud of things until we Got Good (and because it didnt sound anything like our music idols at the time).

rambling about skill below



i wrote this game in java, 2 or 3 months after i started learning programming by making my first minecraft mod. it's not a very good game- but this is because I didn't yet understand how to come up with ideas for good games.

the code is bad. I haven't seen it in years, but it's probably really bad. Does that matter? No. When you're writing a game, the code only has to be good enough to finish the game. I was only able to make this because I didn't care about if the code was good.

"Good Code"

The thing that I wish I understood when getting into coding, is that what makes code "good" is situational. A lot of people giving programming advice online are doing so from the perspective of working in an "industry". Here's some common scenarios:

They are writing code on a medium or large team.

They need everyone on the team to be able to understand the code to make changes. They need people to be able to gain that understanding quickly by reading it, because people do not have a shared mental model. They don't necessarily read all the code other people write as its written. They might go on vacation for a week and need to catch up. They might have been hired on a few years into the project!

They are writing a project that will last a long time and need to be changed a lot over that time

Like an operating system. Or a bad startup app. Or an MMO. Or a game engine that just will not ever die coughbethesdacough. You need to be able to keep working on these for quite awhile, maybe indefinitely. And these projects often get really, really big as they expand to do all sorts of random stuff. The less of a project that can fit in your head, and the longer you need to work on it, the more you need to prioritize making it easy to rediscover the project piece by piece.

The program needs to run for a really long time without problems

Perhaps many times longer than it will take to even beat the game you're making. Are you memory leaking 50 megabytes of ram an hour? It'd be nice if you fixed that, but you probably don't actually need to care. Services Georg who runs 50 copies of their server and only restarts them once every two weeks definitely does.

Sometimes they are just elitist

and think that if the code doesn't meet some arbitrary standard they've set, it's not worth existing. stay away from these people.

Anyways, the point is,

these concerns are usually not the concerns of a small indie game you and a couple friends are putting together. Your code only needs to be good enough to

  • make the game do what you want it to do
  • make the game run where you want it to run however fast you want it to run
  • let you make the changes you want to make up until the point the game is done

beyond that, dont worry about it. Seriously. I've seen so many people try to get into this stuff and fail to get anywhere because they spent all their energy worrying about writing the best code, constantly rewriting to make the code better and better.

Improving your developer skills is a worthy goal, but it can come later. On later projects, on more ambitious projects. Spend some time after you've made something, trying to rewrite a part of your project in a better way. Focus on improving the parts that genuinely frustrated you when making it the first time. See how you like your changes. See if its really better or not.

When you actually need to care the most

OK, here's where you need to care, for real: networked multiplayer, in memory-unsafe languages. Does your game do networking? Did you write the networking code yourself? Did you use C/C++? Great (sarcastic) news, you might accidentally write a bug that lets a player hack another player over the network.

My recommendation? Get help with the networking. Use a library for it. Be very careful with any data that comes from other players. Or, you know, maybe just use a different language. C and C++ are perhaps the most unforgiving languages for a newcomer to work with, in general.

Anyways, that's my anti-perfectionism post for the $TIMEPERIOD



once upon a time you could write a program that did something, and that was the end of it. no internet connection, cool. and you can still sort of do that I guess. as long as the person only has the one computer. if they have more than one computer, for a lot of programs, you're gonna want to sync data between them or the program just isn't useful. That's true of say, a calendar. or a plural system organization tool. a password manager. maybe your documents or your photos. a phone is a computer by the way.