Game Engines 2021W Lecture 2
Resources
You should go through the Godot engine step-by-step or equivalent, as it gives a good introduction to Godot. The articles from Will Nation's are optional but are good if you want to better understand how Unity and Unreal compare to Godot.
- Godot Engine step-by-step, read & do the exercises through "Your First Game"
- Godot's Node System, Part 3: Engine Comparisons. Also look at Part 1 and Part 2.
Notes
Lecture 2
---------
* set timelines, guidelines, due dates
* getting started in godot
* designing a game engine
30% journal
10% participation
60% project
- proposal
- progress report
- presentation
- report
Report, due at end of exam period
Presentations, last week of classes, Apr 6 & 8
- 5 min presentations plus questions
- please use slides
- no demos, no time
- maybe short video clips?
Progress report due early/mid March
- March 8/15
- PDF
Proposal February 5th
- PDF format
Build something in or extend Godot
- flexible
- non-trivial
- be interesting to you
Journal
- weekly updates on what you've been doing design/implentation wise
- should have technical problems you are encountering
- Due on Mondays 11:55 PM (midnight is always ambiguous)
- I'll create a bunch of submission due dates in cuLearn
- graded on participation/attempt
- about a page, whatever that means to you
- can be long, but at least a few hundred words
- until the midterm report
- first one due on this Monday
- can be very simple
- plain text or PDF please
- markdown is great
- can certainly include pictures, if so PDF please
- I prefer sentences to bullet points, but you can use some bullet points
- just make sure it is easy to understand
- this is the place to do rough drafts
- fine to grab content from journal for proposal/progress report/final report
Project specifications
- do something interesting, original
- using Godot
- assets/code should be yours, authorized, or CC/open source
- credit should be given
- either a game, an app, or an engine extension
A simple game with a technical or design challenge is fine
- don't "fluff it up"
- small and interesting is better than large and boring
Grading scheme for final report
30% report quality
writing/clarity
organization
10% references
60% technical quality & creativity
- split will depend on what you did
The hard part of this is deciding what to do
- but that is part of the assignment!
- and I will provide lots of feedback and guidance where appropriate
Understanding Godot
- download from godotengine.org
- but version from Steam, your Linux distribution should be fine for now
- games organized into scenes
- scenes made of nodes
- nodes can be almost anything
To learn about Godot, start here:
https://docs.godotengine.org/en/stable/getting_started/step_by_step/intro_to_the_editor_interface.html
- read about the editor, scenes & nodes, instancing, scripting, signals
your first game
- after this, you'll have the basics
Go download Godot, play with it, report what you did by Monday
- in class on Tuesday we'll answer your questions
- and we'll start/continue with figuring out potential projects
Visual Studio Code is for browsing/changing the code of Godot itself
Desiging a game engine
Game/App
*Game Engine*
OS
Hardware
The perfect game engine would make it very easy to write the game you want.
Earlier, game engines and games were co-designed and developed
- think Doom
- you'd come up with a design, make a basic engine and level editor,
then build your game, enhancing the engine to do things as
the game required
Game engines have become "good enough" that most developers choose to use an existing engine rather than start from scratch
- but non-trivial games almost always extend the engine in some way
Ultimately, the engine has these responsibilities
- get user input
- display game state
- update game state based on user input, game progression
- if multiplayer, have to get input from all players, coordinate
At this level of description, this isn't that different from any application
Classic design pattern is Model-View-Controller, what I discuss above is really just that
But games are different
What's the difference between a Word Processor and a Game?
- performance matters?
- game state can change without user interaction (sometimes)
- wildly different?
When you make a game, what makes up the game state can be almost anything
- and it may need to be updated in arbitrary ways at arbitrary times
- suduko, solitaire, tetris, FPS, simulation
- can turn almost anything into a game
This all means that game engines potentially need to support arbitrary abstractions
- we need abstractions to describe how a game works, looks, & sounds
The painful part of using game engines is matching the natural abstractions of your game to the facilities the engine provides
- the closer your game is to the abstractions the engine provides,
the more likely your game is boring
Games are distinguished by how they work more than how they look
- and how they work is defined by interactions between abstractions
So how can a game engine best bridge this gap?
- by being extensible!
One of the distinguishing characteristics of Godot is its abstractions
- Scenes and Nodes, that's it
Godot seems to be much better suited to arbitrary application development than other engines
- but this is a debatable point
A good game engine
- makes standard things easy
- makes non-standard things possible
Extensibility
- how can I encode my ideas in the engine?
- two basic ways
- scripting
- extensions
Scripting is for adding functionality to existing abstractions
- changing how a player interacts when they run into a wall
- maybe it should trigger a trap!
Extensions are for adding/changing abstractions
- adding a level editor to the game engine editor
- abstraction is the levels
- basically, provides custom input method with validation
Shaders I would say is a kind of scripting
- fitting inside of an existing box
This split is common in CS
- think web browsers
- also have scripting, extensions
- comes up whenever you make a platform for creating applications