digm520admin – Page 19 – Steven Lilley

Notes on Research Paper: Automatic Game Progression Design through Analysis of Solution Features by Butler et al.

digm520admin / 2019-11-19 / Procedural Generation, Research, Thesis

November 19, 2019

Thesis Research

Notes on Resources

TITLE:

Automatic Game Progression Design through Analysis of Solution Features

AUTHORS:

E. Butler, E. Andersen, A. M. Smith, S. Gulwani, and Z. Popović

IEEE Citation – Zotero

[1]E. Butler, E. Andersen, A. M. Smith, S. Gulwani, and Z. Popović, “Automatic Game Progression Design through Analysis of Solution Features,” 2015, pp. 2407–2416.

ABSTRACT

– use intelligent tutoring systems and progression strategies to help with mastery of base concepts

as well as combinations of these concepts

– System input: model of what the player needs to do to complete each level

– Expressed as either:

– Imperative procedure for producing solutions

– Representation of features common to all solutions

– System output: progression of levels that can be adjusted by changing high level parameters

INTRODUCTION

– Level Progression: “how game introduces new concepts and grows in complexity as the player progresses”

– link between level progressions and player engagement

– “Game designer Daniel Cook claims that many players derive fun from “the act of mastering

knowledge, skills and tools,” and designs games by considering the sequence of skills that the

player masters throughout the game [11].”

– *** Why we want to have system produce similar but varied versions of the same type

of experience

– “Intelligent tutoring systems (ITS) [29, 22] have advanced the

teaching potential of computers through techniques that track

the knowledge of students and select the most appropriate

practice problems [8, 12].”

– “We aim to enable a different method

of game design that shifts away from manual design of levels

and level progressions, towards modeling the solution space

and tweaking high-level parameters that control pacing and

ordering of concepts”

– *** Possible major goal of my research

– “Andersen et al. [1] proposed a theory to automatically

estimate the difficulty of procedural problems by analyzing

features of how these problems are solved”

– Procedural Problems: those that can be solved by following a well-known solution procedure

– i.e. Integer division using long division

– Procedural Paths: code paths a solver would follow when executing procedure for a particular

problem

– Use this as a measure of difficulty

– “This is mainly because Andersen’s

framework does not account for pacing. In contrast,

our system allows a designer to control the rate of increase

in complexity, the length of time spent reinforcing concepts

before introducing new ones, and the frequency and order

in which unrelated concepts are combined together to construct

composite problems”

– *** Another goal/direction for my research

RELATED WORK

– Intelligent Tutoring Systems have “several models for capturing student knowledge and selecting

problems”

– *** Possible future work research

– “Generated levels are not useful in isolation; they must be sequenced

into some design-relevant order, called a progression”

APPLICATION

– Game called Refraction

– split lasers into number fractions that need to satisfy certain values at end

SYSTEM OVERVIEW

– Level: “any completeable chunk of content”

– Level Progression: “sequence of levels that create an entire game”

– Solution Features: “properties of the solution to a level”

– “need to be able to extract features from the levels that can

be used to create an intelligent ordering” for progression

EXTRACTING SOLUTION FEATURES

– Example of following procedural traces and n-grams within the exercise of doing hand subtraction

– Certain steps have a letter output that is recorded to see if a certain type of step

was used and how often (i.e. Was borrowing necessary for subtraction?)

– n-grams: n-length substrings of the trace

– Example: Trace = ABABCABAB

– 1-grams: {A, B, C}

– 2-grams: {AB, BA, BC, CA}

– 3-grams: {ABA, BAB, ABC, BCA, CAB}

– 1-grams are fundamental concepts

– Compare complexity by comparing n-grams

– They used these general concepts to build their own similar, but not identical, system

– their game didn’t fit this model perfectly well, so they broke their game down into

graph objects that they thought were more representative

– they had fundamental graph objects (similar to 1-grams), that could then build into

more complex graph objects by combining these defined fundamental graph objects

AUTOMATICALLY GENERATING LEVELS

– “We applied the level generation process described by Smith et

al. [30] to generate a large and diverse database of puzzles”

– *** Look into this for our system?

CREATING A PROGRESSION

– n-grams = graphlets (their specific type of n-gram)

– “To summarize, given two levels L1 and L2, L1 is considered conceptually simpler if, for

some positive integer n, the set of n-grams of L1 is a strict subset of the set of n-grams of L2″

– if a level contains the steps required for another level, it is more complex (has the same and

more basically)

– Because of several issues, their approach was create a rather large library of generated levels

to choose from, and choose a select few that represent an effective progression

– model tracks whether player has completed a problem containing each component

– also track n-grams of those components (up to very small n as values get exponentially huge)

– hard to know what to do on failure

