What Do You Spend Most Of Your Game Dev Time On?

I am curious how you folks spend the majority of your game development time.

For me, I've always spent around 80% (maybe 90% at times) of my game dev time on R&D.

For example, currently I have returned to my FPS Action Adventure and am spending time researching, designing, developing and testing ways to handle enemy navigation.

The reason for this is simple. In all of the years and frameworks I've been working on game projects there are always a lot of holes in the canned solutions. Sometimes just functionality is outright missing and other times it just doesn't make sense to me the way it is implemented.

Enemy navigation is one such case. It seems the common approach is to use A*, waypoints and NavMesh.

In my mind I think something like this should be fairly straightforward and easy to work with.

In my current design, I see it all as simply a matter of defining obstacles and then gathering forces from around the enemy that motivate it to go one way or another. Basically, the distance value from the casts can be seen as a force perhaps even as "pain" in a sense. I just flip around the distance values so close ends up having a higher force value. Much like steering behaviors themselves. This seems quite promising so far.

In my experience it just seems like people have always made things way more complex than they need to be. Or way more limited than they should be. And that results in me doing some research for alternatives and ultimately that usually ends up with me thinking about the problem at hand, coming up with a few different things to try out. And after I spend the time on R&D on those and can see the pros and cons of each I am much better prepared to come up with a final solution and that is what I end up implementing.

This stuff happens constantly in game dev. For me at least. So like I said, about 80% of my time is spent on this kind of R&D work. I do this because I feel the need to. Otherwise, this time would be focused on the actual game itself and I imagine I'd be making bigger games and more frequently.

What do you sink most of your time into?

 

This one is hard to answer because it's more about "what iteration period are we in to do a certain task", and at what stage of development are we at.

 

Around 80% of my time actually coding is spent on bugs in middleware, other people's assets and Unity workarounds or looking for documentation. Very little coding time is spent on actually coding with C#.

This isn't an estimate of thinking time, which is variable, I might do it in the shower even. But it's fairly surprising it's usually someone else that is causing me problems, be it asset authors or Unity.

