Detecting Collisions in 2D

Introduction
Let's say a game object is in 2 positions over frame updates.  The 2 positions form a line L1.  To determine if the game object collided with a line L2, we look for the presence of an intersection.

We can detect the presence of an intersection (we don't care where it is) by only looking at the slopes between L1's start point and L2's endpoints, and between L2's start point and L1's endpoints.  If L1's slope is between the 2 slopes of L1's start point and L2's endpoints, and also if L2's slope is between the 2 slopes of L2's start point and L1's endpoints, a collision occurred.


Caveats
I have not compared efficiency to other methods.  However this requires no dot product calculations thus no need for taking the cosine.  [If you know of other methods and would like to share - please post a comment!]


Process

Detect the presence of any intersection between line L1 from x1,y1 to x2,y2, and L2 from x3,y3 to x4,y4.

Figure 1, Two Lines L1 and L2

In Figure 1 above, the slopes of the lines are:

For L1, slope m1 = (y2-y1)/(x2-x1)

For L2, slope m2 = (y4-y3)/(x4-x3)

----------------------------------------------------------------------------------------------


Now we can calculate the slopes between x1,y1 and x3,y3, between x1,y1 and x4,y4, and between x3,y3 and x2, y2, as shown in Figure 2 below:

Figure 2, Additional Lines L14, L13, and L32

In Figure 2 above, the slopes of the lines are:

For L14, slope m14 = (y4-y1)/(x4-x1)

For L13, slope m13 = (y3-y1)/(x3-x1)

For L32, slope m32 = (y2-y3)/(x2-x3)

We also added L31, slope m31 = (y1-y3)/(x1-x3)


An intersection exists (and thus a collision occurred) if:

( m14 > m1 > m13 ) || (m14 < m1 < m13 )

&&

( m31 > m2 > m32 ) || (m31 < m2 < m32 )

C# Reflection - It's What Allows The Entity Component System Pattern At Runtime.

Here is the C# Language Specification 5.0.

From the introduction:

C# is an object-oriented language, but C# further includes support for component-oriented programming. Contemporary software design increasingly relies on software components in the form of self-contained and self-describing packages of functionality. Key to such components is that they present a programming model with properties, methods, and events; they have attributes that provide declarative information about the component; and they incorporate their own documentation. C# provides language constructs to directly support these concepts, making C# a very natural language in which to create and use software components.

If you had never used components, you might walk away from this paragraph scratching your head "well what is component-oriented programming?"

Sadly, this is all the specification spells out specifically about component-oriented programming.

-------------------------------------------------------------------------------

Enter the Entity Component System design pattern.  Apparently there are multiple flavors, and many discussions and purists concerned with how to implement the ECS pattern, and one of those flavors is implemented in Unity, which allows components to be added to game objects in the editor, and at runtime:


// add a script foo to the gameObject
gameObject.AddComponent ("foo");


// add a collider to gameObject
gameObject.AddComponent("SphereCollider");



Unity must be taking advantage of C#'s Reflection feature to find out which components have been added to a gameObject.  I believe Reflection opened the world of component-oriented programming in C#, which is quite wonderful!  Yet searching the C# Language Specification for "reflection" only lightly discusses the reflection feature, and you might not grasp the significance by reading.

Where is the ECS pattern used?  So far I'm only aware of games.  I'm guessing Galactic Civilizations (ship editor), Fate, Reassembly, probably Skyrim, probably Trackmania, Robocraft, and WazHack among many others.

I say "probably Skyrim" and "probably Trackmania", because some features might still be implemented without ECS, but it's cleaner to add components rather than trying to anticipate every possible feature that may ever need to be added to an object.  Thus a modding feature might be best implemented with ECS, but there are other ways to allow a game to be moddable - they just won't be as future-proof.

For example, if you wanted a collapsible wall which responded to impacts, it could be coded without ECS, but it would be a nightmare.  With ECS, a collapsible wall is trivial to implement, as each section of the wall can independently respond to impacts and distribute damage to adjoining sections.

There is also some discussion that Unity "breaks" the ECS pattern by allowing code to reside in components.  Some people want the components to be data only with no methods.  My impression is they have overlooked other messaging features and Unity does it fine; it's a rabbit hole I'm not interested in digging into right now.  The way Unity implements ECS is to divide concerns into individual components.

The ECS pattern in Unity organizes the software in such a way that components can be attached to initial objects without much emphasis on inheritance.  I've written applications without ever deriving from anything other than monobehavior.

Also, if you want to understand Reflection by itself, watch C# Reflection to the Max, and thanks Jamie King for helping me grasp the concept!

Unity Versus Sencha for Mobile App Development

This whole discussion is mostly academic for me.  I post it for whoever might have an interest in these tools.


Recently I looked into the Sencha development environment.  It reminds me a lot of Maqetta, specifically the sliding UIs it generates.

I've looked into whether similar UI is available off-the-shelf for Unity (especially for workflow), and so far it looks like it's not.  I wrote a UI from the ground up using uGUI, but this adds extra weight which isn't present in the Sencha UX, and the workflow isn't anywhere close to as streamlined.

All I can say is Unity still thinks of itself as a game engine, rather than a mobile app engine.

It has not yet matured in the direction of rapid UI development.  I have this nagging feeling I want to create a Sencha-like UX in Unity, which only animates going between scenes while not actually using a Unity uGUI scroll-rect to hold them all.  Mostly I want to do this to improve the whole game development workflow, of which UI design can be a good starting point.

But again... this discussion is mostly academic.

Live and learn.  Unity is still more efficient than going through multiple target learning curves (i.e. Xcode for iOS + Android API).

Will I switch to HTML5?  Only if three.js or other tools can bridge the gap.  Push notifications look like they are available at least for Chrome (and possibly exclusively to GAE).

Google may kill Unity altogether eventually.

The Harass-Justify Pattern

I did not even want to write about this.  Then I load youtube to watch a tutorial on Scala, and up pops this ad!

I had already written this article in my head, decided I didn't want to write about it, and then I see exactly the ad I was thinking about, all in a matter of about 1 minute.

Okay!  I'll write about it!  Here's a screenshot of the ad:

Harass

The ad starts out by saying "these are real people".  I.e. they are not actors, other than the guy throwing eggs at them.

As the people go to sit down at the table, the man in the middle throws eggs and the real people jump in surprise.


Justify

If you didn't skip the ad, the middle man explains something about "life is hard to respond to when there are surprises" or something along those lines.  The justification for the harassment of throwing eggs at complete strangers is "I have some insight to share."


The Pattern

Whether or not the insight is valuable is not really interesting to me.  What is interesting is that the 2 behaviors "harass" and "justify" are presented in combination.  Throwing an egg by itself isn't enough.  And justification by itself apparently isn't enough either.  It is a theatrics pattern.

That's all... I'm going to watch about Scala now.


POSTSCRIPT

This is really obsession-compulsion, where "harass" is the compulsive behavior ("I must"), and "justify" is the obsessive thinking.  The justify is like a broken record that keeps playing over and over again.  There's some projection of "if everyone only could see what I'm obsessing about, they would understand my harassing behavior".  Such thinking is fantasy.

I guess the pattern could be generalized into Powerplay-Justify.  It's a "when words are many, sin is not far..." sort of thing.  Something about it doesn't smell right, as opposed to people operating in a natural outflow.

We could ask "what is source of obsessive thinking?"  There is a source.

Augmented Reality Target Recognition

Last night I was up until 3am making this video.


Actually the video was done at about 9pm, or even earlier, but for some reason I couldn't get the video from my camcorder.  I started to wonder "did something break?"

There was this sort of ... prompting ... a real message I had seen earlier that evening which said:

 "Stop giving up."

Now what can you do with that?  Well... keep trying.  Finally at 2:30am I see the manual for my camcorder talking about "Use only a Sony cable" and after so many other wrong attempts found out I had a different cable, plugged it in.. and everything worked again!  Ugh!


Augmented Reality Target Recognition

The video was implemented running Unity app on an iPad.  There are 5 target images in the Vuforia plugin of common items.  The 3D doll that gets projected onto the items is one feature that has some application, but the bigger application is bringing in context according to which target the camera recognizes.

I had a specific application in mind, but it opens a whole world of interesting UX user experiences.  Going through the process is mind-expanding, and really fun.


Everybody Already Knows How To Do This

As soon as I posted this video, I suddenly realized "this is nothing new!" and I had some real doubts about why I should pester anyone with this technology.  Well... if that's the only way I can learn something new, then it's just part of the process.


Importing Packages Into Unity At Runtime

Because the application only knows those 5 target images I had processed on the Vuforia website, the next step seems to be experimenting with loading packages in the Unity app at run-time.  According to Unity documentation, that is supported!  So this would open up some very wide applications to at least allow some application administrator to set up their own library of recognized images.

Augmented Reality Experiment

I used Vuforia, and it was relatively easy.  Low light conditions don't seem to work very well, but it's a start!

The Antidote Pattern

There's a quintessential Christian marketing story that goes something like this:

- Person was desperate

- Person experienced miracle

- Person became a Christian

When I called myself a Christian for many years, and before that growing up in a Christian home, I heard this story with variations over and over.  The frequency was maybe never lower than every 3 years, sometimes more often, at least that's how I remember it.  My mother LOVED repeating every new variation of this story when it came out.

Every time I heard this story, I had 2 responses internally: the story was always unverifiable, and the story was always believable.  At least it was believable when I heard it for the first time.  It lost some of that luster after hearing it countless times though.

Then many years ago I left Christianity, and I never heard that story again in other religious practices.  There are other parallels to Christianity in other religions (like love your neighbor as yourself, or practice kindness, etc) but from what I've picked up in Buddhism or Hinduism or maybe even Mormonism - at least so far I've never heard this type of story.  And possibly that's why at a very deep level Christianity just wasn't for me - at a certain level the story produced more doubt than it produced devotion.

The closest story which also shows up in other religions is something like this:

- Person has good practice

- Person lives good life even with hardships

That story shows up in Christianity and Judaism (i.e. Job, Habakkuk), but also in Buddhist Koans and maybe even something like it is in the Baghavad Gita.

Back to the marketing story.  My only explanation is that this story exists on 2 levels.  It may actually reflect real events.  But it also serves a purpose for countering lost practice.  So I think of it as an antidote.  If you have really bad theology (namely the whole universe is really tainted with sin and all people are fundamentally bad) and everyone in your religious practice actually believes this bad theology (rather than seeing it for what it is, a metaphor of the not-yet-born-again-enlightened mind), then nobody new would ever come in.  So that horror theology needs an antidote story.  And you have to keep applying this antidote over and over again.

It is similar to the "end of the world" story that comes out at about the same frequency - every 3 years or so - where the world will end on such and such a date.

Now maybe that's not true.  Maybe I'm seeing something that's not really there.  Maybe your mileage varies.  But the idea of an antidote pattern seems a compelling storytelling mechanism, so I present it here, because storytelling and game design are closely related.  There is something very human going on here, and it seems worth mentioning.

Why Board Game Manuals are Evil

You bought a new game.


And it's gorgeous!  Oh it's going to be so much fun!


So you read the manual and start to figure out how it works.  The manual is a work of art - the whole game experience unfolds before you as you read it.


Finally you feel ready to host a game, and invite friends over to play.


And what happens next?


Do you give everyone a copy of the manual and order them to read?


Or did the manual explain to you how to be a good "game master" - organizing all the details of the game in such a way that everyone feels compelled to keep going forward with the process of learning the game?


The Indescribable Importance Of The Wiener Pattern

At this point, a game will either "magically" be great and everyone loves it, or half the audience at your house will want to play and half will have no clue what is going on and wander off with confused looks on their faces, or nobody even shows up in the first place.  Oh sad.


This is why the wiener pattern is so important.  And why game manuals usually fail.  It's not that the game manual is at fault - it's that someone else usually explains the rules to the players.  And that person probably likes the game, but doesn't know how to propagate that "like" to other players.


The answer is the wiener.  How can a game be designed that the whole learning process is a continuous stream of wieners for all skill levels and not rely on a "game master" to do the work of producing wieners himself?


A Gigantic Pile of Details

My experience has been that some board games are so detailed the first few minutes involve hearing a gigantic pile of rules and explanations of "this is what this card is" etc.  It can be overwhelming.

And overwhelming makes me feel dumb.

Now sometimes it's my job to feel dumb - but not everyone is so forgiving.  They might not want to come back next time to visit such unfamiliar territory.


Organize The Piles Into Easily Digestible Categories

One way to incorporate wieners into a board game, is to make the game unboxing itself part of the learning process.  There can be a specific order that items have to be taken out of the box - so that everyone watching isn't overwhelmed with "everything all at once".  Instead, there may need to be boxes within boxes, to allow categorization of game concepts.


Put The Game Master Into The Game Itself

This offloads the burden from the game master and shifts it back to the game explaining itself, in it's own way.  It can be as dramatic as it needs to be - but it no longer relies on the game master's dramatic skills.  This way the game is it's own game master, inviting everyone to learn in a consistent way regardless of how much exposure they've had.

Building a Board Game

I recently created a prototype board game for a game idea I've been working on.  If you are at all interested in this sort of thing, I highly recommend this video about user interface design at Apple:

How to Build an iPhone App that Doesn't Suck

That video changed the whole world for me - because it got me started making a paper model board game that I could play with family and see their reactions, without writing any lines of code.  It's also a lot of fun to cut out paper tiles and apply artwork.

But the real work that precedes the paper model, is the set of rules that makes the game.  I used a spreadsheet for writing out my rules, and could easily generate random board layouts - all of this builds up momentum and generates ideas.

The whole process eventually lead me to some generalizations about both board games and card games (possibly other genres too).  If you look at a well-designed game, you might imagine they used this process:


1) Create Layers