– General Framework:

– set of problems

– domain of concepts

– player model

– These three things are what are used to generate sequence of problems for the player

– Choosing the Next Problem

– given current model state and set of problems, what is appropriate next problem?

– dynamic cost model

– cost of problem, p, is weighted sum of the n-grams in the trace of p

– weight has 2 components:

– one based on what model knows about player

– one designer-specified weight

– Player Model Cost:

“First, at each point in the progression, for a given n-gram

x, the player model assigns a cost k(x). This cost should

be high for unencountered n-grams and low for ones already

mastered, which will ensure more complex problems have a

higher cost than simpler ones with respect to the player’s history”

– Designer Added Cost:

“as expert designers, we know

(possibly from data gathered during user tests) that particular

concepts are more challenging than others or should otherwise

appear later in the progression”

– “Thus, given a library of problems P, choosing the next problem

pnext consists of finding the problem with the closest cost

to some target value T”

– “In order for this sequencing policy to be effective, it requires

a large library of levels from which to choose. The levels

should be diverse, covering the space of all interesting solution

features. Furthermore, in order to enable effective control

of pacing, this space should be dense enough that the progression

can advance without large conceptual jumps”

– *** Supports need for my thesis work

UnityLearn – Beginner Programming – Finite State Machine – Pt. 02 – Finite State Machines

digm520admin / 2019-11-19 / AI, Programming, StateMachine, Tutorial, TutorialList, Unity, UnityLearn

Novemeber 18, 2019

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Finite State Machines

Building the Machine

This part of the tutorial has a lot more hands on parts, so I skip some of the sections for note purposes when there is not much substance to them other than following inputs.

A key in finite state machines is that an object can only ever be in exactly one state at a time. This helps ensure each state be completely self contained.

Elements of a Finite State Machine:
Context: maintains an instance of a concrete state as the current state
Abstract State: defines an interface which encapsulates behaviors common to all concrete states
Concrete State: implements behaviors specific to a particular state of context

To get started in the tutorial, they created a public abstract class PlayerBaseState which will be the abstract state for this example. PlayerController_FSM is the context. They note that while in this case all the abstract state methods take the PlayerController_FSM (the context) in as a parameter in this case, that does not necessarily have to be the case for the general FSM pattern.

Concrete States

It is noted that the context in a FSM needs to hold a reference to a concrete state as the current state. This is done in the example by creating a variable which holds that of the type that is our abstract state, which is PlayerBaseState in this case. They then create a method called TransitionToState which takes a PlayerBaseState in as a parameter. It then sets the currentState to that parameter state, and then calls the new state’s EnterState method (all states have this method as it is dictated by the abstract class they all implement). This determines what actions should be done immediately upon entering this new state.

Example:

public void TransitionToState(PlayerBaseState state)
{
currentState = state;
currentState.EnterState(this);
}

The tutorial also shows a way to take control of the context’s general Unity methods and pass the work on to the concrete states instead. This example did this with Update and OnCollisionEnter. The abstract state, and in turn, all of the concrete states, have their own Update and OnCollisionEnter method. The context, PlayerController_FSM, then simply calls currentState.Update(this) in its Update method, and currentState.OnCollisionEnter(this) in its OnCollisionEnter method, so that the current concrete state’s logic for these methods are used without flooding the context itself with any more code.

Since it is necessary that your context has some initial state, they do this by simply calling the TransitionToState method within the Start method and entering the IdleState. IdleState is the initial state for this case.

Beginning the Implementation

Important benefits seen using this system:
While working on the concrete classes themselves, we never needed to go back to the PlayerController_FSM class (the context) to modify any code there. The entire behvior is handled within the concrete states and is abstracted from the character controller (the context). Setting expressions was much easier as no checks are needed and this can just be set in the EnterState method of each concrete state.

It is already clear that this method removes a lot of boolean checks from the overall code, and helps organize the code by ensuring any logic about a state is contained within the class for that state itself (with less bleeding into the code of other states).

Continuing the Implementation

It is worth noting that PlayerController_FSM holds a reference to every concrete state except the spinning state. This was done because they actually have the jumping state create a new spinning state on transition each time it is invoked. They apparently do this so that the local field for rotation within the spinning state is reset to 0 each time it is called, but it seems like there would be other ways to do this that seem less wasteful (such as resetting it to 0 when exiting the state). I am also not sure if this is intended behavior, but the spin also immediately cancels upon contacting the ground (resetting the player rotation to 0) with this setup, where as in the previous behavioral setup the spin completed even if the player contacted the ground.

Module Conclusion

Benefits of FSM:

More modular
Easier to read and maintain
Less difficult to debug
More extensible

Cons of FSM:

