#ruby warrior

Late last year I completed the Back End Web Development (a purely Ruby on Rails) course with General Assembly and I wanted to share a couple of the things I've learnt during my WDI course that I wish I knew back then.

Pry - Pry is to ruby programming what Jesus is to Christians. It's our saviour. When doing the Back End course I was blissfully unware of this gem (see what I did there?). My instructor had recommended a similar gem called debugger but I could never seem to get it working. This resulted in many frustrating hours wasted trying to figure out exactly what was / was not present in my params hash. Pry makes debugging a breeze. Simply add "require 'pry'" to your code, then add "binding.pry" at the point in your code where you want to launch into pry in terminal. Finally, type params to view what's inside the hash. You can also use "ls" while in pry to list all local / instance variables. It also makes creating some basic seed data to test a new model or relationship easy.

Zen Coding - This greatly reduces the amount of shitty HTML code you need to write and saves huge amounts of time. The beauty of Zen Coding is that it uses CSS syntax, so it's not like you are learning some arbitrary new syntax for this purpose.Simply type some CSS and press TAB and blam! your HTML is generated. In addition you can do things like "ul>li*3" which will generate an Unordered List with 3 List Items. Even better is just type "!" and press TAB to get a basic HTML template generated in seconds.

How you install this depends on what editor you have so look here for details https://code.google.com/p/zen-coding/. For Sublime Text 2 you need to use the Package Manager to install "Emmet"

Direct Database Access - During my previous course I was fully aware that a 'model' is an object that represents a row in the corresponding table in the database but had no idea how to view the database. How you do this will depend on if you're using postgres, sqlite3 or something else but it is definitely worth finding out.

With some fairly basic SQL knowledge this gives you a huge amount of visibility of what is going on with your program rather than solely relying on your models in Ruby. This is particularly useful in diagnosing why your relationships aren't working or even just to check that your models are in fact saving.

To access your database from terminal...

SQLite3 Navigate to where your .db file is sqlite3 [databasename.db] type ".schema" to display your table structure

Postgres Make sure postgres.app is actually running! psql [database_name] type "\d" to describe (display the tables)

From here you can run queries i.e. "select * from table_name;" and view the contents of your database.

Ruby Warrior - This game is amazing and educational so you should play it...

The following is a guest post by Carlos Lazo and originally appeared on his blog. Carlos is currently a student at The Flatiron School. You can follow him on Twitter here.

In Weeks 3 – 6 at Flatiron School, the focus has been on learning both the Sinatra and Rails web frameworks. Understanding the paradigms has been crucial in spinning up web applications “the right way”.

However, it’s important to remember the foundation on which these frameworks are built – the Ruby language. With only 6 weeks of Ruby knowledge under my belt, I want to continue understanding the principles of abstraction, modeling, and scope.

Enter the realm of Artificial Intelligence (AI).

Basic AI Principles

I’ve had the honor and pleasure of working with AI concepts in the Scheme programming language. I wanted to explore this realm in Ruby, and it turns out there’s a great venue. Before I get into that, let me define two common terms used in AI:

Agent: an autonomous entity which observes through sensors and acts upon an environment using actuators and directs its activity towards achieving goals.

Heuristic: a function that ranks alternatives in various search algorithms at each branching step based on the available information in order to make a decision about which branch to follow during a search.

Here’s a cool image that will make these definitions clearer:

Now with that background, onto Ruby Warrior.

What is Ruby Warrior?

The Ruby Warrior project (Github and Ruby Gem) was built as a vehicle to teach Ruby. How? Through the gamification of artificial intelligence.

Here’s a quick overview:

You (the player) are a Warrior in this world, with your primary objective being to scale levels of a tower.

There is a beginner / intermediate tower, both with ‘epic’ modes.

Each level is laid out differently, and can have a variety of components.

Monsters, Captives, Bombs, Walls, etc.

Each level grants the warrior more abilities.

You get to perform one and only one action(!) per turn based on whatever logic you choose to define.

More abilities lead to harder levels (e.g. more directions to move in).

A score is given per level based on different things: level clear speed, amount of action! used, captives rescued, etc.

Every turn, the play_turn method is called in player.rb file – this and any other files can be used, as long as play_turn calls one and only one action.

Climbing the Tower

For this post, my goal is to share how I’ve applied my Ruby skills to the first 4 levels. Here’s a quick legend regarding level layouts:

Legend: Tower Level Symbols

Level 01

Here is the representation of Level 01:

This level is pretty straightforward. Having only one action available [warrior.walk!], the logic here is simple:

Level 01 was completed and I achieved maximum points.

Lessons learned:

Model heuristic functionality based on immediate sufficiency.

Level 02

Here is the representation of Level 02:

This level introduced the first monster. I realized I needed to add logic to check to see if a monster was in front of me based on my available actions. Still pretty straightforward.

Level 02 was completed now completed.

Lessons learned:

Decision logic is going to get completed quick.

Probably worth refactoring and “setting the stage” in Level 03.

Able to make assumption that Player class is being initialized one time, with play_turnbeing called in a loop. Take advantage of the initialize method.

Level 03

Here is the representation of Level 03:

Four (4) monsters. Oh snap son.

As I began writing my code, I realized I didn’t want to do annoying amounts of nested logic. Projecting into the future, I felt the need to begin splitting parts of the agent into logical methods in an organized structure. I also needed to figure out when was the right time to rest, to keep moving forward, and when to attack.

Overall, I was really happy with my code – beat this level with no issues. Even though it grew in size, the play_turn method is readable and tells me exactly what the Warrior is to do at any given point in time.

Lessons learned:

(+) Breaking out logic into well-named functions was a great idea!

(–) Potential issues in the future with additional functionality (like more actions).

(–) Don’t like how each function needs to have warrior as a parameter.

Can this be fixed with instance variables in Level 04?

(–) ALL actions are evaluated even if an action is already called.

Given all the negatives, there was going to be some heavy-duty refactoring in Level 04. All in all though, I was fairly certain that the logic in the code was ‘just going to work’.

I couldn’t have been more wrong.

Level 04

Here is the representation of Level 04:

Enter the dreaded Archer – umm… f*ck.

This unit can attack from multiple spaces away. With my current logic, I’d rest when the space in front of me was empty and I wasn’t in combat. BUT I WAS IN COMBAT, since my health was decreasing by 1HP even though I was resting (rest = +2HP, attack = -3HP).

This now forced new state logic into my methods, along with some well-needed refactoring.

Awesome! This now gets around the ‘distance attack’ issue. If I’m being attacked from afar and the space in front of me is empty, do not rest and continue walking until you find and slay the offending monster.

Lessons learned:

(+) Building modular code makes it easy to add in edge cases.

(+) Constant refactoring makes for better flow.

(–) class Player is getting huge.

Consider splitting things into separate classes?

Interestingly enough, your Agent can always be “more intelligent”.

Shooting for the Top

I have a long way to go to reach the top of the Beginner tower, but this has been a tremendous learning experience. I’ve been able to apply Ruby principles to the challenging yet fun problem space of Artificial Intelligence.

A few things I’m thinking about going forward:

Future considerations:

Classes and further simplification makes sense.

The levels are only going to get harder:

Ability to move in different directions.

2-dimensional maps.

How will I track movement?

How will I behave when I hit a wall?

Rescuing captives.

Shooting ranged weapons.

Commanding a ‘golem’ during my turn.

Avoiding bombs that detonate.

I’m convinced that my upfront work will help prevent the following from happening:

Slowly but surely, I will become the Ruby Warrior I’m destined to be.

A shoutout to my boy Dan Friedman for working on this with me.