The simplest game I can imagine is to flip a coin: heads I get <something>, tails I don't.  I'll call this "directly dependent attainment".  The attainment of <something> is directly dependent on the coin toss.

Creating layers means adding indirect dependencies for attainment.  [And by naming the indirect dependencies creatively, a story-line is generated.]  So if we replace "flip a coin" with "open a goody hut", the goody hut may have a 50% chance of containing people (versus being empty).  Will the people be friendly or hostile?  It depends on <player stats OR technologies researched OR religion OR the phase of the moon>.

So the simple (and boring) coin toss game becomes interesting as layers of attainment are added - and a story is generated along the way.  I can think of resource combining, exploration, and technologies as these sorts of layers that make a game interesting.


2) Organize Dependencies To Maintain Parallelism

This is really all about story-telling.  Don't believe me?  Listen to that guy talking about his last poker game - or my mom talking my brother's ear off about the Scrabble game she won by 1 point (I almost had her!).  Maintaining parallelism of dependencies makes the story that much more compelling.

If you add several layers of dependencies for the player to create a specific unit (or issue a specific attack, or build a specific building, etc), each layer should contain related elements.  One layer might contain resources (the landscape), another layer contain technologies (the technology tree).  Don't put 1000 lbs of iron in the technology tree - it makes no sense!