Take time to setup initially
More moving parts
Potentially less performant

Just something very notable with this approach, it seems much harder for me to break than the naive implementation. If I spammed key presses (like pressing jump and duck a lot) with the naive approach, sometimes I could break the system and have the player stuck in the duck position or be ducking while jumping. I have not been able to break it at all with the full FSM setup, which makes sense since transition behaviors solely exist within the states themselves so these inputs cannot be jumbled in any way.

SUMMARY

Using state machine systems appear way easier to use and build on than the “naive” approach of basic boolean behaviors (with lots of if statements and boolean checks). Not only was I very excited about how much easier this appears to work as a scalable option, it also just worked better and more cleanly when it was all put together.

The other version had small bugs that would pop up if you spammed all the different action keys (such as getting stuck ducking or being ducked in a jump), which were possible just because the key presses would get recorded before reaching the bools or if statements that should be telling them that they are not proper options. These very separated states make that type of error impossible as it is only concerned with a single state at a time.

This type of system just seems much cleaner, more organized, and less error prone than what I have done before and I am very excited to try and build a system like this for my own project (for both players and enemy AI).

UnityLearn – Beginner Programming – Finite State Machine – Pt. 01 – Managing State

digm520admin / 2019-11-16 / AI, Programming, Tutorial, TutorialList, Unity, UnityLearn

Novemeber 15, 2019

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Managing State

Project Overview

This part of the tutorial has a lot more hands on parts, so I skip some of the sections for note purposes when there is not much substance to them other than following inputs.

The basics covered in this section are:
What is state and how to manage it
Finite State Machine pattern
Build your own finite state machine

Introduction

State: condition of something variable
State Examples: Game state, Player state, NPC State

Finite State Machine: abstract machine that can be in exactly one of a finite number of states at any given time

Parts of a Finite State Machine:

List of possible states
Conditions for transitioning between those states
State its in when initialized (initial state)

Naive Approach to Managing State

This naive approach focuses on boolean states and if staements. It uses a lot of if and else if statements in the Update method to determine what state the player is in and if/when/how they can switch to another state. Even with two states this becomes tedious and somewhat difficult to read. This example is just to emphasize the use of proper finite state machines.

Actions, Triggers, & Conditions

Look at your actions as a set of: actions, triggers, conditions.
Example for Arthur jumping:

Actions: Arthur jumps; jumping expression
Triggers: Spacebar is pressed
Conditions: Arthur is not jumping

Continuing to follow the naive state management approach, we see that everytime we add a new state it makes all snippets about other states more complex and harder to follow. This is very clear that this will become unmanagealbe with only a few states even.

Module Overview

The biggest issue with the naive approach is the interdependent logic of the various states. It makes each state exponentially harder to work with with every state that is added, so it is very limited on its scalability. This does not even come with a benefit to readability, as it also becomes difficult to read quickly.

SUMMARY

Using the naive approach (boolean fields and if/else statements) to manage state is only really useable for extremely simple cases. As soon as you reach 3 or 4 states with even small amounts of logic to manage them, this approach becomes very awkward and unwieldy. Fininte State Machines should hopefully open up a better way to manage more states with better scalability and allow for more complexity with better readability.

Programming A* in Unity

digm520admin / 2019-11-15 / A*, AI, C#, Programming, Tutorial, TutorialList, Unity

November 14, 2019

A* Programming

Unity

A* Pathfinding (E01: algorithm explanation)

Tutorial #1 – Link

By: Sebastian Lague

Unity – A Star Pathfinding Tutorial

Tutorial #2 – Link

By: Daniel

Unity3D – How to Code Astar A*

Tutorial #3 – Link

By: Coding With Unity

I have used A* before, but I would like to learn how to setup my own system using it so that I can make my own alterations to it. I would like to explore some of the AI methods and techniques I have discovered in my AI class and use that to alter a foundational pathfinding system built with A* to come up with some interesting ways to influence pathfinding in games. I would eventually like to have the AI “learn” from the player’s patterns in some way to influenece their overall “A* type” pathfinding to find different ways to approach or avoid the player.

Maya Tutorials – Basics and Fish

digm520admin / 2019-11-13 / Maya, Tutorial, TutorialList

November 11, 2019

Maya Modeling

Basics and Fish Tutorials

Maya Fish Tutorial Part 1 Modeling

Tutorial #1 – Link

By: Alberto Alvarez

Cartoon animals). Fish 3d modeling in Autodesk Maya 2016

Tutorial #2 – Link

By: Cartoon with MK

3D Shark Modeling Tutorial – Autodesk Maya 2018

Tutorial #3 – Link

By: Vedant VFX