If we are talking about thinking time, then R&D by far sucks up the most (and R&D isn't for a better solution but THE solution, and is nearly always a game mechanic). I don't really R&D optimisations for instance.

 

For me there is a mood I want to create and that has to be done via graphics and music, to a lessor extent voice. Creating gameplay that can expose that mood is also no trivial matter.

 

This is a great topic really. It asks "where does the time go" and "how badly could Unity explain it's own features". Did you know that you can use root motion and drive a physics-based rigidbody physically with forces AND use navmesh? Really, up until a couple of weeks ago I didn't.

1. The docs are poor at explaining this.
2. No learning materials attempt to hint at it.

The only way I found out was to repeatedly search for clues (ie burn a lot of time not developing). It indicates only a small part of Unity is able to think in the minds of it's users.

I hate to sound critical of the docs team. I think they're doing their best but stretched way too thin to ever become properly comprehensive and keep up. There should be a ton of extra attached material for each Unity feature, covering all the use cases it can potentially do, not just scratching the surface or giving super-basic explanations (sometimes none at all).

Please invest here, Unity.

 

Most of my time is spent rewriting the existing code...

 

At the moment as I'm still in the 'honeymoon period' most of my time takes up figuring out how to do things, from scratch, which involves searching/googling.

If I already had these resources to hand and I new what the code was or the process, I'm guessing the vast majority of my time would be taken up on modeling, texturing and animating easily, haven't bought anything of the asset store of yet, which might be a blessing in disguise, so my scenes are models are practically all done from scratch including animation.

Music and sound also takes a bit of time, to cut the tracks up. Adding atmosphere, and actual gameplay involves having an idea then trying to practically implement it if possible.

 

Testing and fixing stuff.

 

Most of my time goes into R&D, which as @hippocoder points out - is difficult when most of the Unity internals are locked up *and* not documented. I'm looking at you SkinnedMeshRenderer docs, you've wasted a week of my life trying to fix an issue because a little catch was not documented.

 

I would say alot of my time is spend into research and trying to see if the concept I have in my mind is already explored by someone else and might explain it better, maybe even with code example so I can understand how to implement my ideas...alot of that has probably also to do with me not knowing all there is to know about C# and unity, so sometimes it turns out to be something "basic" but at the same time, because it's so basic it's hard to find (I find myself currently somewhere between being newbie and mediocre programming and it seems very difficult to find tutorials, specially video tutorials where I don't have to jump over most of the stuff to get to what I want to know, sometimes thats eating alot of time too)
Else than that I would say I'm spending alot of time in the concept phase and graphics also I want it to look as best as I can and I usually have a very precise image(s) in my head of how I want the game to look like, so trying to execute that takes time and I'm a little perfectionist....

 

Documenting my story properly and graphics.

 

Great post, so true!..

 

Am I the only one that spends most of my dev time actually writing code? At least on my own projects.

On my recent game jam project most of my time was spent on intergration. But if I was to do it full time I'd write the editor tools to take over for me.

Edit: Okay, that's a lie. 70-80% of my dev time is sucked up by the forums.

 

May I file my time on the forum under R&D? If so then I spend close to 100% of my dev time on R&D .

Do you have some links about that, that you could share? It sounds really useful.

 

Not really Martin. Don't generally keep links and it would be why I made my comment: it's so obscure and I would need to google for a week again. But it is actually hinted at in the docs, just never followed through. Basically you add a navmeshagent component and update it's internal velocity and position while reading the desiredVelocity parameter.

They do point out how to move it under non physical control, but not how to control it with physics correctly, which is kind of a valuable point. Plus then there's cars, other things - obvious things - which are missing.

There's no point to making things easy to use if they're still not covering basic use cases in the docs. I get it, obviously, but my complaint is many won't.

 

Same. Research is a fair portion as well.

 

Graphics are definitely the most time consuming part, I would submit - and also one of the less important ones.

 

For sure there is a big time-sink dealing with other people's code/unity code problems, be it bugs or just getting to grips with the behavior. Another big one is finding the appropriate piece of documentation in order to write the proper code to do something... the API is so big and complicated I can't hope to remember it all which really slows down coding. At least half my coding time is spent trying to understand how Unity wants me to do stuff or whether it's even possible.

Another big chunk I think is figuring out how to use what's available to get the artistic result you want... often times the idea or design seems simple but the simpler and more elegant it is, it turns out that this requires even more layers of code and abstraction to get that final outcome. The translation between ideas and 'computer language' is still a big pain. Especially in 2D areas, I find there are so many things I have to do due to Unity being a generic engine that should take mere seconds to achieve but end up taking many minutes.

And then there's the graphics... yawn.

 

Unfortunately most of my time is spent dreaming about how awesome my game will be if I could only get it to work

 

What stops you from getting it to work? That answer might be one of the things in the list or something not in the list that should be.

 

Although I really don't intend for this to be a "hammer at Unity" thread I'll definitely say I agree with you about the API or understanding the Unity Way (how Unity wants us to do stuff). It is odd really. For so many people it seems like Unity makes perfect sense to them and they just "get it". And even more strange is it seems like complete beginners with no prior experience are some that find it the easiest of all.

For me it has been a real struggle. It is something I still struggle with. I want to get it to click and it is just not there yet. It does seem like (as you stated) even doing the simplest of things sometimes seems to require layer upon layer of "stuff" that needs to be done. And to me I also see that is complexity not simplicity.

I guess it all depends maybe on what a person has worked with in the past and what we are used to? I think I remember you mentioned working in Blitz many years ago.

Much of my time seems to be spent on R&D trying to understand how to do what to me seem like pretty basic things. And actually using other frameworks would be. Yet trying to figure out how to easily do it Unity it is crazy how much time and effort it takes.

I think we just need to click with it. Get what they are thinking. Or maybe they (Unity) just need to spend more time explaining what they are thinking and how this dev kit is intended to be used. What I would love to see is an example like so this is how you did this kind of thing in Blitz or Direct3D and this is how we do it here. I think sometimes the difficulty for me is this thing just works so differently than anything I have ever used before.

 

Most of my time goes into polish. The amount depends on the game, but I'd genuinely guess that it's over 80%. Making something "work" is easy. Making something that I'm comfortable putting in front of others and then shutting up about? That's a whole other story.

The challenge for me is knowing which things need to be polished, and which things I can get away with being mostly just functional.

 

They don't have to unlearn other methods. I've had similar issues at various points with other languages due to knowledge of older languages and the usage patterns I had built up with them.

 

Several people at the game game last weekend were running briefings to get people up to speed. Best summary of the unity way I heard:

The advice did me wonders. I'd never intergrated an animation from a Sprite sheet before. Turns out you can just drag and drop. And so on for just about any task in unity.

 

This. I've heard a number of experienced/skilled software developers explain things such as that "Unity uses a component-oriented approach instead of doing things properly with [some other method]". It's not just Unity, of course. It's just human tendency to stick to what we know instead of embracing the unknown. We're naturally resistant to learning things if we feel that they go against stuff we already know.

Plus, the first few times we do it, it is indeed genuinely challenging. So there's not just the above, there's also the legitimate temptation to revert to methods which we know might get us faster or better results in the short term. And sometimes that is indeed a better way to go, as long as we don't fall afoul of the Sunk Cost Fallacy in the long term.

 

I'd have to agree with this too. I can do pretty much anything in Unity. It's the environment I really dug into learning code.

If I was ever to step outside of Unity I would end up trying to implement the component based structure and banging my head against the wall.

(At least I assume so. I've not venture far outside of Unity. Unity is my safe place. The world of not-Unity looks pretty big and scary.)

 

Prototyping mostly (visual and interaction targets). I take design requirements and concept art and turn it into a functional prototype to assess technical requirements and iterate on the visuals, vfx, and ux. Once direction is locked down, I then typically continue to polish it for final implementation. Occasionally these prototypes (or videos of them) are used for marketing/promotion or to aid in the approval process from the Lucas story team. Of that work, about 40% is coding, 40% is art (2d/3d/ui/vfx/shaders), and 20% meetings. Aside from prototyping, about 15-20% of the rest of my work is tools to improve art pipeline. And a very, very small part of my time is pimping the game at cons.

 

Today I'd say artwork and idea's take up 70% of my time, it's not easy to fill big worlds (or sub-worlds in my case) full of stuff. I spend 10 % of the time coding and / or fixing engine issues and 10% fretting over performance, 5 % of my time in meetings and 5% just wasting time really.. Well on some days I spend 100% of my day wasting time, but that's neither here or there ..

In Unity I spent a lot of time on workarounds / coding and shaders, well actually most of my time.. In Unreal I've not tended to do that anywhere near as much.. Artwork is the issue it's such a slow process uhhh!, with BP's things don't take long to get cooking once you understand Epic's way of doing things, which is rather odd at first..

 

It seems to me that over time engines have become more advanced and have taken the coding/logic/functionality stuff to a whole new level in terms of automation and automagic ... etc... but it seems that far less progress has been made in the area of content and media. Other than finding some pre-made stuff on an asset store, there isn't very much different in how much time it takes to create quality art assets. I guess in some ways there are new tools and people are shifting to using vectorgraphics and stuff to simplify, or tools to help with animation, but still the `king` of most designs is the artistic content and it simply still takes a very long time to make quality content for a game. Most programmers struggle with it. Most engines have not addressed it (although at least there is an asset store which sort of helps). I suppose there are procedural texture generators and better photoshopping tools and stuff...but still... most successful games have good quality art and it still takes a lot of work.

 

The problem with art assets is nobody wants their game to look the same as other games, it would just look like a clone. Code is different. I don't see how an engine is supposed to address creating art and sound. Since sound would not be any different.

 

That does seem true to a large degree and on the other hand I rarely make it to the point of even thinking about graphics because I am focusing on the core stuff first. For me the challenge is just in doing the basic stuff.

I'm getting there though. Just takes time. And one thing I've realized is that creating custom inspectors and so forth (even Grid systems and such) is required in Unity not an option. If you want to do anythjng but the most basic stuff I mean.

So I am thinking about spending time just R&D on custom Editor components. I *think* that will help tremendously. Probably a no brainer to most die hard Unity devs but I never really got that bit until time and again I find myself saying "if I just had some actual data to easily work with like if I had a simple dang grid here in the editor that would help lot". So that has helped very recently for me to see what I think may be the Unity Way.

I had always thought Unity just had all of these things built into it... somewhere... just a matter of finding out where. But now I see it like basically it really is just a shell and we're supposed to be writing our own layers of stuff on top of the Editor. Might be wrong. That is just where I am now. lol

 

Rewriting sucks up a lot of my time.

I open up a project and freak out about how badly it is planned/written/commented, and think up new ways to make it better. ~ I'm talking about my own projects by the way. I've redone one of them like 4 times, though in my defense it is 6 years old.

EDIT:
I also do a lot of editor scripting nowadays. If you can make Unity do more of the hard work for you, why not?

 

Yeah the editor is basically saying "mould me to the game".

 

Well I'm surprised they haven't found solutions to tedious stuff like UV mapping yet in a more sort of "all in one solution"..

I know there is a lot of controversy over level editors via engines, but having art tools in any engine would swing it for me. Because at the moment I use seven art tools to get the job done, so Modo, Substance Designer, Z-brush, topoG, Quixel, Substance painter, Unreal (for blockouts).

Unity is about the only engine I've ever tried that doesn't have major import /compatability issues, it's such a pain. Even between art tools it's messy.. Imagine being able to skip scale testing, exporting, uv mapping issues, level design disparencies, animation compatability issues just to name a few..

Imagine how many months if not years of development that could save you.

CryEngine apparently has started taking notice, not a fully featured set yet but it's getting there.. Unreal has BSP and a basic version of photoshop (you can de-sat / grade textures etc.).. I think it'll get there one day, literally an all-in-one game development solution. Download one engine to do it all and when that day comes I'll be doing happy spins on the floor..

 

Sounds sort of like what Autodesk is going for with Maya and Stingray

 

When I tried Stingray it was just an update button to copy it from Maya to Stingray, I guess it bypasses .FBX but didn't really make a difference. The shader things was cool though...

It's getting there, but no cigar yet.. The only one I've seen so far that comes close is Source Engine..

 

Definitely game mechanics. I stopped trying to make full games years ago. Every unity project now is just a collection of experiments that might be useful at some point in the future.

The rest of my game development time is spent inflating my unity forums post count.

 

Bugfixing.

Then fixing the bugs that the bugfixing introduced.

 

This would be awesome for layout - but I don't think I want the game mechanics/creation environment having to worry/mess with vertex weighting, rig creation, and mesh editing. The engine is for game play, and functional development, not asset creation.
But would love it for level design and layout. Unity would definitely have to update with multiple viewports. At least 2 viewports for layout.
Level design, Layout in Max is so simple and intuitive compared to Unity.

 

You know you can do this now, right?

 

With the latest version of Unity you can even do it with different scenes at the same time. (As I understand it anyway, I've not yet tried it).

 

I spend most of my time trying to make time for game dev. And then when I finally do I spend way to much time getting back into a groove, but then run out of time and struggle to get back to it within a week.

 

Hands down, I have to agree with hippocoder on this. I cannot stress this enough.

I've timed myself quite thoroughly. Above everything, I find a massive time sink in Unity's flaws, Unity's lack of documentation, Unity's quirks, or Third Party Asset bugs or bugs I create by not fully understanding a Unity concept or the middleware (which IMO is less my fault, and more the lack of a clear explanation for some things / lack of good documentation.)

Here is an example:

Implementing any one feature, all on my own:

Adding a new feature (my own code): Nearly always 3 hours. (This includes redoing a feature, improving it, or anything really. A single task seems to always take 3 hours. If elementary, it still takes about 1 hour no matter what.)

Complex Feature: Usually around a full days of work, maybe two if I have to research or engineer something I don't have experience in. (Procedural Generation comes to mind, as well as adding any major system like the initial GUI system or major gameplay mechanic.)

Problem with Unity or 3rdPartyAsset: Whatever it is, it nearly always consumes a full day of work PLUS an extra hour the next day. (9 hours total). This is when I can't find the answer readily or I have trouble understanding the (often non-existent) documentation.

Learning Middleware: Nearly always 9-18 hours. That's min/max, but usually is 9, 14, or 18 hours.

Although not all assets are created equally. Forge networking, for example, takes me about 10 minutes to fix a bug or implement a new feature. It's wonderful.


---------------

I would like to add to this (as there are only so many bugs in middleware, and only so much you need to learn before Unity stops giving you problems).

Using Unity.

The Inspector, the Editor, and the "Play Mode".

This consumes an enormous amount of my time. So much so, I try to automate as much as I possibly can (and even then, it still takes most of my time.)

For example, I recently spent 3 days creating prefabs for all of my items in Unity. I don't have that many items yet, is the thing. This means a lot of boring, repetitive tasks.

1) Create new Prefab
2) Rename Prefab
3) Attach scripts or double check duplicated prefab for correct scripts
4) Change settings of scripts
5) Set graphic, collider, etc. Configure prefab for game.
6) Attach any debug scripts or temporary scripts.
7) Test prefab, to make sure it all works well.
8) Run game, and hope to god I don't accidentally edit a script during runtime (although the "Panic Button" has really helped here.)
9) Hope Unity doesn't lock up, crash, or freak out.
10) Hope I don't accidentally delete or edit the prefab later, making me do all this over again.

