Game Engines 2021W Lecture 2: Difference between revisions
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.
- 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