I may explore transitioning one of my game projects that I worked on from a 2D game to a 3D game. It’s mostly sea themed at this point so it would help to be able to put some basic fish shaped models together, so I gathered some sources on a wide variety here just to get started. These videos give me a detailed tutorial on a general fish, with a quick look at how people have made sharks and more cartoon styled fish.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 03 – The Observer Pattern

digm520admin / 2019-11-08 / Programming, Tutorial, TutorialList, Unity, UnityLearn

Novemeber 7, 2019

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

The Observer Pattern

Observer Pattern: software design pattern in which an object, called the subject, maintains a list of dependents, called observers, and notifies them of any state change, usually by calling one of their methods

Observer Pattern Anatomy

Subject

collection of observers
method: AddObserver
method: RemoveObserver
method: NotifyObservers

Observer

method: Notify (what to do when notified)

An interface is a good way to ensure observers have the types of methods you need to exist when notified by the subject.

Implementing the Observer Pattern

This was an example of how to setup a basic observer pattern using the example project. First they created the interface for the observers, which was named IEndGameObserver. This simply held an empty method named Notify().

They then used the GameSceneController script as the subject for the observer pattern. To do so, they created a list of IEndGameObserver objects, created a method AddObserver which could add to that list, created a method RemoveObserver which could remove from that list, and finally a method called NotifyObservers that was a simple foreach loop that went through each IEndGameObserver in the list and called their Notify() method.

NotifyObservers then just needs to be called when the event or state is reached where the observers need to be informed that a change has occurred. Since this example was to inform objects of when the game ended, NotifyObservers was called within the GameSceneController script when the player ran out of lives.

Concrete Observers

Concrete Observers: just objects that implement the observer interface

This example showed that with this setup, either the observer or the subject can be used to add observers to the subject’s collection of observers. The HUDController already had a reference to the GameSceneController (subject) so it made sense to just have it add itself to the observer collection through that reference.

While the EnemyController and PowerupController do not have reference to the GameSceneController, the GameSceneController has references to them created on instantiating them. These could then be used with the GameSceneController to add them to the observer collection upon instantiation.

***Could possibly use this observer pattern in my thesis project to easily collect all of the various Create classes into the Scenario classes (and potentially again to collect the Scenario classes into the SystemManager).

Removing Observers

To avoid nullreferenceexceptions, you must ensure that observers that are destroyed are also removed from the subject’s collection of observers.

To apply this to the example, we added a method called RemoveAndDestroy to both the PowerupController and the EnemyController class which both removed it from the observer collection and destroyed it. This method was exactly the same for both, so this could indicate that it should be added to the interface itself to keep it consistent amongst all observers using this interface.

The Observer Pattern and C# Events

Example Problem with C# Events:
The ProjectileController has an event that occurs when it reaches the bounds of the screen. The PlayerController subscribes to this event by adding one of its methods to this event. There are some cases where the projectile exists while the player is destroyed, so when the projectile goes out of bounds (and calls its event), it tries to invoke a method from the destroyed PlayerController class, which gives an error.

Similar to the observer pattern where we want to remove observers from the collection when they are destroyed to prevent errors, we want to unsubscribe classes from events when they are destroyed. This ensures that they are revmoved from the events invocation list so that they do not try to call methods of destroyed objects which will create errors.

The Publisher Subscriber Pattern

Publisher Subscriber Pattern: similar to Observer Pattern, but adds another entity, the broker, which is in charge of keeping track of and notifying subscribers.

Observer Pattern has a single subject, but publisher subscriber pattern can have any number of publishers. Each of these publishers has a reference to the broker to notify it when a noteworthy happening occurs.

Example:
They created a class called EventBroker that just contained a public static event ProjectileOutOfBounds and a public static method named CallProjectileOutOfBounds (which just checked that the event wasn’t empty and then called that event). The PlayerController subscribes to this event by adding its EnableProjectile method to it on Start (and removes it OnDisable), both of which are very direct since everything is public static in EventBroker. Finally, the ProjectileController invokes the event CallProjectileOutOfBounds when the projectile leaves the screen, which now invokes the PlayerController’s EnableProjectile method.

This setup allows the ProjectileController to effectively communicate with the PlayerController without references to each other in anyway by going through the EventBroker.

SUMMARY

Using delegates, events, and actions can provide a clean and effective way to communicate important happenings throughout many objects and have them act accordingly. The Observer Pattern uses a single subject and multiple observers which receive information from the subject when to do something. The Publisher Subscriber system is similar, but adds a middle man entity of a broker which communicates the information between the publisher and subscribers without the publishers or subscribers needing any direct reference between each other.

HFFWS Thesis Project – Theory for General Generation System Architecture

digm520admin / 2019-11-07 / HFFWS, Programming, Thesis, Unity

November 6, 2019

