Best practices?

News & General Discussion
1

I’ve heard a couple of times on this forum that I’m making my game in a unlogic way. So what is a good tutorial or book to design my game in a smart way? I don’t want restart creating the game again because of the way I’ve started designing it.

2

Way too broad of a question. There are some design patterns that have been proven to work well in a variety of game designs. Unity itself uses a component-based design for GameObject’s, for instance.

At the end of the day, if the code is maintainable, extendable, and performs well enough for your game’s needs, then it’s good. Beyond that and you’re into subjective style issues.

If your game’s scope is small enough and won’t increase, it may not be that hard to achieve all three of those.

When the scope starts getting larger, established techniques become more helpful. It’s often helpful to lean on what others have done thousands of times, but it’s not always necessary.

Anyway, here’s a book on that topic that I actually have not read myself, but looks interesting:

It can be more helpful to ask much more specific questions and even post some code.

3 Likes
3

Thank you for the tip.

For everyone who wants to read it for free, the author has an online version for free.
http://gameprogrammingpatterns.com/contents.html

4

Designing your game play? Designing your game’s presentation? Designing your game’s scripting/class structure?

…like… what are we aiming for… here…

5

Designing the game’s scripting/class structure and the structure in Unity.

I also found this: 50 Tips for Working with Unity (Best Practices) – Dev.Mag

6

It’s just software.

I will advise…

  • Creating task-based components that do one thing and naming them in a way that explains what they do (generic tasks that will be used on lots of unrelated GameObjects). Add public editor parameters so you can tweak values for each instance or prefab in the editor.
  • Creating a controller class for each game object that contains logic. Like an enemy, or a menu. It should have awareness of the relevant GameObjects.
  • When possible, when GameObjects depend on other game objects to exist for their scripts to do their tasks, create an empty GameObject and place these related objects within.
  • If a task requires two or more different components’ jobs to be done, create an appropriate public method in the controller class to handle it.
  • Use GameObject.Find() on Start() to get your references only if you are sure the object you’re looking for is going to be there and the objects are not related in any other way, but still need awareness of each other.
  • Use Manager classes to do higher level tasks between controllers.
  • Use public static methods on your Manager classes when you can, and make the singleton reference private within the manager class, it’s cleaner than creating references within instances.
1 Like
7

Are you talking the design of your code or the design of your game? For game design, consider checking out The Art of Game Design by Jesse Schell. Some say my podcast is also helpful (see sig). Code is a different topic - I’m personally fond of the Jonathan Blow school of thought.

Gigi

1 Like
8

That’s very interesting. Although I haven’t taken it to the extreme he has with favoring large blocks of code… in general I agree and arrived at basically the same conclusions. Actually just wrote about this a few weeks ago in one of my dev logs.

I personally find value in refactoring large blocks of code into smaller more task-oriented blocks of code if only for the sake of being easier to debug. But in general I agree with much of what he is saying.

Basically summarized in this bit from the log:

As time passed and I continued to embrace the latest & greatest ideas in software engineering I noticed that although they had value solving various problems they also added layer upon layer to the development requirements. So, in a way this is a test of stripping out a lot of the modern practices and dropping back to a more “old school” development approach. More straightforward. Less to think about as far as applying the modern development philosophies. And instead taking me closer to a more pure development approach much like I used a long time ago.

1 Like