3) Organize the Learning Curve

This might be more about presentation than it is game-play.  If the game is deep, can the game elements be organized such that players don't have to know all the rules before they can start?  In this way the game rules themselves are evolving as the game unfolds.


4) Subtlety Creates Depth

Here is where I bang my head against the wall - how are Chess and Go such wonderfully deep games with such simple and few rules?  If you watch or play many chess games, you start to see piece development and piece cooperation as key.  The story becomes more subtle even as it becomes more simple, less contrived.

These are what might be considered the highest art of gaming - a subtle story playing out, which like a good joke, maybe only a few will understand.


You'll find more discussion about game design in an earlier post Patterns and Rules.

Call for Android testers

Pre-Alpha Unity build for Android.

Ship shoots on a timer.  Touch the screen and ship follows your finger.  My high score is 200,000.

Feel free to try it.  Please let me know your results, heap size, etc.


http://tinyurl.com/cuwjmuk

Copyright 2012 Frank Braker

DIRECTIONS:

Download file from your Android phone.  Click on "Downloads" and click the 
downloaded file - it will ask if you want to install "SpaceWithText".  Install it and run.

This is a 3D test and AI demonstration.  It might not run on all Android phones.

Spawning cubes show their current behavior, which is driven by a behavior tree.

Patterns and Rules

