What Is The Hardest Part Of Gamedev?

This is probably related:
https://wiki.c2.com/?FizzBuzzTest

1 Like

Maybe this says more about me than about game development, but finding and nurturing relationships with collaborators that share even some of your creative values, priorities, and work ethic is the hardest part for me.

Marketing is missing on this list.
How many devs even think about it, before actual release, until is too late.
Especially apparent for small teams of up to handful devs.
See as an example, number of kickstarters projects with 0 followers on the game title.

2 Likes

I am going to expand on this @koirat and say “Strugging with someone else’s API…” it’s not just limited to game engines. I integrate a LOT of other third-party APIs (advertising, tracking, attribution, live ops, etc.) and for every minute I spend figure out a Unity API, I spend perhaps two hours figuring out other weird APIs from companies where clearly it was the interns who actually wrote the code.

1 Like

There’s an interesting time axis to emergent complexity too: you can spend an intense weekend or week of getting some feature going, and it all seems very nice and tidy and operational, you understand it all, you’re happy with it, and then you put it aside for six months or a year, and decide “Hey I ought to add X to that feature!”

Then when you pick it back up you are absolutely BOGGLED by the complexity of what you made in a week of intense hacking, and it takes you massive effort to sort out what is going on, and you’re still not 100% sure if a particular construct you see is actually a bug, or if it’s the right way because “man, it sure seems like it ought to be parented to THAT thing, not this thing,” etc…

4 Likes

What side of it? Like the drag and drop gui or the actual items?

Drag and drop is probably the most annoying gui thing to code in general.

1 Like

Basically it’s code written to isolate and hide away the complexity of one or more systems.

Just recently I had to implement achievements and every platform we were supporting has a different way to do this. Without abstraction code a developer wanting to unlock a trophy would have to execute multiple methods to do so but with the abstraction code I wrote it’s just one method that unlocks the trophy.

Additionally we have a platinum trophy but only one of the platforms has them so the code that handles unlocking the trophy checks for that too and unlocks it if the requirements are met.

+1 for marketing, probably because it’s my most hated topic and because I’m very bad at it

You probably misunderstood, they just wanted to turn this topic into Unity-beating fest, like they are doing with every other ones.

7 Likes

so an abstract version would be one function that says when an event is triggered, then sends out a message, and whoever is listening for that message will do their own thing with it. Right?

like, player kills 10 crabs, send the killed 10 crabs event, then each platform specific achievement script is going to do what they want based on that event getting put out.

Yes.

Aye… and the number of ways that small teams justify NOT marketing is manifold.

“People will see how great our game is and just flock to it!”

“Our game will be so amazing it will make a big splash!”

Remember, while I was typing the above three lines, probably about 27 more games shipped to all asset stores combined worldwide. Oh wait, 28, 29, 30 augh…!

2 Likes

I think about two weeks into starting to learn to code for Unity, I sat down to code my first inventory system and promptly went “I have no idea how to do this.”

So I shelved that and learnt some more stuff. After learning more about abstraction, inheritance, polymorphism, Interfaces, etc, I sat down and took a proper stab. And after some futzing about I had a working inventory system with items using Scriptable objects.

And then I spent this past week completely reworking it because, turns out, having a different class for each item type (inheriting from a base class and sprinkling in Interfaces) does not make for a fun system to manage the code of. Now it’s just the one class for an item, of which has a list components instead.

So for newbies like myself - as has been mentioned a bit - a lack of experience can definitely make it harder and cause you to code yourself into a difficult spot.

And on topic, being new, I’ve only had trouble dealing with a few of Kurt’s list. Movement, inventories, UI. No doubt the rest I’ll have to deal with in time. I think Saving is next on the list for me.

4 Likes

The hardest part is holding on to your sanity.

This website doesn’t help.

3 Likes

Looking back at the list, I have to agree with “tutorials”. Oodles of edge cases, code to check for all the stuff the player is meant to do, code to detect if they’ve gone off-script and to get them back if/when they want, content to support it all, and changing a bunch of that each time you iterate… which will be many times, because you need to reliably teach stuff to a player, and that’s much harder than telling a computer what to do.

Even the lame old “pause the game until the player presses the right button” style tute requires a bunch of custom UI, events, etc.

Pretty rewarding to make a good tutorial and see the impact it has on players, though.

2 Likes

Actually yeah, project management in games is probably the most difficult. Like you said, you never really know if you got it right or didn’t waste a lot of time and money, whether the problems that had to be fixed should never have existed in the first place or whether they were somehow evolutionary to the game.

It’s easy when everything’s a hobby and everyone’s just messing around, but as soon as you treat it like everything you spend is valuable and could have been spent elsewhere, everything becomes questionable.

That’s what’s fun about it though, so I don’t see it as being very unpleasant, but it’s certainly the most difficult to get right.

Gamedev is funny, the newer you are to it, the more unbridled energy you have. So even if you have to redo things over and over because you scoped too big, or make some noob mistake, you push through and eventually get it done, thrilled to be learning cool new things and you wake up with vigor to do it all over again.

As you get better and make better decisions/ less mistakes, you are mostly going through the motions, churning out functionality that produces the proper thing you know will work, but the thrill is gone.

I would say the hardest thing about gamedev is throttling the line between doing something fresh that will keep you developing and pushing forward, while also doing something you know will be tried and true, producing results.

Oh bonus hardest thing of gamedev: Waiting impatiently for your creative energy to strike you again as you wallow in burnout, inching closer to a worthwhile project.

Thrill is fine here but I started dev in 82 so I’m not sure I know what the real world actually is.

My advice for people is not to try too hard. It’s always better to compromise. If this means only using features Unity provides out of the box, and compromising on the game, this will likely make many people a lot happier than some ill-contrived magnum opus.

3 Likes

I really wish this was small enough to put on a teeshirt and pass out at GDC.

I suppose another way I like to put it is, “Ship the game.”

2 Likes

I don’t think there’s anything wrong with aiming for a magnum opus. The problem is that it is equated to ‘working in an intoxicating haze of ‘inspiration’ without having a clue what you’re doing until the bank account runs dry’.

There’s no excuse for not having a basic plan, and some idea of how one’s demonstrable capabilities and resources will achieve what is in it. If all that lies between someone and their magnum opus is a hell of a lot of work, cool, if they can pull it off so much the better.

But if what lies in between is some vague notions of grandeur, and no work has ever been demonstrated that could conceivably be part of the final envisioned result, it’s simply an illusion.

Except that usually the first half of doing so requires 90% of your bank account, and the second half (minus the polish) also requires 90% of your bank account, and then when you actually have people play it in public you realize that you need ANOTHER 90% of your original bank account (we’re up to 270% of your bank account for the non-numerically challenged) to make it a worthwhile game that anybody even bothers to boot a second time.

This is why EVERY developer needs to put proper eventing into their games. Most developers who do this are stunned to find out that a MASSIVE fraction of their users never run the game a second time, and a whole awful not never even make it out of the main menu, let alone complete the tutorial.

2 Likes