HFFWS Puzzle Generation System

General System Architecture

General Notes

Pulley Varieties

I wanted to start with sketching out the general structure of a single puzzle type to help me get a better idea of what a useful general structure might look like for the overall puzzle generating system I want to make.

Hook on an end to latch onto other objects
Object to move can be used as a platform
Open heavy door
Focus on rotation of wheel
Build a pulley
(Rope puzzle) Move two rope conjoined objects somewhere to accomplish a goal

Breakdown of what I can currently alter/generate in rope/pulley tool

Objects (at ends of rope)
Objects (for wheels)
Length (of rope)
Position (of rope)
Position(s) (of wheel(s))

I then quickly sketched out what I could change with the current controllable parameters to match the various puzzle variations (I only did the first three for now just to work it into testing quicker).

Hook on end

Objects at ends
- Hook
- Grabbing Mass (i.e. small sphere)
Outside objects
- Objects that need pulled by hook

Objects attached can be used as platforms

Objects at ends
- Platform type objects
Outside objects
- Mass objects to influence pulley movement

Open heavy door

Objects at ends
- Heavy Door
Outside objects
- Mass objects to influence pulley movement

Architecture Design (1st Pass)

The overall flow of information is:
GenerationManager -> ScenarioManager -> “Create” type classes

GenerationManager

Passes down highest level information to ScenarioManager. This will include puzzle type, variation type within that puzzle type, and any other high level information such as overall positioning or how many scenarios in total to generate.

ScenarioManager

Will take that information and use it to determine which “Create” type classes will need to be used (or have the option of being used), how many times to use each, and what other information needs to be passed on to them (the “Create” type classes) to properly build out the desired scenario.

“Create” type Class

Use the information passed down to them from the ScenarioManager to create objects that satisfy the needs of the desired scenario. Within these bounds, in then adds variation to what it creates to vary its creations while still meeting the requirements given by the ScenarioManager

All the “Create” type classes will need an interface or inheritance of some kind to make them all similar types of objects to make grouping them and using them a bit easier.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 02 – Working with Multiple Subscriptions

digm520admin / 2019-11-05 / Programming, Tutorial, TutorialList, Unity, UnityLearn

Novemeber 5, 2019

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Working with Multiple Subscriptions

Creating a Parameterized Event

Parameterized Event: an event that takes in at least one parameter

Points of Reference

A subscriber must have a reference to the publisher (class raising the event) in order to be able to subscribe to that event.

The general pattern for making delegates and events from how they have done it so far is that you create the overall delegate type that you will want the events to use outside of a class definition and public (so that all classes that want to make an event of this delegate type can use this single delegate type as a reference). The events themselves are then within the class definition, and use that newly created delegate type.

Example Breakdown

I broke down the tutorial example in order to better understand it.

The parameterized event is created in the EnemyController script. This is done by creating a delegate called EnemyDestroyedHandler outside of the class definition in the EnemyController script (this delegate is of type void and takes an int parameter, so any event using this must do follow the same signature). They then created a public event of type EnemyDestroyedHandler named EnemyDestroyed within the class definition of EnemyController.

Since subscribers need references to the publishers in order to subscribe to their events, they go to the GameSceneController class to subscribe to the EnemyDestroyed event since it already has references to the EnemyController class in its spawning methods. Here they add a method (Enemy_EnemyDestroyed, the default name) from within the GameSceneController class to the EnemyDestroyed event. It matches the signature (return type void, with a single paramter of type int). Now, when the EnemyDestroyed event is called in the EnemyController script, the parameter input given there is the same parameter input used for all methods subscribed to that event. So in EnemyController, EnemyDestroyed(pointValue) ends up calling Enemy_EnemyDestroyed(pointValue) from within the GameSceneController class.

The GameSceneController also creates its own event of type EnemyDestroyedHandler named ScoreUpdatedOnKill. This uses the same delegate type created in the EnemyController script, so they just need to create the event here in the GameSceneController script. It should be noted that this can be done simply because they are using the same signature delegate type here, it does not necessarily even have to do with the fact that its a similar game related event. This event is then called within the Enemy_EnemyDestroyed method, which is subscribed to the EnemyController EnemyDestroyed event already. So this creates a chain of method calls from a single event.

This event, ScoreUpdatedOnKill, is used to update the HUD score value. To accomplish this, we need the HUDController class to subscribe to the event. So they go to the HUDController and create a reference to the GameSceneController class (since subscribers must have a reference to the publisher). Since the GameSceneController is an object that will persist throughout the entirety of the game, they simply create the reference to it and subscribe to the event within the GameSceneController within the Start method of the HUDController.

