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.
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.
The docs are poor at explaining this.
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).
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.
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 :o 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…
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.
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.
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.
.