#psuedocode

Over the past 2 weeks part of our unit 2 assessment has been taking a game idea given by our teachers, writing it in pseudo code, creating a flow chart, then implementing it into an actual script, then creating a playable prototype in unity. The following images and gifs are the process and end result. It's not prettied up with art, but that wasn’t the point of the exercise.

Welcome back, dear reader.  The first week of Launch Academy's Summer 2014 cohort (the final 10 weeks of in-person problem solving and project building) is now history; one chapter in a book I hope to continue writing for many years to come.  History was always a favorite subject of mine in grade school.  Some kids found it boring, and sure, there were those periods of slow, plodding changes.  Man learns, over many years, how to plant crops and settle down in one place for a while - evolution.  

Evolution is the norm and evolution is great.  But what's really fascinating to me about history are those periods of rapid, sweeping changes.  Revolution!  Defying traditional systems of rule, reshaping social norms, introducing ideas that will manifest over centuries.  Washington, Robespierre and Marie Antoinette....those are the most compelling stories, right?  And in the history of my programming education, now is undoubtedly a time of revolution.

As summer approached I began questioning my decision to attend Launch.  Is it worth the money?  Worth the time and effort?  Is this the best way to grow into a well-grounded programmer?  The answer to each is a resounding yes.  So, in this one week, what has been so revolutionary?

Launch Academy has done fantastic job of bringing a truly diverse group of smart, motivated people together and pushing them to solve problems.  The most important things that we've learned in our first days here have not been new Ruby or Git syntax (although there's been plenty of that), but rather how to approach engineering challenges.  Have a tough problem that's making your head spin?  Don't you dare touch that keyboard.  Grab the whiteboard and diagram what needs to happen.  Use flow charts, and use plain English.  Now, pseudocode.  What are the end user's needs?  What smaller parts can we break this down into?

Think you've wrapped your head around the problem?  Good, but how well do you explain it to others?  Can you go up to the appropriate level of abstraction based on your audience?  Can you practice patience and put your ego aside in order to learn another, maybe better, way apart from what's comfortable to you?  Of course these aren't shocking concepts, this is common sense.  But common sense isn't always common, and the magic of Launch is in ensuring the implementation of these techniques.  It's one thing to preach the virtues of this flavor of critical thinking, but it is another thing entirely employ it out of necessity.

In our cohort's first week nearly everyone has put in 5 consecutive 10-12 hour days, and while we may end the day drained, enthusiasm abounds the next day.  Case in point, I'm now sitting at Mission Control writing this post on a beautiful Saturday afternoon with a room full of fellow Launchers, marked up whiteboards and code-filled text editors.  There is no requirement that we be here on weekends, only our desire to get better.  We are struggling together, learning from one another, and becoming practiced at applying these methods to challenging programming puzzles.  We've heard firsthand, from senior engineers like RBM's Johnny Boursiquot, about the importance of these problem solving and communication skills.

This is the value of Launch Academy; immersing yourself each day in not only the technical knowledge of web development, but in the mindset of pragmatically dissecting and producing solutions for problems.  Those are the abilities that employers want.  To know one technology or another is an asset, but understanding how to analyze, solve and communicate effectively is invaluable.

The big goal of the component based design is to have these components exist functionally isolated from each other.

However, these components still need to be able to communicate information. Graphics's animations will be based off of what it's doing, such as running if the entity is moving, If collision detects you bumped into a health power up, health needs to be informed to heal, or if health goes down to zero, a lot of things will need to know you've died.

The strength of components is their flexibility. If you wire a direct reference to another component (say the graphics gets a pointer to a physics) you lose that big advantage. Now you have to have a physics component. This coupling gets rapidly worse the more types of components that get added in.

But there's more than one way to find out important information. Instead of going around asking for information and being prepared to answer, having to deal with finding the right people to ask and those people possibly missing, we announce important information, and listen for the stuff we care about.

When something significant happens, you send a message to the entity. The entity then broadcasts this message out to the components. If it's something it cares about, you react. Otherwise, you just ignore it.

The funny thing is, this is where my brain got stuck for a while. I read again and again about this 'messaging' concept, but couldn't seem to figure it out. If I wanted to send a message about landing on the ground, I figured I needed to have something like this:

Entity {   send( Message m )   {  for each component: receive( Message m) } } Component {     receive( Message m)     {   ..// read message then react if necessary} }

This was akin to writing an actual letter, sending it to a supervisor, then having him show the message to every else. The message class itself started being the weird part because I would almost certainly need to pass some contextual information along with the message... a collision message would likely need to say where it occurred, a damage message how much...

These message might need to be stored if it's something that couldn't be resolved immediately... in which case all these new messages are fragmenting memory...

Well. I realized I was derping... I didn't have to make a message object at all.

sendMessage( int messageType, float x, float y)

receiveMessage( int messageType, float x, float y) {    if( messageType == something I care about)    {  do stuff }    if( messageType == something else I care about)    { do  other stuff }  }

This is perfectly fine for a collision message. If the component needs to store something, or queue it up, the component itself can do it. Say this graphics component needs to know if onGround, you give it a boolean flag for it, and if you receive an 'MessageType' equal to 'ON_GROUND', set it to true. When you go to draw, you reference your internal note, which won't change until some yells that you're OFF_GROUND.

If I need to send a message with a different structure, well, just make an additional send() for the Entity and complimentary receive() for the components.

Most messages will probably be ignored, which is fine.

It's also only another step to pass the messages along to something that say, do Achievements. Rather than have something that searches all over the place for relevant info, or inserting the achievement code into other parts of the code base, you can simply have an achievement component and listen.