Anytime I can automate this with scripts or write actual code? It's usually very quick & easy. Even complex things don't take me that long to write, test, or refractor. Even if I haven't touched the code in months, it is still pretty fast & easy to read through & refractor. Even when I have to constantly make simple referrences to the docs, it's pretty fast & easy.

When I have to read OTHER people's code or understand OTHER people's way of doing things? Oh god, it takes sooooo long! Anytime I have to mess with Unity by using a lot of mouse clicks & keyboard presses? That time adds up.

The documentation is horrible. I really wish they would press to have the best docs in existence. It would add a tremendous amount of value to their engine.

Also this. The "Unity Way" is sometimes just ludicrous / irrational. Although I am pretty sure I've finally reached the point where everything I'm doing has been covered in past research already. So this isn't draining my time now, but it sure as hell did in the beginning... and I'm almost certain it will again when I go in to tackle a lighting system or custom shaders. Ugh...

 

manipulating models, textures and lighting.

The amount of coding I can get done in 4 hours is amazing, but I can easily waste the same amount of time getting the lighting and vegetation right for a very small area of the gameworld. I spend way too much time on shaders for environmental objects.

 

YES!
Of course I knew that - before I just tested it

 

I am glad to hear someone else seems to actually have the same struggles with this thing that I do. I am basically exactly the way you described. If it is just programming things myself it is easy. I mean just design it and build it. Simple. But interfacing to Unity or 3rd party assets and just trying to understand and use the Unity Way is where it all breaks down. Because just like you said it often just seems so tedious and time consuming as well as simply illogical.

