Official 5 Tips for Writing Better Code in Unity | Unite Now

5 Tips for Writing Better Code in Unity

As your project’s ambitions and codebase increase, so does the risk of spaghetti code. In this session, we share 5 programming patterns and techniques you can consider implementing into your project to achieve a performant, clean, and reusable codebase.

Find helpful Unity documentation here.

Find the sample project here.

 

video unavailable

 

I only saw 50% of the Video.
Pls let me watch the rest.

 

I only looked at the beginning, then i stopped the video. It was actually more of a video on how not to write code. No wonder that the video is no longer online.

 

Yeah a couple of us watched it and oh no. @AskCarol, whoever's in charge of having these created needs some better quality controls.

For people who didn't see it, video spent a lot of time explaining the pros and cons of C# arrays vs. Lists, being completely convinced that a List is a LinkedList behind the scenes. It's not! It's array-backed. Most of the times in the video where the List spent a lot of time doing things would've been fixed by passing a single parameter to it's constructor.

I can't quite remember the rest of the advice, but I seem to remember that it ranged from mediocre to bad, so.

 

@Baste was that video, with how list is managing memory?
I don't think that vid was targeted for beginners anyway.

 

I have no idea who it was targeted at.

The first "tip" was "this is a mangled beginner's explanation of what inheritance is", and the last one was "let's do a deep-dive on the memory allocation of List<T>, except everything we say is wrong".

 

Why on earth is this still pinned?

 

Sad I missed it, would have been fun to watch. The constructor overload on a List that takes initial capacity should have been a hint its array backed

 

Thank you everyone for the feedback. We removed the video to fix a correction in describing a List and Linked List. We’d love to hear your continued feedback so we can continue to improve upon our content. In particular, any feedback around programming topics that you believe would be the most beneficial to the great community is always welcome!

 

Is it about "tips" as in the title of this video, or are you looking at larger topics?

My main suggestion is to get videos peer reviewed by industry experts before you release them. I didn't see the above video but if it's as others have described... yuck. Get yourselves a panel of programmers and a panel of artists from games we would recognise (who's relevant teams are well respected) and get them to watch stuff and give you feedback in advance.

My second suggestion is to steer clear of stuff to do with code optimisation when you're targeting beginners. Writing clean code is far more important than writing fast code for the vast majority of cases, and clean code is easier to optimise if the time comes in any case.

What's the goal behind this? That'd help us suggest topics which are actually relevant.

I haven't looked at them for quite some time, but most of the examples from Unity I remember seeing are all of relatively simple versions of things. That's cool for someone learning to make games, but it's useless for people going from small projects to large ones. So, it'd be great to see a variety of games picking and examining a major system that's of particular imporance for them: how they designed it from both a gameplay and development workflow perspectives, what worked, what didn't, and how it impacted both the development work and the game itself.

For example, in an RPG how has a team such as InXile managed the inventory system throughout the scope of games such as Wasteland 2 and 3? There are plenty of examples of how to make an inventory, that's not actually the interesting part to me. What I'm interested in is the broader integration of a relatively simple piece of functionality within the context of a larger game.
- How is the content managed? The simple cases are trivial, but when you have things such as localisation, integration with quest systems, and a large team of people all potentially making changes...
- What are the workflows for things that need to integrate with the inventory and its content? Eg: if I have an item unique to a quest, how is that managed?
- How did the team go about designing the overall system? What were their up front requirements and why were they important? What custom tools did they make? How did the design of this system (and its workflows) impact the design of the game?
- How did all of the above tie in with the game's QA and testing? This is a kicker for many small teams, who are often literally learning about software testing as they go.



Looking at more beginner focused stuff, information about how to write clean and maintainable code as I mentioned above would be great. I'd also suggest demonstrating optimisation of non-code aspects of a game, since that's likely to have a far bigger impact on most games than custom scripts. (In fact, please start by debunking the idea that "draw calls are evil".) Event-based programming is another big ticket item to look at, though it requires that people are writing clean code to begin with. On that one I'd look at event usage strategies rather than just the code to make events work.

For all of the above, the really important thing is that you don't stop at "how". You need to get into the "why" of things, otherwise people can't make informed decisions about one approach or another. Who remembers when people kept trying to jam their whole GUI into a single draw call?

 

More stuff.

Version control, and why everyone should be using it. Don't make this an advert for Unity Collab or Plastic, though both should definitely be covered.

Automated builds / continuous integration. Again, not an advert for the Unity service, though it should definitely be covered.

Automated testing. Cover a bunch of different approaches, the pros and cons to each, and where each one is most likely to be useful for different types of projects.

Localisation. Why would you do it, how do you prepare for it?