Game Engines 2021W Lecture 2: Difference between revisions

From Soma-notes
Created page with "==Notes== <pre> Lecture 2 --------- * set timelines, guidelines, due dates * getting started in godot * designing a game engine 30% journal 10% participation 60% project -..."
 
No edit summary
 
Line 1: Line 1:
==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.
* [https://docs.godotengine.org/en/stable/getting_started/step_by_step/ Godot Engine step-by-step], read & do the exercises through "Your First Game"
* [https://willnationsdev.wordpress.com/2018/04/07/godots-node-system-part-3-engine-comparisons/ Godot's Node System, Part 3: Engine Comparisons].  Also look at [https://willnationsdev.wordpress.com/2018/04/05/godots-node-system-a-paradigm-overview/ Part 1] and [https://willnationsdev.wordpress.com/2018/04/06/godots-node-system-part-2-framework-concepts/ Part 2].
==Notes==
==Notes==



Latest revision as of 17:46, 14 January 2021

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.

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