In fact, I often find myself thinking "are they intentionally trying to make everything take longer, be more involved and tedious than it should?" and because I know that cannot be the case I am now focusing on learning the Unity Way as deep as I can. I just want to really get it.

Anyway, very glad you posted this. Thanks!

 

I don't get why you say it isn't for asset creation? Back in the 90's it was common practice (level editors etc.) and a lot of AAA engines do have fully functioning art systems more powerful than Maya (or even built on Maya)..

It's not that it shouldn't be done, the fact of the matter is there's a metric ton of things that Unity need to sort out before it ever became a consideration. Even then it'd probably be better if a middlware company were to handle the duties..

 

It's my own personal opinion - as a game engine company Unity should stay focused on creating the best possible game development environment they can.
External art development tools will always be superior than anything a game engine company can incorporate into there engine, and the art tool companies will always be ahead of the game.
Relying on Unity to stay current with up to date workflows for modeling, texturing, UV, normal mapping, sculpting, rigging and skinning would be troublesome, and would require resources to be reassigned from keeping the engine updated as a solid development environment.

The current light baking system is a good example to support this opinion.
The current state of the lighting (baking) system is troublesome and has been a constant issue since released. Since light baking is something that could be handled by any 3D package externally, with comparable or better results - I think a much better solution to import externally baked information - could have been considered.

