Which part you hate the most when making games?

Supporting multiple input methods that can be used in multiple contexts(e.g. in-game and in menu) is a pain in the ass.

 

Everything not code related

 

Getting up to poop.

 

You can just RDP in from your laptop

 

programming and generally doing gui stuff - for me it's one of those things that just 'needs to be done'.
This and lack of time. All things around me that distract from coding

 

Ahaha..agree with you!

 

Not knowing how to do something.. or specifically the best way to do it...

 

Visual art design.
Well, I don't hate it, I'm just not an artist.

 

How long it takes to get stuff done.

 

When creating a master server application. The security and efficiency parts are difficult for a beginner like me. The commercial options are too expensive or limited with the CCU limit rules and the free options are too inflexible or do not offer good supports. But it is highly essential for most games nowadays

 

Texturing and animations.
As a programmer I'm not very good when it comes to art. Modelling or drawing some 2D Sprite can still be fun, but I lose motivation pretty fast as soon as I have to make some animations or textures.

 

Spending week on writing few hundreds lines of code on certain functionality, realizing I can make it within fraction of the size and time.

Also, rewrite prototype, of prototype, of prototype, to make it better. I mean, results and learning curve is highly satisfactory with learned new tricks and methods. But is just the fact annoying, doing same functionality over and over again, approaching multiple times different ways. Hopefully each time cleaner more performant and more modular.

Just on opposite site of the coin, if I may add, I love integrating stuff. For example custom modules and assets, while keeping them decoupled.

 

Following a tutorial and realizing that it is outdated.
(which, can mean anything from deprecated code to non existent functions or menus)

(also for those of you that create youtube tutorials, please at least run the audio through a compressor or limiter).

Also, doing some R&D on something, which starts out as a simple google image search, then following the rabbit hole and ending up on trying to read some siggraph whitepaper involving math which is completely outside my league.
(have lost count how many times this has happened)

 

This.

 

Discovering a core system in your game isn't going to work as planned, and requires a redesign or replacement.

For example, I have a couple years now of work into a networked game using Unet. The HLAPI has been working fine, but reliability problems came up under just moderate load (nowhere near the number of players I had planned for the game) that are in the closed source LLAPI making them difficult to troubleshoot and probably impossible to fix on my end. I finally decided to replace Unet, even though it is integrated throughout my project, and after investigating alternatives I decided the best way forward was to develop my own networking solution from scratch.

Between stopping feature development to investigate the problems in the first place, time developing my own solution, and the time to replace and integrate, I'm looking at at least a 6 month delay to my project.

 

This. Redesigning and replacing is a brutal process.

 

Some things I dislike about game development:

• replacing a unity feature
• implementing a missing unity feature
• poor or outdated unity documentation
• unity bugs

Oops! Looks like all of those game development problems are Unity's fault. But Unity's benefits far outweigh the faults, so I continue to develop in Unity.

 

None of what are people saying are my problems.
My biggest issues is probably something that is everyone's issue.
The difficulty and near impossibility of making rig's and animations, especially for characters/monsters without motion capture software.
Manual rig creation and animation is a pain in the ass and extremely time consuming with bad results.

I can figure out coding issues, importing issues, lighting stuff can be dealt with and get the result you want. But with animation/rigs no matter the time spent you wont get those smooth good looking sword swings or run loops its just impossible without mo cap and good auto-rigging software/algorithms.

If i were to pay for something in unity, it would be something along the lines of AI/Machine learning assisted auto rigging based on indications you provide like Mixamo but 10 times better thats what we need.
Also the software should include auto rigging of cloth/gear/armor etc which currently is impossible in blender.

UT recently unveiled a new feature at Unite (In berlin i think) for future iterations where you can use AI machine learning to generate animations and states without manual setup, thats simply amazing i hope they continue on this path of adding lots of knobs and buttons to such a system where you can customize in 1000 ways, no more manual rigid animation and manual setup states that dont trigger as you want to.

 

It can also be extremely rewarding feeling if your domain was so well designed that the redesign was a breeze. Like when we scrapped Forge Networking and wrote our own solution, the low level stuff took 2 months but because of good abstraction we didn't need to change one line of code in the domain.

 

Light Settings -> Bake

 

Indoor lighting, I'm just terrible at it.

 

Doing something I already done twice again.

 

Light Settings -> Bake -> Wait one hour > crash > start all over

 

I have had my project on realtime for months now (with gi) so I don't have bake times. The visual quality is virtually the same but obviously, there will be potential performance issues (currently it's quite fast). It is however, something just perfect for dev.

 

Anything GUI related. It always feels extremely time consuming and tedious for something that seems like it should be simple.

 

You don't use the standard shadows then? The directional shadows are ok, but point lights are just awfull

 

Initial response was UV-unwrapping, but I actually sort of look forward to it now. Just put on some good music or an audiobook and work through it. Blender has some nice tools after a hiatus.

So maybe.. UI setup?

 

Sales. If I could just make games and not have to worry about the market... that would be bliss.

 

the second 90%, the polish to perfection, i just want to move on. i know its important to making a good xp but man does it feel like a slog most of the time

 

Anything close to level design. I can make the prototypes and use whatever characters you throw at me and make it work. I'm just not a level designer. I love the type out the code and debug every bit of it until it's running exactly how I want it and still feel interested. If I have to make a level, I actually hide from my laptop.

 

