https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Game_Engines_2021W_Lecture_3 2026-05-13T02:39:46Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Game_Engines_2021W_Lecture_3&diff=22833&oldid=prev 2021-01-19T16:18:25Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Lecture 3 --------- what is the best game engine? - and what does this question even mean? If time and effort are no object, the best game engine is the on...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 3<br /> ---------<br /> <br /> what is the best game engine?<br /> - and what does this question even mean?<br /> <br /> If time and effort are no object, the best game engine is the one you built yourself.<br /> <br /> Why?<br /> <br /> - it supports exactly what you want to do with minimum effort<br /> - because if you built it, why wouldn&#039;t it be that way? :-)<br /> <br /> So, we don&#039;t nowadays build our own game engines because we want to save<br /> time and money<br /> - current game engines are very powerful, would take a huge amount<br /> of personal/team effort to duplicate<br /> <br /> Nevertheless, some teams do maintain their own engines<br /> - licensing<br /> - you already have it<br /> - it is known to the team<br /> - in-house knowledge facilitates customization<br /> - it is suited to the type of games your team makes<br /> <br /> For &quot;interesting&quot; game development, the most important game engine feature is<br /> extensibility/customization<br /> <br /> games, at their heart, are rule-based systems<br /> - the rules are the heart of gameplay<br /> - the rest is the interface<br /> <br /> game engines inherently limit the kinds of rule-based systems you can build<br /> - because they are built with certain assumptions about what a &quot;game&quot; looks like<br /> - they have to make those assumptions in order to speed up game development<br /> <br /> So using a game engine makes lots of tasks easier, but at the same time<br /> it gets in your way the moment you want to do something &quot;different&quot;<br /> - an interesting game is one that is doing something different from<br /> past games<br /> - kind of like research, if it is the same as what has happened before,<br /> why not just play the old game?<br /> <br /> What sort of games/game mechanics will be challenging to implement in<br /> most game engines (unless there is a specific extension)?<br /> - procedural generation (code-generated levels)<br /> - you&#039;re going to be doing this on your own mostly<br /> - detailed simulation games (beyond physics)<br /> - AI based (other than simple rules-based AI)<br /> - economic simulations/reactive worlds<br /> <br /> Game engines are built to facilitate specific parts of games<br /> - graphics and sound<br /> - movement of objects/appearance of scenery in 2D/3D<br /> - keyboard/mouse/controller input<br /> - networking<br /> <br /> Note that the assumption of objects moving in 2D/3D space can be limiting<br /> - what if the space doesn&#039;t follow normal physics rules?<br /> - non-euclidean games<br /> - dynamic particle/surface movement?<br /> - time as a dimension?<br /> <br /> The space of possible 2D/3D images/animations &gt;&gt; 2D/3D easy to build in a game engine<br /> - they have assumptions on what you want to build<br /> <br /> 2 games come to mind<br /> - Portal<br /> - changes spatial relationships fundamentally w/ portals<br /> - Braid<br /> - can reverse time, turns platforming into a puzzle game<br /> - but is also a game mechanic, because some things don&#039;t reverse<br /> - fez<br /> - bizzare spatial arrangements<br /> <br /> <br /> How do we get game engines?<br /> - built to facilitate the creation of specific games<br /> - then are slowly generalized to deal with other games<br /> - never completely escape their origins, although<br /> they can grow beyond them<br /> <br /> How does this compare with general software development?<br /> - this is exactly what has happened with mainstream software development<br /> - we have tools/libraries/frameworks to support standand applications<br /> - really, facilitate key interface and functional pieces<br /> - as developers, you often more assemble pieces than code components<br /> <br /> When you make a GUI, you use standard libraries/frameworks<br /> - get consistent interfaces this way, users know how they work<br /> - don&#039;t want to change the rules<br /> <br /> But with games, we often *want* to change the rules<br /> - if it is completely predictable, it&#039;s boring<br /> - learning is key to games<br /> - simple games have replay value because we&#039;re learning about other people<br /> as well as the rules<br /> - basis of competitions<br /> <br /> speed running is all about testing the limits of the rules of games<br /> - exploit the bugs!<br /> <br /> when you make a game, you are playing with rules<br /> - game engines implement specific rules<br /> - you&#039;re going to want to change some of them to make an &quot;interesting&quot; game<br /> - changing rules =&gt; extending the engine<br /> <br /> What does software engineering tell us about extensible systems?<br /> - we know that dealing with legacy code is hard<br /> - legacy code =&gt; code we didn&#039;t write (or forgot about)<br /> - modifying any software system means dealing with some degree of legacy<br /> code, i.e., other people&#039;s code<br /> - true for game engines as for anything else<br /> <br /> We have a strategy for working with other people&#039;s code, abstraction<br /> - just have to learn the interface, not the implementation<br /> - but all interfaces are leaky<br /> - reveal details of implementation<br /> - constrained by implementation<br /> - huge source of bugs<br /> <br /> So, if you can&#039;t write your own engine, the best engine is the one that<br /> - makes standard things easy<br /> - facilitates doing custom things in the easiest way possible<br /> <br /> Note these two requirements can be contradictory<br /> <br /> What are the arguments in favor of dynamic typing?<br /> (Static typing is so much better because it catches errors, right?)<br /> - JavaScript, LISP, Python<br /> - quick development of prototypes<br /> - why?<br /> <br /> Dynamically-typed systems are inherently more extensible<br /> - because they don&#039;t assume anything about data types<br /> - will just try, and throw errors if something doesn&#039;t work<br /> <br /> Static typing<br /> - the type of all symbols is known at compile time<br /> <br /> dynamic typing<br /> - type of data associated with symbols is only known at runtime<br /> - a symbol can refer to any data<br /> <br /> Dynamic typing facilitates programs that adapt and change to new tasks<br /> <br /> Statically-typed languages have very complex mechanisms to try and get<br /> the benefits of dynamic typing with more safety<br /> - templates, generics<br /> <br /> Godot does use dynamic typing natively<br /> - but supports statically-typed languages<br /> <br /> But I&#039;m thinking more philosophically<br /> <br /> Lisp is the ancestor of most dynamically-typed languages<br /> - JavaScript is, roughly, just Lisp in drag (C-style syntax)<br /> <br /> What was Lisp used for?<br /> - artificial intelligence<br /> <br /> Why?<br /> - flexible representations/rules<br /> <br /> With game engines, we ideally want as few constraints on what we can create<br /> - should be flexibly extensible<br /> - so, we should be able to adapt existing facilities to new purposes<br /> <br /> This sort of flexibility is facilitated by uniform building blocks<br /> - think legos<br /> <br /> For game development, you want to deal with legos as much as possbile<br /> - avoid melting plastic when you can<br /> <br /> Godot is more flexible than most game engines because of key design choices<br /> - focus on generic nodes<br /> - dynamically-typed extension language<br /> - editor built in game engine<br /> - editor itself is extensible/modifiable in same way as games<br /> &lt;/pre&gt;</div>

Soma