GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Source: C# Programming Yellow Book

3 min read

Source metadata

  • Type: Textbook (free online)
  • Author: Rob Miles
  • Edition: 8.1 (December 2019)
  • Scope: Foundational C# programming — data types through object-oriented design, collections, and debugging

Key takeaways

  • OOP in C# is built around classes as blueprints and objects as instances; encapsulation via private data + public methods is the central discipline.
  • Enumerated types (enum) provide type-safe named states — superior to using raw integers for state tracking.
  • Inheritance lets child classes reuse parent behaviour; virtual/override enables controlled method replacement; base calls the parent implementation.
  • Interfaces separate the description of behaviour from its implementation, enabling polymorphism and easy substitution.
  • C# properties (get/set) combine the ergonomics of field access with the control of methods, and are how the .NET library exposes data on all its types.
  • List<T> and Dictionary<K,V> supersede ArrayList and Hashtable — prefer them always; they are typesafe and avoid casts.
  • Test-driven development: write tests before or alongside code; game-specific caveat — gameplay quality cannot be unit-tested, only code correctness.

Notable claims

“If it is a data member (i.e. it holds data) of the class, make it private. If it is a method member (i.e. it does something) make it public.” (§4.5.2)

“A static member is a member of the class, not a member of an instance of the class.” (§4.6.1)

“Every time you need to hold a bunch of things, make a List. If you want to be able to find things on the basis of a key, use a Dictionary.” (§5.1.4 Programmer’s Point)

“The other kind of program that is very hard to test in this way is any kind of game. This is mainly because the quality of gameplay is not something you can design tests for.” (§4.5.4)

Relevance

This source grounds foundational C# OOP concepts that underpin all Unity scripting beyond beginner scripts. It is the primary source for:

What was skipped (dated or out of scope)

  • §3.6 File I/O — rarely relevant in Unity game scripts
  • §4.3 Structures — superseded by classes for most use cases; Unity’s built-in structs (Vector3, etc.) are better covered via Unity docs
  • §5.4 Threading — Unity has its own threading model (Coroutines, Jobs); raw C# Thread usage is out of scope
  • §5.7 GUI — Windows Forms; entirely dated and irrelevant for game dev
  • §4.12.6 Delegates — covered in Unity context via UnityEvents; the raw C# delegate section is too thin to stand alone

Open questions raised

  • How do C# interfaces relate to Unity’s component model — is MonoBehaviour itself an interface implementation?
  • When should a Unity script use a C# interface versus relying on GetComponent<T>() to duck-type behaviour?

Graph View

Backlinks