ScoreUpdatedOnKill, the GameSceneController event, is given the method GameSceneController_ScoreUpdatedOnKill from the HUDController. This method simply calls the method UpdateScore which changes the text to match the new score.

It is important to note that since this is a chain of events, as opposed to multiple subscribers subscribing to a single event, the value passed throughout the chain can change. The EnemyDestroyed event in EnemyController uses the int pointValue, so that the GameSceneController method Enemy_EnemyDestroyed subscribed to it adds that value to the totalPoints, which is held within the GameSceneController. The GameSceneController then passes totalPoints (not pointValue) into its event, ScoreUpdatedOnKill, which is the event the HUDController subscribes to in order to update the score. This makes sure it displays the new total score as opposed to just the value for the last score gained.

I wanted to make this difference clear since I also noted that multiple subscribers to a single parameterized event will all use the same parameters. This chain of events simply use the same delegate type because they just happen to want to use the same signature (return type void with a single int parameter) and nothing more.

Multiple Subscribers

You can have several classes subscribe to the same event.

What was weird for this example was that they just wanted to reenable the firing mechanism for the player when an enemy was destroyed, using the same ScoreUpdatedOnKill event. This event requires a method of return type void with an int parameter. So they made a method satisfying this, but it doesn’t use the int parameter at all. It simply calls another method that is just void return type with no input parameter, EnableProjectile (which lets the player fire again). Since you can simply subscribe to an event with a method that just calls another method, your method actually doing work does not particularly have to match the signature of the original delegate type.

Conclusion

