[ca6d8815]

> Just out of curiosity, when you spent 9 hours at work, was that in a software field?

Yes, however the day job and night project were _completely_ different disciplines. Someone wrote that gamedev isn't really software engineering... I'd agree with that (not putting it down, but its not like anything I've done).

> If so, why would you choose to do the same thing 18 hours a day for 5 years?

Those long days came in the last 1.5-2 years. Why? I don't think we would have finished otherwise, or at least not anytime soon.

We found that momentum for us was critical. If we took it easy, then it slow days would turn into slow weeks and it would turn into slow months. We wanted to finish at some point. Even when we had a slow week or day, or when we'd go do something that wasn't the game, there would be a shadow of guilt that we are not finishing. I think that is personal, everyone does this differently.

And the second why? The reward loop of doing something with a realtime 3D game is simply joyous. I would sometimes have _so much fun_ making the game that on the good days I dreamt of quitting the day job and starting up a studio full time.

When the dust settled though, it took me almost a year to think about using the computer at home for anything other than playing a game or reading news / experimenting with homelab stuff. The burnout was harsh.

I don't regret it... but I'll never do it like that again.

[pizza234]

> Someone wrote that gamedev isn't really software engineering

Could you elaborate on that? I find this perspective very interesting.

I had a brief experience with gamedev, and I've actually found that even the smallest bit of game engineering is significantly more challenging than (I suppose) "x%" of web development.

However, on the other hand, the engine is only a part of game development (and can also be underengineered, and I think it generally is), so maybe this is actually the reason why you/other people don't consider game dev software engineering?

[ca6d8815]

> Could you elaborate on that?

I can try, but I may not do the idea justice.

When I was working on the game, the only thing that mattered was the _game_. Was it fun? Intriguing (we are a story based walking simulator)? Original? In line with our story structure (we wrote the story side by side of making the game because sometimes the best words on paper just couldn't be translated by us to a player experience)?

You make changes non-stop to iterate and tweak and perfect. You learn quickly that someone's gut feeling can kill an entire chapter of the game, or change the ending completely.

At some point, my code was just a tool in making the game. I didn't see myself carrying this codebase further to other projects (we built the game on Unity so already writing an engine was "solved"), so it just turned into working prototype after working prototype.

Your code doesn't have to solve for all the corner cases you may miss in QA, because in our game the state was almost guaranteed at different parts of the play through. You need to remain extremely flexible with your design and code because its possible the game shifts drastically under your hands, more so than I've ever experienced at an already-chaotic "big" company.

So it just stops mattering that much. At least for us. We didn't have a team for code (just me), or a separate art team, or a separate story team, or even a single game designer throughout the project. Everyone wore almost every hat, and you lose the grace of planning and process.

It's more a feeling than something I could quantify exactly. An interesting reflection is that I became more rigorous and detail oriented at the day job after the wild west of my game code.

[animal531]

I think I know what you mean, but I'll counter and say that instead of just focusing on completing the game one should pay some attention to longevity and re-usability of your codebase.

For example I have things like a KD-Tree implementation/wrapper that will always be useful, a maths library, a HexGrid component I use a lot, wrappers for rendering a lot of things fast, an entity system for units/objects, a generic framework/layout for code/objects in Unity etc.

But having said that, it really depends on the type of game that you're making.

[BlargMcLarg]

On top of what the others said, you basically answered it with "However, on the other hand, the engine is only a part of game development". Game dev is one of the most technically complex subfields of software dev, but it still pales in comparison to the total package of disciplines (and skill levels in those disciplines) to make a game.

Compare a basic CRUD webapp to a game. Most webapps won't need stellar art, it just needs to look okay and have some logos or default assets. Games often need to run their own assets for uniqueness, have way more freeform art, you name it. That includes pixel art, the often lowest barrier to entry. Animation? Webapps generally don't need animation beyond some default practice tweening, most games require animation to make things feel smooth and actually give the feeling things are happening, on a vastly higher level than simple tweening of color and position of some flat objects. Audio? Where the average person hates the embedded autoplay video/audio, games generally require at least sound effects, preferably a sound track too. Storytelling? Unless you count the average buzzword-filled marketing video as storytelling, webapps don't need that. Marketing, collaboration, etc. are all factors that come to play as well depending on corporate size, so depending on your goals, you will run against those too.

There is much more too. Psychology can play a huge part if you don't just blatantly copy existing things, and it is far more difficult to map a vague "I like this / I don't like that" than a business requirement. If you don't require animation, in all likelihood you're either creating a game in a genre where other demands are higher (visual novels with higher storytelling and individual art asset demands), or you'll be outcompeted if you don't have something to stand out, in which case one could argue the load is shifted to other disciplines anyway.

Maybe most of all, you generally don't need to develop content in most webapps: you are enabling users to create content themselves, whereas in gamedev, you are more often providing them with content. Of course this comes with exceptions (What about Sims? What about Rollercoaster Tycoon? What about mods?), but most games deliver at least some content developed by the makers of the game themselves. Or you spend days agonizing over algorithms to generate content in a way that makes it fun, making tons of art assets players can fiddle with, etc.

[Sohcahtoa82]

> Could you elaborate on that? I find this perspective very interesting.

In addition to what others have said, game development places a massive priority on optimization and performance.

You have to write code that updates game state and renders a scene in under 16 ms. CONSISTENTLY under 16 ms. Otherwise, you get stutters and choppiness as it fails to maintain 60 fps. If you want to please your top-end PC gamers with their 144 hz monitors, you need to render each frame in under 6.9 ms.

With a web app, you can make up for underperforming code by scaling horizontally. That's simply not an option for game development.

[ajuc]

Normal software engineering is 95% glueing libraries together.

Gamedev is mostly about iteratively changing some equations to make the thing behave like you want it to behave.

Disclaimer: I never worked commercially in gamedev, but I wrote a lot of games as a hobby. Most of them unfinished of course.