I agree that static level editing and UV tools would be nice but, when getting down to sub-object level editing, vertex, complicated UV editing, rigging & skinning and character setup which requires a high degree of finesse, I'd prefer to do outside the game engine.

I can't remember any publicly available engines that had fully functioning art systems. Maybe proprietary engines but those were always tools custom created for the current game the company was working on. Not a complete custom Art package like Maya or Max. If I'm wrong - thanks for the clarifying.

Now if your suggesting Unity buy/partner with a company to develop (add-ons) to be plugged into the engine, I don't see anything wrong with that - as long as the (import) pipeline stays open enough for artists and developers to use whatever (external) tools they prefer. I cringe at the thought of Blender being tacked onto Unity and being the defacto mesh editor, rigging tool.

 

Where is the poll option for bugs and workarounds?

Sure most time is actually spent on code, playtesting, tweaking code/values, art, animation depending on your game... but the time for me that is spent on just getting things to work that really could and should easily be handled better by the engine and editor is the part that annoys me the most even though it probably isn't where most the time is spent, it just feels that way.

As a description of the problem I currently have right now doing the UI, I'm frankly getting tired of the prefab system.. it just isn't good enough, it sucks (bit like remaking a project and the best Unity can offer for a description of a missing script, shader is.. well just that its missing.. really can't be bothered to store some sort of last used filename that it knows is missing but not what :S) .. And especially using ugui and trying to skin elements and improve default style for ui components (ongui has the guiSkin system), but for ugui making big changes to ui components and wanting to base other similar type components off of that main one.. nope, better off writing code to handle passing down those changes. what was the point of ugui again? its been left for a year now without any real improvement added by Unity or anything to complement its existence.. ie the feature of the next paragraph...

Nested prefabs and inheritance, it should be core and higher priority as it sits in the dev roadmap not something people need to go buy an asset for (which I feel like unity benefits a lot from more so than any other engine, but it seems like a crutch for them to not bother bringing that stuff into the core engine/editor themselves in any sort of meaningful timeframe, when they still get a cut from the asset store and don't have to bother adding it, for me if the asset is going to play a core aspect in how I use Unity for a game, then the last thing I want to do is buy asset and become reliant on a third party)

Right now its a frustration and I've given up on prefabs for different ui components to drag and drop.. you could end up wasting time setting the same things over and over again without proper way of inheritance and ways to manage it, same with redoing animations for a different ui components even though it would just be easier to have some quicker way of re-targetting existing animations to work on (you can sort of do it but its a hacky workaround)

Thus having to write code to get components and a main interface in which to adjust all colors, sizes, styles for multiple ugui components etc

Which makes me feel like many features Unity add are half baked implementations, before they move onto something else without properly finishing and polishing what they started. 2015 ugui was fixing bugs surrounding it, and adding a few more to it before the year was out. Hell even working with ugui is pain, having to use assets like https://www.assetstore.unity3d.com/en/#!/content/34807 just to make working with ui components a little quicker, then the lack of grid layout snapping (yeh next up find something for that).. aah the whole thing is just an unfinished mess to work with and it really shouldn't be.

2016 the current roadmap for unity features it really doesn't thrill me, seems like most the good stuff is in developement the alternatives are improving is it greener yet i dunno.

 

@Player7 what you are describing is what I lump under R&D. Spending effort and time just trying to figure out how to make things work. It involves continual tests, trial-and-error until eventually we figure it out. And I do agree it is crazy how much time is needed on this. It is not normal. But maybe it is a trade-off for having the visual system to work with (the Editor). All I know is when I have used frameworks in the past (purely codebases) it never took so much time. Of course, like I said, there also was no visual component to it either.