Actions (C#): types in the System namespace that allow you to encapsulate methods without explicitly defining a delegate

Actions are inherently delegate types so they keep you from having to separately define a delegate when creating an event. They mention that they will just use actions from here on for the course, so I assume this is generally better and cleaner practice this way. This does make more sense with my recent understanding that the delegate signature type is not particularly that crucial for the actual outcome when dealing with this subscriber and publisher pattern.

SUMMARY

Subscribers need a reference to their publisher in order to use their events, so look for places where you are already creating this reference for improved efficiency. An event can have multiple subscribers, so calling that event can call multiple methods from multiple objects. You can also create chains of actions that call methods while starting other events. Actions are a more compact and cleaner way to create an event without the need for separately creating the delegate.

UnityLearn – Beginner Programming – Observer Pattern – Pt. 01 – Handling Events

digm520admin / 2019-11-05 / Programming, Tutorial, TutorialList, Unity, UnityLearn

Novemeber 4, 2019

Beginner Programming: Unity Game Dev Courses

Unity Learn Course – Beginner Programming

Handling Events

The Demo Project

This section focused on handling inter-object communications. They covered direct object calls, tight coupling, and loose coupling. This topic was covered using mostly delegates and events.

Events: something that happens within the context of one object to be communicated to other

The first objective of the tutorial was to restric the rate of fire of the player ship so that it could only have one projectile on the screen at any time. They could not fire again until that projectile was destroyed (which in this case, only occurred once it left the screen).

Direct Object Calls

Direct Object Calls: directly make a call from within one object to a method in another object (usually through public methods)

Example: The ship needed to be able to fire again when the projectile reached the end of the screen. The projectile used a reference to the PlayerController to call a method within it when the projectile reached the end of the screen to reenable the firing mechanism.

Costs: This forces you to expose a lot of methods within objects so that others may access them.

Tight Coupling

Tight Coupling: making objects dependent on one another; can be done by having one object call a method found in another object

Costs:

Difficult to maintain and debug
Not easily scalable
Impedes collaboration (like Git or Collab)
Complicates Unit Testing

Delegates and Events

This section looks to use delegates and events to get around the issues found with direct object calls and tight coupling. These allow for loose coupling.

Important Notes

One way to think of delegates is that they are method variables.
All events have an underlying delegate type.

Example: The ProjectileController script created a public delegate and public event. It then called that event within its code somewhere (which would then execute any methods assigned to that event). The PlayerController assigned one of its methods to that public event when instantiating the projectile. The ProjectileController could then effectively call that PlayerController method by calling the event within it.

SUMMARY

Delegates and events can provide a nice way to create loose coupling, which can lead to better and easier to maintain ways to allow your objects to communicate between one another. Be careful with direct object calls and tight coupling as they can reduce encapsulation and lead to tricky debugging problems down the road.

Thesis Current Resources and Citations

digm520admin / 2019-11-01 / Research, Thesis

October 31, 2019

Academic Resources

Current Citations

I just wanted to have a list of all my current sources I have compiled that may be useful for my thesis here. This list will be modified over time as I dtermine which topics I will not get to in my thesis, and which topics need more support, but this is a pretty good foundation for now.

[1]J. L. Anderson and M. Barnett, “Learning Physics with Digital Game Simulations in Middle School Science,” Journal of Science Education and Technology, vol. 22, no. 6, pp. 914–926, Dec. 2013.
[2]M.-V. Aponte, G. Levieux, and S. Natkin, “Measuring the level of difficulty in single player video games,” Entertainment Computing, vol. 2, no. 4, pp. 205–213, Jan. 2011.
[3]S. Arnab et al., “Mapping learning and game mechanics for serious games analysis: Mapping learning and game mechanics,” British Journal of Educational Technology, vol. 46, no. 2, pp. 391–411, Mar. 2015.
[4]E. Butler, E. Andersen, A. M. Smith, S. Gulwani, and Z. Popović, “Automatic Game Progression Design through Analysis of Solution Features,” 2015, pp. 2407–2416.
[5]M. J. Callaghan, K. McCusker, J. L. Losada, J. Harkin, and S. Wilson, “Using Game-Based Learning in Virtual Worlds to Teach Electronic and Electrical Engineering,” IEEE Transactions on Industrial Informatics, vol. 9, no. 1, pp. 575–584, Feb. 2013.
[6]M. Callaghan, M. Savin-Baden, N. McShane, and A. G. Eguiluz, “Mapping Learning and Game Mechanics for Serious Games Analysis in Engineering Education,” IEEE Transactions on Emerging Topics in Computing, vol. 5, no. 1, pp. 77–83, Jan. 2017.
[7]D. B. Clark, B. C. Nelson, H.-Y. Chang, M. Martinez-Garza, K. Slack, and C. M. D’Angelo, “Exploring Newtonian mechanics in a conceptually-integrated digital game: Comparison of learning and affective outcomes for students in Taiwan and the United States,” Computers & Education, vol. 57, no. 3, pp. 2178–2195, Nov. 2011.
[8]M. M. Cruz-Cunha, Ed., Handbook of Research on Serious Games as Educational, Business and Research Tools. IGI Global, 2012.
[9]A. A. Deshpande and S. H. Huang, “Simulation games in engineering education: A state-of-the-art review,” Computer Applications in Engineering Education, vol. 19, no. 3, pp. 399–410, Sep. 2011.
[10]M. D. Dickey, “Game design narrative for learning: Appropriating adventure game design narrative devices and techniques for the design of interactive learning environments,” Educational Technology Research and Development, vol. 54, no. 3, pp. 245–263, 2006.
[11]J. Dormans and S. Bakkes, “Generating Missions and Spaces for Adaptable Play Experiences,” IEEE Transactions on Computational Intelligence and AI in Games, vol. 3, no. 3, pp. 216–228, Sep. 2011.
[12]M. Ebner and A. Holzinger, “Successful implementation of user-centered game based learning in higher education: An example from civil engineering,” Computers & Education, vol. 49, no. 3, pp. 873–890, Nov. 2007.
[13]M. Eraut, “Non-formal learning and tacit knowledge in professional work,” British Journal of Educational Psychology, vol. 70, no. 1, pp. 113–136, Mar. 2000.
[14]D. Farrell and D. Moffat, “Cognitive Walkthrough for Learning Through Game Mechanics,” in European Conference on Games Based Learning, 2013, p. 163.
[15]H. Fernandez, K. Mikami, and K. Kondo, “Adaptable game experience through procedural content generation and brain computer interface,” 2016, pp. 1–2.
[16]A. Foster, “Games and motivation to learn science: Personal identity, applicability, relevance and meaningfulness,” Journal of Interactive Learning Research, vol. 19, no. 4, p. 597, 2008.
[17]C. Franzwa, Y. Tang, A. Johnson, and T. Bielefeldt, “Balancing Fun and Learning in a Serious Game Design:,” International Journal of Game-Based Learning, vol. 4, no. 4, pp. 37–57, Oct. 2014.
[18]J. Fraser, M. Katchabaw, and R. E. Mercer, “A methodological approach to identifying and quantifying video game difficulty factors,” Entertainment Computing, vol. 5, no. 4, pp. 441–449, Dec. 2014.
[19]J. P. Gee, “What video games have to teach us about learning and literacy,” Computers in Entertainment, vol. 1, no. 1, p. 20, Oct. 2003.
[20]J. P. Gee, “Good video games and good learning,” in Phi Kappa Phi Forum, 2005, vol. 85, p. 33.
[21]B. Gregorcic and M. Bodin, “Algodoo: A Tool for Encouraging Creativity in Physics Teaching and Learning,” The Physics Teacher, vol. 55, no. 1, pp. 25–28, Jan. 2017.
[22]R. H. Mulder, “Exploring feedback incidents, their characteristics and the informal learning activities that emanate from them,” European Journal of Training and Development, vol. 37, no. 1, pp. 49–71, Jan. 2013.
[23]T. Hainey, T. M. Connolly, E. A. Boyle, A. Wilson, and A. Razak, “A systematic literature review of games-based learning empirical evidence in primary education,” Computers & Education, vol. 102, pp. 202–223, Nov. 2016.
[24]P. Hämäläinen, X. Ma, J. Takatalo, and J. Togelius, “Predictive Physics Simulation in Game Mechanics,” 2017, pp. 497–505.
[25]M. Hendrikx, S. Meijer, J. Van Der Velden, and A. Iosup, “Procedural content generation for games: A survey,” ACM Transactions on Multimedia Computing, Communications, and Applications, vol. 9, no. 1, pp. 1–22, Feb. 2013.
[26]R. Hunicke, M. LeBlanc, and R. Zubek, “MDA: A Formal Approach to Game Design and Game Research,” p. 5.
[27]I. Iacovides, P. McAndrew, E. Scanlon, and J. Aczel, “The gaming involvement and informal learning framework,” Simulation & Gaming, vol. 45, no. 4–5, pp. 611–626, 2014.
[28]P. Lameras, S. Arnab, I. Dunwell, C. Stewart, S. Clarke, and P. Petridis, “Essential features of serious games design in higher education: Linking learning attributes to game mechanics: Essential features of serious games design,” British Journal of Educational Technology, vol. 48, no. 4, pp. 972–994, Jun. 2017.
[29]H. B. Lisboa, “3D VIRTUAL ENVIRONMENTS FOR MANUFACTURING AUTOMATION,” vol. 6, p. 9, 2014.
[30]R. Lopes, T. Tutenel, and R. Bidarra, “Using gameplay semantics to procedurally generate player-matching game worlds,” 2012, pp. 1–8.
[31]S. D. Mohanty and S. Cantu, “Teaching introductory undergraduate physics using commercial video games,” Physics Education, vol. 46, no. 5, p. 570, 2011.
[32]S. Moser, J. Zumbach, and I. Deibl, “The effect of metacognitive training and prompting on learning success in simulation-based physics learning,” Science Education, vol. 101, no. 6, pp. 944–967, Nov. 2017.
[33]C. Peach, D. Rohrick, D. Kilb, J. Orcutt, E. Simms, and J. Driscoll, “DEEP learning: Promoting informal STEM learning through ocean research videogames,” in Oceans-San Diego, 2013, 2013, pp. 1–4.
[34]J.-N. Proulx, M. Romero, and S. Arnab, “Learning Mechanics and Game Mechanics Under the Perspective of Self-Determination Theory to Foster Motivation in Digital Game Based Learning,” Simulation & Gaming, vol. 48, no. 1, pp. 81–97, Feb. 2017.
[35]M. Qian and K. R. Clark, “Game-based Learning and 21st century skills: A review of recent research,” Computers in Human Behavior, vol. 63, pp. 50–58, Oct. 2016.
[36]S. Sampayo-Vargas, C. J. Cope, Z. He, and G. J. Byrne, “The effectiveness of adaptive difficulty adjustments on students’ motivation and learning in an educational computer game,” Computers & Education, vol. 69, pp. 452–462, Nov. 2013.
[37]M. Shaker, M. H. Sarhan, O. A. Naameh, N. Shaker, and J. Togelius, “Automatic generation and analysis of physics-based puzzle games,” 2013, pp. 1–8.
[38]N. Shaker, M. Nicolau, G. N. Yannakakis, J. Togelius, and M. O’Neill, “Evolving levels for Super Mario Bros using grammatical evolution,” 2012, pp. 304–311.
[39]G. Smith, “Understanding procedural content generation: a design-centric analysis of the role of PCG in games,” 2014, pp. 917–926.
[40]V. Wendel, M. Gutjahr, S. Göbel, and R. Steinmetz, “Designing collaborative multiplayer serious games: Escape from Wilson Island—A multiplayer 3D serious game for collaborative learning in teams,” Education and Information Technologies, vol. 18, no. 2, pp. 287–308, Jun. 2013.
[41]K. A. Wilson et al., “Relationships Between Game Attributes and Learning Outcomes: Review and Research Proposals,” Simulation & Gaming, vol. 40, no. 2, pp. 217–266, Apr. 2009.
[42]J.-C. Woo, “Digital Game-Based Learning Supports Student Motivation, Cognitive Success, and Performance Outcomes.,” Journal of Educational Technology & Society, vol. 17, no. 3, 2014.
[43]G. N. Yannakakis and J. Togelius, “Experience-Driven Procedural Content Generation,” IEEE Transactions on Affective Computing, vol. 2, no. 3, pp. 147–161, Jul. 2011.