Here's a good link:

http://www.gamasutra.com/view/feature/132649/the_case_for_game_design_patterns.php?print=1

While the author is talking about "Game Design Patterns", it brings up a progression of Design Pattern discussion:

http://www.slideshare.net/JoshuaKerievsky/a-timeless-way-of-communicating-alexandrian-pattern-languages

Perhaps most well known among software engineers is the "Gang of Four" Design Patterns book.  Whenever I've heard the term "patterns", I've assumed this was the usage.  Not true!  Design Patterns seem to have originated in architecture, with applications in gardening, theme park design - not just software.

The progression for game design continues to "The 400 Project", which is deliberately a list of "rules" rather than patterns, as discussed in the GDC presentations:

http://www.finitearts.com/Pages/400page.html

This is all fine.  It provides a great framework and vocabulary for discussion.  These are recipe books in architectural and experiential domains.

[Edit:  What I'm wondering now, is how to put wieners, rocks, paper and scissors to good use!]

[Edit: For GoF patterns, this also looks like a good discussion: http://www.oodesign.com ]

Behavior Trees

The general design in Unity is to write multiple behavior scripts, and attach them to a game object.  For example, a "rotate" script and a "shoot-at-anything-that-gets-close" script are attached to an object separately, rather than combining all behaviors into one script.

I like this approach - until an object needs to only apply behaviors selectively.  At that point I realized a finite state machine (FSM) was probably the way to go.  If an object had several scripts attached to it, there would need to be an FSM script which messaged all the other scripts so they knew what state the object was in.  Ugly.

Fine - ask Dr. Google.

People are still using FSMs out there - but the new glorious technology now seems to be Behavior Trees (BT).

I'm just beginning to teach myself about this tool.  There is some comparison between BT and hierarchical finite state machines (HFSM) - the latter which I have no experience with.

An FSM will go from state to state with transition events, and have the capacity to become a fascinating conversation piece among the more super-genius programmers spaghetti nightmare.  Even very simple FSMs can be painful to look at.

BT appears to remove some of the FSM free-form.  They seem to provide a framework of limited logic-flow.  It makes me wonder if eventually processors will be optimized around BT - because it looks like a sort of graphical programming language.  More importantly, it looks like a new way of thinking and building engines.

Here is the best summary page I've found so far (and an excellent blog overall on the subject):

http://aigamedev.com/open/articles/popular-behavior-tree-design/

Achievements versus Visions

I recently had a friend recommend I develop a game for the Microsoft Phone 7 platform.  So I started to look into it.  From only a small amount of digging, I found it would probably mean development in XNA, rather than Unity.  This is fine.

What stood out to me in one of the youtube "Here are all the cool games we have for MP7!" videos, was that they mention "Achievements".  This was a feature in Xbox360.  They are sort of like badges you can earn, and then when someone looks at your game profile (like all those girls who keep checking out which guys have earned the best achievements)...  well you get the picture.  Achievements are essentially a marketing tool to promote the platform, and they also provide the gamer a benefit in that they add visibility to parts of the game that haven't been reached yet.

This reminds me of my resume.  I get to take that resume to an interview, and the interviewer looks it over and says "so tell me about such and such".  But painful as it seems - it's true.  I really don't care about such and such.  Because that was yesterday's news.  And yes, it probably comes through in my voice.

So now I'm in the middle of creating a game.  I think it's worth going broke for.  Call me crazy.  And one of the features I'm looking forward to putting into the game is "Visions".  Instead of telling the player "You've gained the following worthless Achievment!" I'm going to tell them "You've gained the following Vision!"  The player gains a Vision BEFORE they work on a level or puzzle.

You see, having a vision really IS something.  It's the ability for full engagement in something you want to make happen.  That engagement will make you forget to eat, forget to sleep, forget that person who cut you off while driving to work this morning.  "Without Vision, the people perish."