UI design, ick

Also when something is working and then it randomly breaks for no reason and wastes your whole weekend fixing it

 

Y'all need to F***ing hire some artists and designers, goddamn.

 

Is it just me, or are good people specialized in gamedesign and level design much harder to find than e.g. artists, coders or composers.

 

Yes for game designers, but that's mostly because everyone thinks they can be a game designer but not everyone thinks they can be an artist.

 

Yeah, It's also harder to see a portfolio of a designer like it is an artist and judge if they are good or not. So many decisions in video games are team made and so even if a designer has good games to their name, you can't always trust it was their design... :/

 

I should clarify that I meant UI designers.

Because I really can't lie to you all anymore.

Y'all have some ugly-ass interfaces in yours games.

 

I use the shadows that come with HDRP and everything is perfect and crisp, including point lights. Reason being is because in HDRP you get to choose where the resolution goes. Builtin renderer is an all or nothing thing.

For builtin, if your point light shadows suck you can consider using a cube cookie, which can help in both performance and visuals.

 

Cool, didn't know the realtime resulution had changed too

Edit: how is draw call count? The old renders realtime mode is not an option were performance is needed like VR

 

we dont

 

VR support is really coming along nice in HDRP. They will announce it loud when it's properly supported and it's a top priority. You get control over the overall atlas size for all lights, but also per light you control the shadow resolution, so you get some pretty awesome control.

What I love is that it's pretty well culled and you can fade shadows from lights independently, really good amount of control. Allows you to keep resolution really high. That's kinda a must in VR. As for performance, I think it will rock but only if used sensibly

This is off topic. You ALWAYS manage to veer us off topic. I love you man

 

What's a forum without off topic! Sounds good sadly we will probably not have the resources to convert all our assets to the pipeline :/

Oh, that's another thing I hate, the whole thing around scene performance. The domain performance is fun. But scene performance is another beast, hate it. Partially because I'm not knowing what I'm doing, and partly because unity is fubar. For example I try to optimize lightmaps by putting relevant parts in the same lightmap system, only to find out that unity completly ignores my system tags. And that mean the engine can't batch since it can only batch two meshes that are in the same lightmap system

 

Lightmaps are not necessarily going to be faster than realtime lighting + GI (ie no baked). This only works if you have an aggressive LOD merging scheme (hierarchical LOD) - because then the number of draw calls are minimal and batching has no issues because there's nothing to split the batch, and far off meshes are merged into single lumps which doesn't stress draw calls.

But that's a bit too late for your situation.

 

LOD1 and greater use ligh probes not lightmaps. But in VR you cant switch to LOD1 too quickly for large objects because its too obvious cause of the large FOV. We have close LOD1 for all small items and try to switch to LOD1 as fast as we can for larger structures.

 

In my case, the code is only a tiny part of the process of redesigning something. Most of the time involved is in either figuring out the game concepts, figuring out the presentation, then testing/debug and play testing/usability.

Because our game has a lot of game design decisions like dramatically different ux considerations and combat logic, different play phases and modes, different play balance issues, etc - the game design aspects far, far outweigh code considerations.

It's also way more exhausting to revisit. I can't tell you how many different designs I've had to go through for literally every aspect of game play.

 

Depends on which system that needs refactoring, but yeah, we are going from s simple ballistics system were only distance was used to calculate damage. And the new will use velocity and bullet weight etc. But will migrate by scripiting all prefabs so they will convert to the new system using the old settings as convert base

 

I think if you look at games (and frankly, most software) the main point of complexity is always in user input and user control. If you go through your own game - by far, the most detailed systems revolve around user input.

Most of the time, the complexity in those bits and pieces isn't really just code - it's making sure the ideas are the right ideas. Are the goals correct? Is the overall user level design correct? What other systems need to support this one? What kinds of issues are we going to run into later? How do we test this? What impact does it have on other systems?

Just to be clear - none of those questions are about implementation detail - all of those are user level. When I say "what other systems need to support this one" I mean like what UX concepts need to be created, what kind of visual feedback do we need, etc.

Honestly, in my experience - "the code" itself is probably the least of my concerns in most cases.

 

Then maybe you are good at coding, many programmers fail to do large refactors because of lousy maintainability of their domain. Probably more common in game Dev than traditional programming since there are more hobbyist in that sector.

In VR there are much much more complex input than desktop and a new item could mean complete rewrite of existing systems to be able to support the new requirements. Could be the reason why you see so much wierd mechanics in VR, they fail to incorporate new features in the existing code base.

 

Yeah - I think one of the accomplishments in VW is definitely the stability of the user input. Compared to most VR work - it's just clearly smoother (especially when you first released it). I might have different taste in code or whatever - but in my mind - the end result is what matters and the end result input in your game is definitely solid.

Maybe that's true. It's definitely the case that a lot of the other work (UX, etc) is stuff I'm just not good at, and maybe this is a major reason why it takes so much labor to get it right. Ultimately, I'm not a great game designer, and not even a remotely good UX designer, so when I need to wade into those waters things get painful.

 

Thanks man, and alot of that is because of a solid maintainable code base, we couldn't have responded to all our users requests and feedback if we didn't have a pretty agile domain. Offcourse we have code smells, everybody does

 

Unlike what many people have said, I like the idea's more than the grunt work. I am too impatient for it.

I love texturing models, but the rest is just something to get through to see the end.