Getting The Sample Code

You can find sample code at GitHub:\nhttps://github.com/spajus/ruby-gamedev-book-examples.

Clone it to a convenient location:

$ cd ~/gamedev\n$ git clone git@github.com:spajus/ruby-gamedev-book-examples.git\n

\n\n

Complete source code for the game that was built while writing this book is also available on\nGitHub. TODO add links when they are available.

",{"_465":466,"_42":43,"_46":47,"_44":45,"_64":65,"_467":468,"_578":463},"previewContent","

\n A Boy Who Wanted To Create Worlds\n
\n Why Ruby?\n
\n What You Should Know Before Reading This Book\n
\n What Are We Going To Build?\n
- \n Graphics\n
- \n Game Development Library\n
- \n Theme And Mechanics\n
\n
\n Preparing The Tools\n
- \n Getting Gosu to run on Mac Os X\n
\n
\n Getting The Sample Code\n
\n Other Tools\n
\n Gosu Basics\n
- \n Hello World\n
- \n Screen Coordinates And Depth\n
- \n Main Loop\n
- \n Moving Things With Keyboard\n
- \n Images And Animation\n
- \n Music And Sound\n
\n
\n Warming Up\n
- \n Using Tilesets\n
- \n Integrating With Texture Packer\n
- \n Combining Tiles Into A Map\n
- \n Using Tiled To Create Maps\n
- \n Loading Tiled Maps With Gosu\n
- \n Generating Random Map With Perlin Noise\n
- \n Player Movement With Keyboard And Mouse\n
- \n Game Coordinate System\n
\n
\n Prototyping The Game\n
- \n Switching Between Game States\n
- \n Implementing Menu State\n
- \n Implementing Play State\n
- \n Implementing World Map\n
- \n Implementing Floating Camera\n
- \n Implementing The Tank\n
- \n Implementing Bullets And Explosions\n
- \n Running The Prototype\n
\n
\n Optimizing Game Performance\n
- \n Profiling Ruby Code To Find Bottlenecks\n
- \n Advanced Profiling Techniques\n
- \n Optimizing Inefficient Code\n
- \n Profiling On Demand\n
- \n Adjusting Game Speed For Variable Performance\n
- \n Frame Skipping\n
\n
\n Refactoring The Prototype\n
- \n Game Programming Patterns\n
- \n What Is Wrong With Current Design\n
- \n Decoupling Using Component Pattern\n
\n
\n Simulating Physics\n
- \n Adding Enemy Objects\n
- \n Adding Bounding Boxes And Detecting Collisions\n
- \n Catching Bullets\n
- \n Implementing Turn Speed Penalties\n
- \n Implementing Terrain Speed Penalties\n
\n
\n Implementing Health And Damage\n
- \n Adding Health Component\n
- \n Inflicting Damage With Bullets\n
\n
\n Creating Artificial Intelligence\n
- \n Designing AI Using Finite State Machine\n
- \n Implementing AI Vision\n
- \n Controlling Tank Gun\n
- \n Implementing AI Input\n
- \n Implementing Tank Motion States\n
- \n Wiring Tank Motion States Into Finite State Machine\n
\n
\n Making The Prototype Playable\n
- \n Drawing Water Beyond Map Boundaries\n
- \n Generating Tree Clusters\n
- \n Generating Random Objects\n
- \n Implementing A Radar\n
- \n Dynamic Sound Volume And Panning\n
- \n Giving Enemies Identity\n
- \n Respawning Tanks And Removing Dead Ones\n
- \n Displaying Explosion Damage Trails\n
- \n Debugging Bullet Physics\n
- \n Making Camera Look Ahead\n
- \n Reviewing The Changes\n
\n
\n Dealing With Thousands Of Game Objects\n
- \n Spatial Partitioning\n
- \n Implementing A Quadtree\n
- \n Integrating ObjectPool With QuadTree\n
- \n Moving Objects In QuadTree\n
\n
\n Implementing Powerups\n
- \n Implementing Base Powerup\n
- \n Implementing Powerup Graphics\n
- \n Implementing Powerup Sounds\n
- \n Implementing Repair Damage Powerup\n
- \n Implementing Health Boost\n
- \n Implementing Fire Rate Boost\n
- \n Implementing Tank Speed Boost\n
- \n Spawning Powerups On Map\n
- \n Respawning Powerups After Pickup\n
\n
\n Implementing Heads Up Display\n
- \n Design Considerations\n
- \n Rendering Text With Custom Font\n
- \n Implementing HUD Class\n
\n
\n Implementing Game Statistics\n
- \n Tracking Kills, Deaths and Damage\n
- \n Making Damage Personal\n
- \n Tracking Damage From Chain Reactions\n
- \n Displaying Game Score\n
\n
\n Building Advanced AI\n
- \n Improving Tank Navigation\n
- \n Implementing Demo State To Observe AI\n
- \n Visual AI Debugging\n
- \n Making AI Collect Powerups\n
- \n Seeking Health Powerups After Heavy Damage\n
- \n Evading Collisions And Getting Unstuck\n
\n
\n Wrapping It Up\n
- \n Lessons Learned\n
\n
\n Special Thanks\n

A Boy Who Wanted To Create Worlds

\n\n

Once there was a boy who fell in love with this magical device that could bring things to life\ninside a glaring screen. He spent endless hours exploring imaginary worlds, fighting strange\ncreatures, shooting pixelated spaceships, racing boxy cars. The boy kept pondering. “How is this\nmade? I want to create my own worlds…”.

\n\n

Then he discovered programming. “I can finally do it!” - he thought. And he tried. And failed. Then\nhe tried harder. He failed again and again. He was too naive to realize that those worlds he was\ntrying to create were too sophisticated, and his knowledge was too limited. He gave up creating\nthose worlds.

\n\n

What he didn’t give up is writing code for this magical device. He realized he isn’t smart enough\nto create worlds, yet he found out he could create simpler things like small applications - web,\ndesktop, server side or whatnot. Few years later he found himself getting paid to make those.

\n\n

Applications got increasingly bigger, they spanned across multiple servers, integrated with\neach other, became pats of huge infrastructures. The boy, now a grown man, was all into it.\nIt was fun and challenging enough to spend over 10000 hours learning and building what others\nwanted him to build.

\n\n

Some of these things were useful, some where boring and pointless. Some were never finished. There\nwere things he was proud of, there were others that he wouldn’t want to talk about, nonetheless\neverything he built made him a better builder. Yet he never found the time, courage or\nreason to build what he really wanted to build since he was a little boy - his own worlds.

\n\n

Until one day he realized that no one can stop him from following his dream. He felt that equipped\nwith his current knowledge and experience he will be able to learn to create worlds of his own. And\nhe went for it.

\n\n

This boy must live in many software developers, who dream about creating games, but instead sell\ntheir software craftsmanship skills to those who need something else. This boy is me, and you. And\nit’s time to set him free.

\n\n

Welcome to the world of game development that was waiting for you all these years.

\n\n

Why Ruby?

\n\n

When it comes to game development, everyone will tell you that you should go with C++ or some other\nstatically typed language that compiles down to bare metal instructions. Or that you should go with\nfull blown game development platform like Unity. Slow, dynamic languages\nlike Ruby seem like the last choice any sane game developer would go for.

\n\n

A friend of mine said “There’s little\nreason to develop a desktop game with Ruby”, and he was absolutely right. Perhaps this is the\nreason why there are no books about it. All the casual game action happens in mobile devices, and\ndesktop games are for seasoned gamers who demand fast and detailed 3D graphics, motion-captured\nanimations and sophisticated game mechanics - things we know we are not going to be able to build\non our own, without millions from VC pockets and Hollywood grade equipment.

\n\n

Now, bear with me. Your game will not be a 3D MMORPG set in huge, photo realistic\nrepresentation of Middle-earth. Let’s leave those things to Bethesda, Ubisoft and Rockstar Games.\nAfter all, everyone has to start somewhere, and you have to be smart enough to understand, that\neven though that little boy in you wants to create an improved version of Grand Theft Auto V, we\nwill have to go for something that resembles lesser known Super Nintendo titles instead.

\n\n

Why not go mobile then? Those devices seem perfect for simpler games. If you are a true gamer at\nheart, you will agree that touch screen games you find in modern phones and tablets are only good\nfor killing 10 minutes of your time while taking a dump. You have to feel the resistance when you\nclick a button! Screen size also does matter. Playing anything on mobile phone is a torture for\nthose who know what playing real games should feel like.

\n\n

So, your game will have to be small enough for you to be able to complete it, it will have to have\nsimple 2D graphics, and would not require the latest GeForce with at least 512MB of RAM. This\nfact gives you the benefit of choice. You don’t have to worry about performance that much. You can\nchoose a friendly and productive language that is designed for programmer happiness. And this is\nwhere Ruby starts to shine. It’s beautiful, simple and elegant. It is close to poetry.

\n\n

What You Should Know Before Reading This Book

\n\n

As you can read on the cover, this book is “for those who write code for living”. It’s\nnot a requirement, and you will most likely be able to understand everything even if you are a\nstudent or hobbyist, but this book will not teach you how to be a good programmer. If you want to\nlearn that, start with timeless classic: The Pragmatic Programmer: From Journeyman to\nMaster.

\n\n

You should understand Ruby at least to some extent. There are plenty of books and resources\ncovering that subject. Try\nWhy’s Poignant Guide To Ruby or\nEloquent Ruby. You can also learn it\nwhile reading this book. It shouldn’t be too hard, especially if you already write code for living.\nAfter all programming language is merely a tool, and when you learn one, others are relatively\neasy to switch to.

\n\n

You should know how to use the command line. Basic knowledge of Git can also\nbe handy.

\n\n

You don’t have to know how to draw or compose music. We will use media that is\navailable for free. However, knowledge of graphics and audio editing software won’t hurt.

\n\n

What Are We Going To Build?

\n\n

This question is of paramount importance. The answer will usually determine if you will likely to\nsucceed. If you want to overstep your boundaries, you will fail. It shouldn’t be too easy either.\nIf you know something about programming already, I bet you can implement Tic Tac Toe, but will you\nfeel proud about it? Will you be able to say “I’ve built a world!”. I wouldn’t.

\n\n

Graphics

\n\n

To begin with, we need to know what kind of graphics we are aiming for. We will instantly rule out\n3D for several reasons:

\n\n

We don’t want to increase the scope and complexity
Ruby may not be fast enough for 3D games
Learning proper 3D graphics programming requires reading a separate book that is several times\nthicker than this one.

Now, we have to swallow our pride and accept the fact that the game will have simple 2D graphics.\nThere are three choices to go for:

\n\n

Parallel Projection
Top Down
Side-Scrolling

Parallel Projection (think Fallout 1 & 2) is pretty close to 3D graphics, it requires detailed art\nif you want it to look decent, so we would have a rough start if we went for it.

\n\n

Top Down view (old titles of Legend of Zelda) offers plenty of freedom to explore the environment\nin all directions and requires less graphical detail, since things look simpler from above.

\n\n

Side Scrolling games (Super Mario Bros.) usually involve some physics related to jumping and\nrequire more effort to look good. Feeling of exploration is limited, since you usually move from\nleft to right most of the time.

\n\n

Going with Top Down view will give us a chance to create our game world as open for exploration as\npossible, while having simple graphics and movement mechanics. Sounds like the best choice for us.

\n\n

Since you are probably as bad in drawing things as I am, you could still wonder how we are going\nto get our graphics. Thankfully, there is this opengameart.org. It’s like\nGitHub of game media, we will surely find something there. It also contains audio samples and\ntracks.

\n\n

Game Development Library

\n\n

Implement it all yourself or harness the power of some game development library that offers you\nboilerplates and convenient access to common functions? If you’re like me, you would definitely\nwant to implement it all yourself, but that may be the reason why I failed to make a decent game so\nmany times.

\n\n

If you will try to implement it all yourself, you will most likely end up reimplementing some\nexisting game library, poorly. It won’t take long while you reach a point where you need to\ninterface with underlying operating system libraries to get graphics. And guess if those bindings\nwill work in a different operating system?

\n\n

So, swallow your pride again, because we are going to use an existing game development library.\nGood news is that you will be able to actually finish the game, and it will be portable to Windows,\nMac and Linux. We will still have to build our own game engine for ourselves on top of it, so don’t\nthink it won’t be fun.

\n\n

There are several game libraries\navailable for Ruby, but it’s a simple choice, because Gosu is head and\nshoulders above others. It’s very mature, has a large and active community, and it is mainly\nwritten in C++ but has first class Ruby support, so it will be both fast and convenient to use.

\n\n

Many of other Ruby game libraries are built on top of Gosu, so it’s a solid choice.

\n\n

Theme And Mechanics

\n\n

Choosing the right theme is undoubtedly important. It should be something that appeals to you,\nsomething you will want to play, and it should not imply difficult game mechanics. I love MMORPGs,\nand I always dreamed of making an open world game where you can roam around, meet other players,\nfight monsters and level up. Guess how many times I started building such a game? Even if I\nwouldn’t have lost the count, I wouldn’t be proud to say the number.

\n\n

This time, equipped with logic and sanity, I’ve picked something challenging enough, yet still\npretty simple to build. Are you ready?

\n\n

Drumroll…

\n\n

We will be building a multi directional shooter arcade game where you control a tank, roam around\nan island, shoot enemy tanks and try not to get destroyed by others.

\n\n

If you have played Battle City or\nTank Force, you should easily get the idea. I believe\nthat implementing such a game (with several twists) would expose us to perfect level of difficulty\nand provide substantial amount of experience.

\n\n

We will use a subset of these gorgeous graphics\nwhich are available on opengameart.org, generously provided\nby Csaba Felvegi.

\n\n

Preparing The Tools

\n\n

While writing this book, I will be using Mac OS X (10.9), but it should be possible to run all the\nexampls on other operating systems too.

\n\n

Gosu Wiki has “Getting Started” pages for\nMac,\nLinux and\nWindows, so I will not be going\ninto much detail here.

\n\n

Getting Gosu to run on Mac Os X

\n\n

If you haven’t set up your Mac for development, first install Xcode using App Store.\nSystem Ruby should work just fine, but you may want to use\nRbenv or RVM to avoid polluting system\nRuby. I’ve had trouble installing Gosu with RVM, but your experience may vary.

\n\n

To install the gem, simply run:

\n\n

$ gem install gosu\n

\n\n

You may need to prefix it with sudo if you are using system Ruby.

\n\n

To test if gem was installed correctly, you should be able to run this to produce an empty black\nwindow:

\n\n

$ irb\nirb(main):001:0> require 'gosu'\n=> true\nirb(main):002:0> Gosu::Window.new(320, 240, false).show\n=> nil\n

\n\n

Most developers who use Mac every day will also recommend installing Homebrew\npackage manager, replace Terminal app with iTerm2 and use\nOh-My-Zsh to manage ZSH configuration.

\n\n

Getting The Sample Code

\n\n

You can find sample code at GitHub:\nhttps://github.com/spajus/ruby-gamedev-book-examples.

\n\n

Clone it to a convenient location:

\n\n

$ cd ~/gamedev\n$ git clone git@github.com:spajus/ruby-gamedev-book-examples.git\n

\n\n

Complete source code for the game that was built while writing this book is also available on\nGitHub. TODO add links when they are available.

\n\n

Other Tools

\n\n

All you need for this adventure is a good text editor, terminal and probably some graphics editor.\nTry GIMP if you want a free one. I’m using\nPixelmator, it’s wonderful, but for Mac only. A noteworthy fact is\nthat Pixelmator was built by fellow Lithuanians.

\n\n

When it comes to editors, I don’t leave home without Vim, but as long as what you use makes you\nproductive, it doesn’t make any difference. Vim, Emacs or Sublime are all good enough to write\ncode, just have some good plugins that support Ruby, and you’re set. If you really feel you need\nan IDE, which may be the case if you are coming from a static language, you can’t go wrong with\nRubyMine.

\n\n

Gosu Basics

\n\n

By now Gosu should be installed and ready for a spin. But before we rush into building our game, we\nhave to get acquainted with our library. We will go through several simple examples, familiarize\nourselves with Gosu architecture and core principles, and take a couple of baby steps towards\nunderstanding how to put everything together.

\n\n

To make this chapter easier to read and understand, I recommend watching\nWriting Games With Ruby\ntalk given by Mike Moore at LA Ruby Conference 2014. In fact, this talk\npushed me towards rethinking this crazy idea of using Ruby for game development, so this book\nwouldn’t exist without it. Thank you, Mike.

\n\n

Hello World

\n\n

To honor the traditions, we will start by writing “Hello World” to get a taste of what Gosu feels\nlike. It is based on Ruby Tutorial that you can\nfind in Gosu Wiki.

\n\n

01-hello/hello_world.rb

\n\n

 1 require 'gosu'\n 2 \n 3 class GameWindow < Gosu::Window\n 4   def initialize(width=320, height=240, fullscreen=false)\n 5     super\n 6     self.caption = 'Hello'\n 7     @message = Gosu::Image.from_text(\n 8       self, 'Hello, World!', Gosu.default_font_name, 30)\n 9   end\n10 \n11   def draw\n12     @message.draw(10, 10, 0)\n13   end\n14 end\n15 \n16 window = GameWindow.new\n17 window.show\n

\n\n

Run the code:

\n\n

$ ruby 01-hello/hello_world.rb\n

\n\n

You should see a neat small window with your message:

\n\n

\n $\"Hello$

Hello World

\n\n

See how easy that was? Now let’s try to understand what just happened here.

\n\n

We have extended Gosu::Window with our own\nGameWindow class, initializing it as 320x240 window. super passed width, height and\nfullscreen initialization parameters from GameWindow to Gosu::Window.

\n\n

Then we defined our window’s\ncaption, and created\n@message instance variable with an image generated from text \"Hello, World!\" using\nGosu::Image.from_text.

\n\n

We have overridden\nGosu::Window#draw instance\nmethod that gets called every time Gosu wants to redraw our game window. In that method we call\ndraw on our\n@message variable, providing x and y screen coordinates both equal to 10, and z (depth)\nvalue equal to 0.

\n\n

Screen Coordinates And Depth

\n\n

Just like most conventional computer graphics libraries, Gosu treats x as horizontal axis (left to\nright), y as vertical axis (top to bottom), and z as order.

\n\n

\n $\"Screen$

Screen coordinates and depth

\n\n

x and y are measured in pixels, and value of z is a relative number that doesn’t mean\nanything on it’s own. The pixel in top-left corner of the screen has coordinates of 0:0.

\n\n

z order in Gosu is just like z-index in CSS. It does not define zoom level, but\nin case two shapes overlap, one with higher z value will be drawn on top.

\n\n

Main Loop

\n\n

The heart of Gosu library is the main loop\nthat happens in Gosu::Window.

\n\n

TODO write more about main loop

\n\n

Moving Things With Keyboard

\n\n

We will modify our “Hello, World!” example to learn how to move things on screen. The following\ncode will print coordinates of the message along with number of times screen was redrawn. It also\nallows exiting the program by hitting Esc button.

\n\n

01-hello/hello_movement.rb

\n\n

 1 require 'gosu'\n 2 \n 3 class GameWindow < Gosu::Window\n 4   def initialize(width=320, height=240, fullscreen=false)\n 5     super\n 6     self.caption = 'Hello Movement'\n 7     @x = @y = 10\n 8     @draws = 0\n 9     @buttons_down = 0\n10   end\n11 \n12   def update\n13     @x -= 1 if button_down?(Gosu::KbLeft)\n14     @x += 1 if button_down?(Gosu::KbRight)\n15     @y -= 1 if button_down?(Gosu::KbUp)\n16     @y += 1 if button_down?(Gosu::KbDown)\n17   end\n18 \n19   def button_down(id)\n20     close if id == Gosu::KbEscape\n21     @buttons_down += 1\n22   end\n23 \n24   def button_up(id)\n25     @buttons_down -= 1\n26   end\n27 \n28   def needs_redraw?\n29     @draws == 0 || @buttons_down > 0\n30   end\n31 \n32   def draw\n33     @draws += 1\n34     @message = Gosu::Image.from_text(\n35       self, info, Gosu.default_font_name, 30)\n36     @message.draw(@x, @y, 0)\n37   end\n38 \n39   private\n40 \n41   def info\n42     \"[x:#{@x};y:#{@y};draws:#{@draws}]\"\n43   end\n44 end\n45 \n46 window = GameWindow.new\n47 window.show\n

\n\n

Run the program and try pressing arrow keys:

\n\n

$ ruby 01-hello/hello_movement.rb\n

\n\n

The message will move around as long as you keep arrow keys pressed.

\n\n

\n $\"Use$

Use arrow keys to move the message around

\n\n

We could write a shorter version, but the point here is that if we wouldn’t override\nneeds_redraw?\nthis program would be slower by order of magnitude, because it would create @message object every\ntime it wants to redraw the window, even though nothing would change.

\n\n

Here is a screenshot of top displaying two versions of this program. Second screen has\nneeds_redraw? method removed. See the difference?

\n\n

\n $\"Redrawing$

Redrawing only when necessary VS redrawing every time

\n\n

Ruby is slow, so you have to use it wisely.

\n\n

Images And Animation

\n\n

It’s time to make something more exciting. Our game will have to have explosions, therefore we need\nto learn to animate them. We will set up a background scene and trigger explosions on top of it\nwith our mouse.

\n\n

01-hello/hello_animation.rb

\n\n

 1 require 'gosu'\n 2 \n 3 def media_path(file)\n 4   File.join(File.dirname(File.dirname(\n 5     __FILE__)), 'media', file)\n 6 end\n 7 \n 8 class Explosion\n 9   FRAME_DELAY = 10 # ms\n10   SPRITE = media_path('explosion.png')\n11 \n12   def self.load_animation(window)\n13     Gosu::Image.load_tiles(\n14       window, SPRITE, 128, 128, false)\n15   end\n16 \n17   def initialize(animation, x, y)\n18     @animation = animation\n19     @x, @y = x, y\n20     @current_frame = 0\n21   end\n22 \n23   def update\n24     @current_frame += 1 if frame_expired?\n25   end\n26 \n27   def draw\n28     return if done?\n29     image = current_frame\n30     image.draw(\n31       @x - image.width / 2.0,\n32       @y - image.height / 2.0,\n33       0)\n34   end\n35 \n36   def done?\n37     @done ||= @current_frame == @animation.size\n38   end\n39 \n40   private\n41 \n42   def current_frame\n43     @animation[@current_frame % @animation.size]\n44   end\n45 \n46   def frame_expired?\n47     now = Gosu.milliseconds\n48     @last_frame ||= now\n49     if (now - @last_frame) > FRAME_DELAY\n50       @last_frame = now\n51     end\n52   end\n53 end\n54 \n55 class GameWindow < Gosu::Window\n56   BACKGROUND = media_path('country_field.png')\n57 \n58   def initialize(width=800, height=600, fullscreen=false)\n59     super\n60     self.caption = 'Hello Animation'\n61     @background = Gosu::Image.new(\n62       self, BACKGROUND, false)\n63     @animation = Explosion.load_animation(self)\n64     @explosions = []\n65   end\n66 \n67   def update\n68     @explosions.reject!(&:done?)\n69     @explosions.map(&:update)\n70   end\n71 \n72   def button_down(id)\n73     close if id == Gosu::KbEscape\n74     if id == Gosu::MsLeft\n75       @explosions.push(\n76         Explosion.new(\n77           @animation, mouse_x, mouse_y))\n78     end\n79   end\n80 \n81   def needs_cursor?\n82     true\n83   end\n84 \n85   def needs_redraw?\n86     !@scene_ready || @explosions.any?\n87   end\n88 \n89   def draw\n90     @scene_ready ||= true\n91     @background.draw(0, 0, 0)\n92     @explosions.map(&:draw)\n93   end\n94 end\n95 \n96 window = GameWindow.new\n97 window.show\n

\n\n

Run it and click around to enjoy those beautiful special effects:

\n\n

$ ruby 01-hello/hello_animation.rb\n

\n\n

\n $\"Multiple$

Multiple explosions on screen

\n\n

Now let’s figure out how it works. Our GameWindow initializes with @background\nGosu::Image and @animation, that holds array\nof Gosu::Image instances, one for each frame of explosion.\nGosu::Image.load_tiles\nhandles it for us.

\n\n

Explosion::SPRITE points to “tileset” image, which is just a regular image that contains equally\nsized smaller image frames arranged in ordered sequence. Rows of frames are read left to right,\nlike you would read a book.

\n\n

\n $\"Explosion$

Explosion tileset

\n\n

Given that explosion.png tileset is 1024x1024 pixels big, and it has 8 rows of 8 tiles per row,\nit is easy to tell that there are 64 tiles 128x128 pixels each. So, @animation[0] holds\n128x128 Gosu::Image with top-left tile, and\n@animation[63] - the bottom-right one.

\n\n

Gosu doesn’t handle animation, it’s something you have full control over. We have to draw each tile\nin a sequence ourselves. You can also use tiles to hold map graphics The logic behind this is pretty simple:

\n\n

\nExplosion knows it’s @current_frame number. It begins with 0.
\nExplosion#frame_expired? checks the last time when @current_frame was rendered, and when it\nis older than Explosion::FRAME_DELAY milliseconds, @current_frame is increased.
When GameWindow#update\nis called, @current_frame is recalculated for all @explosions. Also, explosions that have\nfinished their animation (displayed the last frame) are removed from @explosions array.
\nGameWindow#draw draws\nbackground image and all @explosions draw their current_frame.
Again, we are saving resources and not redrawing when there are no @explosions in progress.\nneeds_redraw? handles it.

It is important to understand that update and draw order is unpredictable, these methods can be\ncalled by your system at different rate, you can’t tell which one will be called more often than\nthe other one, so update should only be concerned with advancing object state, and draw should\nonly draw current state on screen if it is needed. The only reliable thing here is time, consult\nGosu.milliseconds to know how\nmuch time have passed.

\n\n

Rule of the thumb: draw should be as lightweight as possible. Prepare all calculations in\nupdate and you will have responsive, smooth graphics.

\n\n

Music And Sound

\n\n

Our previous program was clearly missing a soundtrack, so we will add one. A background music will\nbe looping, and each explosion will become audible.

\n\n

01-hello/hello_sound.rb

\n\n

  1 require 'gosu'\n  2 \n  3 def media_path(file)\n  4   File.join(File.dirname(File.dirname(\n  5     __FILE__)), 'media', file)\n  6 end\n  7 \n  8 class Explosion\n  9   FRAME_DELAY = 10 # ms\n 10   SPRITE = media_path('explosion.png')\n 11 \n 12   def self.load_animation(window)\n 13     Gosu::Image.load_tiles(\n 14       window, SPRITE, 128, 128, false)\n 15   end\n 16 \n 17   def self.load_sound(window)\n 18     Gosu::Sample.new(\n 19       window, media_path('explosion.mp3'))\n 20   end\n 21 \n 22   def initialize(animation, sound, x, y)\n 23     @animation = animation\n 24     sound.play\n 25     @x, @y = x, y\n 26     @current_frame = 0\n 27   end\n 28 \n 29   def update\n 30     @current_frame += 1 if frame_expired?\n 31   end\n 32 \n 33   def draw\n 34     return if done?\n 35     image = current_frame\n 36     image.draw(\n 37       @x - image.width / 2.0,\n 38       @y - image.height / 2.0,\n 39       0)\n 40   end\n 41 \n 42   def done?\n 43     @done ||= @current_frame == @animation.size\n 44   end\n 45 \n 46   def sound\n 47     @sound.play\n 48   end\n 49 \n 50   private\n 51 \n 52   def current_frame\n 53     @animation[@current_frame % @animation.size]\n 54   end\n 55 \n 56   def frame_expired?\n 57     now = Gosu.milliseconds\n 58     @last_frame ||= now\n 59     if (now - @last_frame) > FRAME_DELAY\n 60       @last_frame = now\n 61     end\n 62   end\n 63 end\n 64 \n 65 class GameWindow < Gosu::Window\n 66   BACKGROUND = media_path('country_field.png')\n 67 \n 68   def initialize(width=800, height=600, fullscreen=false)\n 69     super\n 70     self.caption = 'Hello Animation'\n 71     @background = Gosu::Image.new(\n 72       self, BACKGROUND, false)\n 73     @music = Gosu::Song.new(\n 74       self, media_path('menu_music.mp3'))\n 75     @music.volume = 0.5\n 76     @music.play(true)\n 77     @animation = Explosion.load_animation(self)\n 78     @sound = Explosion.load_sound(self)\n 79     @explosions = []\n 80   end\n 81 \n 82   def update\n 83     @explosions.reject!(&:done?)\n 84     @explosions.map(&:update)\n 85   end\n 86 \n 87   def button_down(id)\n 88     close if id == Gosu::KbEscape\n 89     if id == Gosu::MsLeft\n 90       @explosions.push(\n 91         Explosion.new(\n 92           @animation, @sound, mouse_x, mouse_y))\n 93     end\n 94   end\n 95 \n 96   def needs_cursor?\n 97     true\n 98   end\n 99 \n100   def needs_redraw?\n101     !@scene_ready || @explosions.any?\n102   end\n103 \n104   def draw\n105     @scene_ready ||= true\n106     @background.draw(0, 0, 0)\n107     @explosions.map(&:draw)\n108   end\n109 end\n110 \n111 window = GameWindow.new\n112 window.show\n

\n\n

Run it and enjoy the cinematic experience. Adding sound really makes a difference.

\n\n

$ ruby 01-hello/hello_sound.rb\n

\n\n

We only added couple of things over previous example.

\n\n

72 @music = Gosu::Song.new(\n73   self, media_path('menu_music.mp3'))\n74 @music.volume = 0.5\n75 @music.play(true)\n

\n\n

GameWindow creates\nGosu::Song with menu_music.mp3, adjusts the\nvolume so it’s a little more quiet and starts playing in a loop.

\n\n

16 def self.load_sound(window)\n17   Gosu::Sample.new(\n18     window, media_path('explosion.mp3'))\n19 end\n

\n\n

Explosion has now got load_sound method that loads explosion.mp3 sound effect\nGosu::Sample. This sound effect is loaded once in\nGameWindow constructor, and passed into every new Explosion, where it simply starts playing.

\n\n

Handling audio with Gosu is very straightforward. Use\nGosu::Song to play background music, and\nGosu::Sample to play effects and sounds that can\noverlap.

\n\n

Warming Up

\n\n

Before we start building our game, we want to flex our skills little more, get to know Gosu better\nand make sure our tools will be able to meet our expectations.

\n\n

Using Tilesets

\n\n

After playing around with Gosu for a while, we should be comfortable enough to implement a\nprototype of top-down view game map using the tileset of our choice. This ground\ntileset looks like a good place to\nstart.

\n\n

Integrating With Texture Packer

\n\n

After downloading and extracting the tileset, it’s obvious that\nGosu::Image#load_tiles\nwill not suffice, since it only supports tiles of same size, and there is a tileset in the package\nthat looks like this:

\n\n

\n $\"Tileset$

Tileset with tiles of irregular size

\n\n

And there is also a JSON file that contains some metadata:

\n\n

{\"frames\": {\n\"aircraft_1d_destroyed.png\":\n{\n  \"frame\": {\"x\":451,\"y\":102,\"w\":57,\"h\":42},\n  \"rotated\": false,\n  \"trimmed\": false,\n  \"spriteSourceSize\": {\"x\":0,\"y\":0,\"w\":57,\"h\":42},\n  \"sourceSize\": {\"w\":57,\"h\":42}\n},\n\"aircraft_2d_destroyed.png\":\n{\n  \"frame\": {\"x\":2,\"y\":680,\"w\":63,\"h\":47},\n  \"rotated\": false,\n  \"trimmed\": false,\n  \"spriteSourceSize\": {\"x\":0,\"y\":0,\"w\":63,\"h\":47},\n  \"sourceSize\": {\"w\":63,\"h\":47}\n},\n...\n}},\n\"meta\": {\n\t\"app\": \"http://www.texturepacker.com\",\n\t\"version\": \"1.0\",\n\t\"image\": \"decor.png\",\n\t\"format\": \"RGBA8888\",\n\t\"size\": {\"w\":512,\"h\":1024},\n\t\"scale\": \"1\",\n\t\"smartupdate\": \"$TexturePacker:SmartUpdate:2e6b6964f24c7abfaa85a804e2dc1b05$\"\n}\n

\n\n

Looks like these tiles were packed with Texture Packer. After some\ndigging I’ve discovered that Gosu doesn’t have any integration with it, so I had these choices:

\n\n

Cut the original tileset image into smaller images.
Parse JSON and harness the benefits of Texture Packer.

First option was too much work and would prove to be less efficient, because loading many small\nfiles is always worse than loading one bigger file. Therefore, second option was the winner, and I\nalso thought “why not write a gem while I’m at it”. And that’s exactly what I did, and you should\ndo the same in such a situation. The gem is available on GitHub:

\n\n

https://github.com/spajus/gosu-texture-packer

\n\n

You can install this gem using gem install gosu_texture_packer. If you want to examine the code,\neasiest way is to clone it on your computer:

\n\n

$ git clone\n

\n\n

Let’s examine the main idea behind this gem. Here is a slightly simplified version that does\nhandles everything in under 20 lines of code:

\n\n

02-warmup/tileset.rb

\n\n

 1 require 'json'\n 2 class Tileset\n 3   def initialize(window, json)\n 4     @json = JSON.parse(File.read(json))\n 5     image_file = File.join(\n 6       File.dirname(json), @json['meta']['image'])\n 7     @main_image = Gosu::Image.new(\n 8       @window, image_file, true)\n 9   end\n10 \n11   def frame(name)\n12     f = @json['frames'][name]['frame']\n13     @main_image.subimage(\n14       f['x'], f['y'], f['w'], f['h'])\n15   end\n16 end\n

\n\n

If by now you are familiar with Gosu documentation, you will wonder\nwhat the hell is\nGosu::Image#subimage. At the point of writing it was not documented, and I\naccidentally discovered\nit while digging\nthrough Gosu source code.

\n\n

I’m lucky this function existed, because I was ready to bring out the heavy artillery and use\nRMagick to extract those tiles. We will probably need RMagick\nat some point of time later, but it’s better to avoid dependencies as long as possible.

\n\n

Combining Tiles Into A Map

\n\n

With tileset loading issue out of the way, we can finally get back to drawing that cool map of\nours.

\n\n

The following program will fill the screen with random tiles.

\n\n

02-warmup/random_map.rb

\n\n

 1 require 'gosu'\n 2 require 'gosu_texture_packer'\n 3 \n 4 def media_path(file)\n 5   File.join(File.dirname(File.dirname(\n 6     __FILE__)), 'media', file)\n 7 end\n 8 \n 9 class GameWindow < Gosu::Window\n10   WIDTH = 800\n11   HEIGHT = 600\n12   TILE_SIZE = 128\n13 \n14   def initialize\n15     super(WIDTH, HEIGHT, false)\n16     self.caption = 'Random Map'\n17     @tileset = Gosu::TexturePacker.load_json(\n18       self, media_path('ground.json'), :precise)\n19     @redraw = true\n20   end\n21 \n22   def button_down(id)\n23     close if id == Gosu::KbEscape\n24     @redraw = true if id == Gosu::KbSpace\n25   end\n26 \n27   def needs_redraw?\n28     @redraw\n29   end\n30 \n31   def draw\n32     @redraw = false\n33     (0..WIDTH / TILE_SIZE).each do |x|\n34       (0..HEIGHT / TILE_SIZE).each do |y|\n35         @tileset.frame(\n36           @tileset.frame_list.sample).draw(\n37             x * (TILE_SIZE),\n38             y * (TILE_SIZE),\n39             0)\n40       end\n41     end\n42   end\n43 end\n44 \n45 window = GameWindow.new\n46 window.show\n

\n\n

Run it, then press spacebar to refill the screen with random tiles.

\n\n

$ ruby 02-warmup/random_map.rb\n

\n\n

\n $\"Map$

Map filled with random tiles

\n\n

The result doesn’t look seamless, so we will have to figure out what’s wrong. After playing around\nfor a while, I’ve noticed that it’s an issue with Gosu::Image.

\n\n

When you load a tile like this, it works perfectly:

\n\n

Gosu::Image.new(self, image_path, true, 0, 0, 128, 128)\nGosu::Image.load_tiles(self, image_path, 128, 128, true)\n

\n\n

And the following produces so called “texture bleeding”:

\n\n

Gosu::Image.new(self, image_path, true)\nGosu::Image.new(self, image_path, true).subimage(0, 0, 128, 128)\n

\n\n

Good thing we’re not building our game yet, right? Welcome to the intricacies of software\ndevelopment!

\n\n

Now, I have reported my findings, but until it gets\nfixed, we need a workaround. And the workaround was to use RMagick. I knew we won’t get too far\naway from it. But our random map now looks gorgeous:

\n\n

\n $\"Map$

Map filled with seamless random tiles

\n\n

Using Tiled To Create Maps

\n\n

While low level approach to drawing tiles in screen may be appropriate in some scenarios, like\nrandomly generated maps, we will explore another alternatives. One of them is this great, open\nsource, cross platform, generic tile map editor called Tiled.

\n\n

It has some limitations, for instance, all tiles in tileset have to be of same proportions. On the\nupside, it would be easy to load Tiled tilesets with\nGosu::Image#load_tiles.

\n\n

\n $\"Tiled\"$

Tiled

\n\n

Tiled uses it’s own custom, XML based tmx format for saving maps. It also allows exporting maps\nto JSON, which is way more convenient, since parsing XML in Ruby is usually done with\nNokogiri, which is heavier and it’s native extensions usually cause more\ntrouble than ones JSON parser uses. So, let’s see how that JSON looks like:

\n\n

02-warmup/tiled_map.json

\n\n

 1 { \"height\":10,\n 2  \"layers\":[\n 3         {\n 4          \"data\":[65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 0, 0, 65, 6\\\n 5 5, 65, 65, 65, 65, 65, 65, 0, 0, 65, 65, 65, 65, 65, 65, 65, 65, 0, 0, 0, 65, 65\\\n 6 , 65, 65, 65, 65, 65, 0, 0, 0, 0, 65, 65, 65, 65, 65, 65, 0, 0, 0, 0, 65, 65, 65\\\n 7 , 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65\\\n 8 , 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65, 65\\\n 9 ],\n10          \"height\":10,\n11          \"name\":\"Water\",\n12          \"opacity\":1,\n13          \"type\":\"tilelayer\",\n14          \"visible\":true,\n15          \"width\":10,\n16          \"x\":0,\n17          \"y\":0\n18         },\n19         {\n20          \"data\":[0, 0, 7, 5, 57, 43, 0, 0, 0, 0, 0, 0, 28, 1, 1, 42, 0, 0, 0, 0,\\\n21  0, 0, 44, 1, 1, 42, 0, 0, 0, 0, 0, 0, 28, 1, 1, 27, 43, 0, 0, 0, 0, 0, 28, 1, 1\\\n22 , 1, 27, 43, 0, 0, 0, 0, 28, 1, 1, 1, 59, 16, 0, 0, 0, 0, 48, 62, 61, 61, 16, 0,\\\n23  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0\\\n24 , 0, 0, 0, 0, 0],\n25          \"height\":10,\n26          \"name\":\"Ground\",\n27          \"opacity\":1,\n28          \"type\":\"tilelayer\",\n29          \"visible\":true,\n30          \"width\":10,\n31          \"x\":0,\n32          \"y\":0\n33         }],\n34  \"orientation\":\"orthogonal\",\n35  \"properties\":\n36     {\n37 \n38     },\n39  \"tileheight\":128,\n40  \"tilesets\":[\n41         {\n42          \"firstgid\":1,\n43          \"image\":\"media\\/ground.png\",\n44          \"imageheight\":1024,\n45          \"imagewidth\":1024,\n46          \"margin\":0,\n47          \"name\":\"ground\",\n48          \"properties\":\n49             {\n50 \n51             },\n52          \"spacing\":0,\n53          \"tileheight\":128,\n54          \"tilewidth\":128\n55         },\n56         {\n57          \"firstgid\":65,\n58          \"image\":\"media\\/water.png\",\n59          \"imageheight\":128,\n60          \"imagewidth\":128,\n61          \"margin\":0,\n62          \"name\":\"water\",\n63          \"properties\":\n64             {\n65 \n66             },\n67          \"spacing\":0,\n68          \"tileheight\":128,\n69          \"tilewidth\":128\n70         }],\n71  \"tilewidth\":128,\n72  \"version\":1,\n73  \"width\":10\n74 }\n

\n\n

There are following things listed here:

\n\n

Two different tilesets, “ground” and “water”
Map width and height in tile count (10x10)
Layers with data array contains tile numbers

Couple of extra things that Tiled maps can have:

\n\n

Object layers containing lists of objects with their coordinates
Properties hash on tiles and objects

This doesn’t look too difficult to parse, so we’re going to implement a loader for Tiled maps.\nAnd make it open source, of course.

\n\n

Loading Tiled Maps With Gosu

\n\n

Probably the easiest way to load Tiled map is to take each layer and render it on screen, tile by\ntile, like a cake. We will not care about caching at this point, and the only optimization would be\nnot drawing things that are out of screen boundaries.

\n\n

After couple of days of test driven development, I’ve ended up writing\ngosu_tiled gem, that allows you to load Tiled maps with\njust a few lines of code.

\n\n

I will not go through describing the implementation, but if you want to examine the thought\nprocess, take a look at gosu_tiled gem’s\ngit commit history.

\n\n

To use the gem, do gem install gosu_tiled and examine the code that shows a map of the island\nthat you can scroll around with arrow keys:

\n\n

02-warmup/island.rb

\n\n

 1 require 'gosu'\n 2 require 'gosu_tiled'\n 3 \n 4 class GameWindow < Gosu::Window\n 5   MAP_FILE = File.join(File.dirname(\n 6     __FILE__), 'island.json')\n 7   SPEED = 5\n 8 \n 9   def initialize\n10     super(640, 480, false)\n11     @map = Gosu::Tiled.load_json(self, MAP_FILE)\n12     @x = @y = 0\n13     @first_render = true\n14   end\n15 \n16   def button_down(id)\n17     close if id == Gosu::KbEscape\n18   end\n19 \n20   def update\n21     @x -= SPEED if button_down?(Gosu::KbLeft)\n22     @x += SPEED if button_down?(Gosu::KbRight)\n23     @y -= SPEED if button_down?(Gosu::KbUp)\n24     @y += SPEED if button_down?(Gosu::KbDown)\n25     self.caption = \"#{Gosu.fps} FPS. Use arrow keys to pan\"\n26   end\n27 \n28   def draw\n29     @first_render = false\n30     @map.draw(@x, @y)\n31   end\n32 \n33   def needs_redraw?\n34     [Gosu::KbLeft,\n35      Gosu::KbRight,\n36      Gosu::KbUp,\n37      Gosu::KbDown].each do |b|\n38       return true if button_down?(b)\n39     end\n40     @first_render\n41   end\n42 end\n43 \n44 GameWindow.new.show\n

\n\n

Run it, use arrow keys to scroll the map.

\n\n

$ ruby 02-warmup/island.rb\n

\n\n

The result is quite satisfying, and it scrolls smoothly without any optimizations:

\n\n

\n $\"Exploring$

Exploring Tiled map in Gosu

\n\n

Generating Random Map With Perlin Noise

\n\n

In some cases random generated maps make all the difference. Worms and Diablo would probably be\njust average games if it wasn’t for those always unique, procedurally generated maps.

\n\n

We will try to make a very primitive map generator ourselves. To begin with, we will be using only\n3 different tiles - water, sand and grass. For implementing fully tiled edges, the generator must\nbe aware of available tilesets and know how to combine them in valid ways. We may come back to\nit, but for now let’s keep things simple.

\n\n

Now, generating naturally looking randomness is something worth having a book of it’s own, so\ninstead of trying to poorly reinvent what other people have already done, we will use a well known\nalgorithm perfectly suited for this task -\nPerlin noise.

\n\n

If you have ever used Photoshop’s Cloud filter, you already know how Perlin noise looks like:

\n\n

\n $\"Perlin$

Perlin noise

\n\n

Now, we could implement the algorithm ourselves, but there is\nperlin_noise gem already available, it looks pretty\nsolid, so we will use it.

\n\n

The following program generates 100x100 map with 30% chance of water, 15% chance of sand and 55%\nchance of grass:

\n\n

02-warmup/perlin_noise_map.rb

\n\n

  1 require 'gosu'\n  2 require 'gosu_texture_packer'\n  3 require 'perlin_noise'\n  4 \n  5 def media_path(file)\n  6   File.join(File.dirname(File.dirname(\n  7     __FILE__)), 'media', file)\n  8 end\n  9 \n 10 class GameWindow < Gosu::Window\n 11   MAP_WIDTH = 100\n 12   MAP_HEIGHT = 100\n 13   WIDTH = 800\n 14   HEIGHT = 600\n 15   TILE_SIZE = 128\n 16 \n 17   def initialize\n 18     super(WIDTH, HEIGHT, false)\n 19     load_tiles\n 20     @map = generate_map\n 21     @zoom = 0.2\n 22   end\n 23 \n 24   def button_down(id)\n 25     close if id == Gosu::KbEscape\n 26     @map = generate_map if id == Gosu::KbSpace\n 27   end\n 28 \n 29   def update\n 30     adjust_zoom(0.005) if button_down?(Gosu::KbDown)\n 31     adjust_zoom(-0.005) if button_down?(Gosu::KbUp)\n 32     set_caption\n 33   end\n 34 \n 35   def draw\n 36     tiles_x.times do |x|\n 37       tiles_y.times do |y|\n 38         @map[x][y].draw(\n 39           x * TILE_SIZE * @zoom,\n 40           y * TILE_SIZE * @zoom,\n 41           0,\n 42           @zoom,\n 43           @zoom)\n 44       end\n 45     end\n 46   end\n 47 \n 48   private\n 49 \n 50   def set_caption\n 51     self.caption = 'Perlin Noise. ' <<\n 52       \"Zoom: #{'%.2f' % @zoom}. \" <<\n 53       'Use Up/Down to zoom. Space to regenerate.'\n 54   end\n 55 \n 56   def adjust_zoom(delta)\n 57     new_zoom = @zoom + delta\n 58     if new_zoom > 0.07 && new_zoom < 2\n 59       @zoom = new_zoom\n 60     end\n 61   end\n 62 \n 63   def load_tiles\n 64     tiles = Gosu::Image.load_tiles(\n 65       self, media_path('ground.png'), 128, 128, true)\n 66     @sand = tiles[0]\n 67     @grass = tiles[8]\n 68     @water = Gosu::Image.new(\n 69       self, media_path('water.png'), true)\n 70   end\n 71 \n 72   def tiles_x\n 73     count = (WIDTH / (TILE_SIZE * @zoom)).ceil + 1\n 74     [count, MAP_WIDTH].min\n 75   end\n 76 \n 77   def tiles_y\n 78     count = (HEIGHT / (TILE_SIZE * @zoom)).ceil + 1\n 79     [count, MAP_HEIGHT].min\n 80   end\n 81 \n 82   def generate_map\n 83     noises = Perlin::Noise.new(2)\n 84     contrast = Perlin::Curve.contrast(\n 85       Perlin::Curve::CUBIC, 2)\n 86     map = {}\n 87     MAP_WIDTH.times do |x|\n 88       map[x] = {}\n 89       MAP_HEIGHT.times do |y|\n 90         n = noises[x * 0.1, y * 0.1]\n 91         n = contrast.call(n)\n 92         map[x][y] = choose_tile(n)\n 93       end\n 94     end\n 95     map\n 96   end\n 97 \n 98   def choose_tile(val)\n 99     case val\n100     when 0.0..0.3 # 30% chance\n101       @water\n102     when 0.3..0.45 # 15% chance, water edges\n103       @sand\n104     else # 55% chance\n105       @grass\n106     end\n107   end\n108 \n109 end\n110 \n111 window = GameWindow.new\n112 window.show\n

\n\n

Run the program, zoom with up / down arrows and regenerate everything with spacebar.

\n\n

$ ruby 02-warmup/perlin_noise_map.rb\n

\n\n

\n $\"Map$

Map generated with Perlin noise

\n\n

This is a little longer than our previous examples, so we will analyze some parts to make it clear.

\n\n

81 def generate_map\n82   noises = Perlin::Noise.new(2)\n83   contrast = Perlin::Curve.contrast(\n84     Perlin::Curve::CUBIC, 2)\n85   map = {}\n86   MAP_WIDTH.times do |x|\n87     map[x] = {}\n88     MAP_HEIGHT.times do |y|\n89       n = noises[x * 0.1, y * 0.1]\n90       n = contrast.call(n)\n91       map[x][y] = choose_tile(n)\n92     end\n93   end\n94   map\n95 end\n

\n\n

generate_map is the heart of this program. It creates two dimensional Perlin::Noise generator,\nthen chooses a random tile for each location of the map, according to noise value. To make the map\na little sharper, cubic contrast is applied to noise value before choosing the tile. Try commenting\nout contrast application - it will look like a boring golf course, since noise values will keep\nbuzzing around the middle.

\n\n

 97 def choose_tile(val)\n 98   case val\n 99   when 0.0..0.3 # 30% chance\n100     @water\n101   when 0.3..0.45 # 15% chance, water edges\n102     @sand\n103   else # 55% chance\n104     @grass\n105   end\n106 end\n

\n\n

Here we could go crazy if we had more different tiles to use. We could add deep waters at\n0.0..0.1, mountains at 0.9..0.95 and snow caps at 0.95..1.0. And all this would have\nbeautiful transitions.

\n\n

Player Movement With Keyboard And Mouse

\n\n

We have learned to draw maps, but we need a protagonist to explore them. It will be a tank that you\ncan move around the island with WASD keys and use your mouse to target it’s gun at things. The tank\nwill be drawn on top of our island map, and it will be above ground, but below tree layer, so it\ncan sneak behind palm trees. That’s as close to real deal as it gets!

\n\n

02-warmup/player_movement.rb

\n\n

  1 require 'gosu'\n  2 require 'gosu_tiled'\n  3 require 'gosu_texture_packer'\n  4 \n  5 class Tank\n  6   attr_accessor :x, :y, :body_angle, :gun_angle\n  7 \n  8   def initialize(window, body, shadow, gun)\n  9     @x = window.width / 2\n 10     @y = window.height / 2\n 11     @window = window\n 12     @body = body\n 13     @shadow = shadow\n 14     @gun = gun\n 15     @body_angle = 0.0\n 16     @gun_angle = 0.0\n 17   end\n 18 \n 19   def update\n 20     atan = Math.atan2(320 - @window.mouse_x,\n 21                       240 - @window.mouse_y)\n 22     @gun_angle = -atan * 180 / Math::PI\n 23     @body_angle = change_angle(@body_angle,\n 24       Gosu::KbW, Gosu::KbS, Gosu::KbA, Gosu::KbD)\n 25   end\n 26 \n 27   def draw\n 28     @shadow.draw_rot(@x - 1, @y - 1, 0, @body_angle)\n 29     @body.draw_rot(@x, @y, 1, @body_angle)\n 30     @gun.draw_rot(@x, @y, 2, @gun_angle)\n 31   end\n 32 \n 33   private\n 34 \n 35   def change_angle(previous_angle, up, down, right, left)\n 36     if @window.button_down?(up)\n 37       angle = 0.0\n 38       angle += 45.0 if @window.button_down?(left)\n 39       angle -= 45.0 if @window.button_down?(right)\n 40     elsif @window.button_down?(down)\n 41       angle = 180.0\n 42       angle -= 45.0 if @window.button_down?(left)\n 43       angle += 45.0 if @window.button_down?(right)\n 44     elsif @window.button_down?(left)\n 45       angle = 90.0\n 46       angle += 45.0 if @window.button_down?(up)\n 47       angle -= 45.0 if @window.button_down?(down)\n 48     elsif @window.button_down?(right)\n 49       angle = 270.0\n 50       angle -= 45.0 if @window.button_down?(up)\n 51       angle += 45.0 if @window.button_down?(down)\n 52     end\n 53     angle || previous_angle\n 54   end\n 55 end\n 56 \n 57 class GameWindow < Gosu::Window\n 58   MAP_FILE = File.join(File.dirname(\n 59     __FILE__), 'island.json')\n 60   UNIT_FILE = File.join(File.dirname(File.dirname(\n 61     __FILE__)), 'media', 'ground_units.json')\n 62   SPEED = 5\n 63 \n 64   def initialize\n 65     super(640, 480, false)\n 66     @map = Gosu::Tiled.load_json(self, MAP_FILE)\n 67     @units = Gosu::TexturePacker.load_json(\n 68       self, UNIT_FILE, :precise)\n 69     @tank = Tank.new(self,\n 70       @units.frame('tank1_body.png'),\n 71       @units.frame('tank1_body_shadow.png'),\n 72       @units.frame('tank1_dualgun.png'))\n 73     @x = @y = 0\n 74     @first_render = true\n 75     @buttons_down = 0\n 76   end\n 77 \n 78   def needs_cursor?\n 79     true\n 80   end\n 81 \n 82   def button_down(id)\n 83     close if id == Gosu::KbEscape\n 84     @buttons_down += 1\n 85   end\n 86 \n 87   def button_up(id)\n 88     @buttons_down -= 1\n 89   end\n 90 \n 91   def update\n 92     @x -= SPEED if button_down?(Gosu::KbA)\n 93     @x += SPEED if button_down?(Gosu::KbD)\n 94     @y -= SPEED if button_down?(Gosu::KbW)\n 95     @y += SPEED if button_down?(Gosu::KbS)\n 96     @tank.update\n 97     self.caption = \"#{Gosu.fps} FPS. \" <<\n 98       'Use WASD and mouse to control tank'\n 99   end\n100 \n101   def draw\n102     @first_render = false\n103     @map.draw(@x, @y)\n104     @tank.draw()\n105   end\n106 end\n107 \n108 GameWindow.new.show\n

\n\n

Tank sprite is rendered in the middle of screen. It consists of three layers, body shadow, body and\ngun. Body and it’s shadow are always rendered in same angle, one on top of another. The angle is\ndetermined by keys that are pressed. It supports 8 directions.

\n\n

Gun is a little bit different. It follows mouse cursor. To determine the angle we had to use some\nmath. The formula to get angle in degrees is arctan(delta_x / delta_y) * 180 / PI. You can see it\nexplained in more detail on stackoverflow.

\n\n

Run it and stroll around the island. You can still move on water and into the darkness, away from\nthe map itself, but we will handle it later.

\n\n

$ ruby 02-warmup/player_movement.rb\n

\n\n

See that tank hiding between the bushes, ready to go in 8 directions and blow shit up with that\nprecisely aimed double cannon?

\n\n

\n $\"Tank$

Tank moving around and aiming guns

\n\n

Game Coordinate System

\n\n

By now we may start realizing, that there is one key component missing in our designs. We have a\nvirtual map, which is bigger than our screen space, and we should perform all calculations using\nthat map, and only then cut out the required piece and render it in our game window.

\n\n

There are three different coordinate systems that have to map with each other:

\n\n

Game coordinates
Viewport coordinates
Screen coordinates

\n $\"Coordinate$

Coordinate systems

\n\n

Game Coordinates

\n\n

This is where all logic will happen. Player location, enemy locations, powerup locations - all this\nwill have game coordinates, and it should have nothing to do with your screen position.

\n\n

Viewport Coordinates

\n\n

Viewport is the position of virtual camera, that is “filming” world in action. Don’t confuse it\nwith screen coordinates, because viewport will not necessarily be mapped pixel to pixel to your game\nwindow. Imagine this: you have a huge world map, your player is standing in the middle, and game\nwindow displays the player while slowly zooming in. In this scenario, viewport is constantly\nshrinking, while game map stays the same, and game window also stays the same.

\n\n

Screen Coordinates

\n\n

This is your game display, pixel by pixel. You will draw static information, like your\nHUD directly on it.

\n\n

How To Put It All Together

\n\n

In our games we will want to separate game coordinates from viewport and screen as much as\npossible. Basically, we will program ourselves a “camera man” who will be busy following the\naction, zooming in and out, perhaps changing the view angle now and then.

\n\n

Let’s implement a prototype that will allow us to navigate and zoom around a big map. We will only\ndraw objects that are visible in viewport. Some math will be unavoidable, but in most cases it’s pretty\nbasic - that’s the beauty of 2D games:

\n\n

02-warmup/coordinate_system.rb

\n\n

  1 require 'gosu'\n  2 \n  3 class WorldMap\n  4   attr_accessor :on_screen, :off_screen\n  5 \n  6   def initialize(width, height)\n  7     @images = {}\n  8     (0..width).step(50) do |x|\n  9       @images[x] = {}\n 10       (0..height).step(50) do |y|\n 11         img = Gosu::Image.from_text(\n 12           $window, \"#{x}:#{y}\",\n 13           Gosu.default_font_name, 15)\n 14         @images[x][y] = img\n 15       end\n 16     end\n 17   end\n 18 \n 19   def draw(camera)\n 20     @on_screen = @off_screen = 0\n 21     @images.each do |x, row|\n 22       row.each do |y, val|\n 23         if camera.can_view?(x, y, val)\n 24           val.draw(x, y, 0)\n 25           @on_screen += 1\n 26         else\n 27           @off_screen += 1\n 28         end\n 29       end\n 30     end\n 31   end\n 32 end\n 33 \n 34 class Camera\n 35   attr_accessor :x, :y, :zoom\n 36 \n 37   def initialize\n 38     @x = @y = 0\n 39     @zoom = 1\n 40   end\n 41 \n 42   def can_view?(x, y, obj)\n 43     x0, x1, y0, y1 = viewport\n 44     (x0 - obj.width..x1).include?(x) &&\n 45       (y0 - obj.height..y1).include?(y)\n 46   end\n 47 \n 48   def viewport\n 49     x0 = @x - ($window.width / 2)  / @zoom\n 50     x1 = @x + ($window.width / 2)  / @zoom\n 51     y0 = @y - ($window.height / 2) / @zoom\n 52     y1 = @y + ($window.height / 2) / @zoom\n 53     [x0, x1, y0, y1]\n 54   end\n 55 \n 56   def to_s\n 57     \"FPS: #{Gosu.fps}. \" <<\n 58       \"#{@x}:#{@y} @ #{'%.2f' % @zoom}. \" <<\n 59       'WASD to move, arrows to zoom.'\n 60   end\n 61 \n 62   def draw_crosshair\n 63     $window.draw_line(\n 64       @x - 10, @y, Gosu::Color::YELLOW,\n 65       @x + 10, @y, Gosu::Color::YELLOW, 100)\n 66     $window.draw_line(\n 67       @x, @y - 10, Gosu::Color::YELLOW,\n 68       @x, @y + 10, Gosu::Color::YELLOW, 100)\n 69   end\n 70 end\n 71 \n 72 \n 73 class GameWindow < Gosu::Window\n 74   SPEED = 10\n 75 \n 76   def initialize\n 77     super(800, 600, false)\n 78     $window = self\n 79     @map = WorldMap.new(2048, 1024)\n 80     @camera = Camera.new\n 81   end\n 82 \n 83   def button_down(id)\n 84     close if id == Gosu::KbEscape\n 85     if id == Gosu::KbSpace\n 86       @camera.zoom = 1.0\n 87       @camera.x = 0\n 88       @camera.y = 0\n 89     end\n 90   end\n 91 \n 92   def update\n 93     @camera.x -= SPEED if button_down?(Gosu::KbA)\n 94     @camera.x += SPEED if button_down?(Gosu::KbD)\n 95     @camera.y -= SPEED if button_down?(Gosu::KbW)\n 96     @camera.y += SPEED if button_down?(Gosu::KbS)\n 97 \n 98     zoom_delta = @camera.zoom > 0 ? 0.01 : 1.0\n 99 \n100     if button_down?(Gosu::KbUp)\n101       @camera.zoom -= zoom_delta\n102     end\n103     if button_down?(Gosu::KbDown)\n104       @camera.zoom += zoom_delta\n105     end\n106     self.caption = @camera.to_s\n107   end\n108 \n109   def draw\n110     off_x = -@camera.x + width / 2\n111     off_y = -@camera.y + height / 2\n112     cam_x = @camera.x\n113     cam_y = @camera.y\n114     translate(off_x, off_y) do\n115       @camera.draw_crosshair\n116       zoom = @camera.zoom\n117       scale(zoom, zoom, cam_x, cam_y) do\n118         @map.draw(@camera)\n119       end\n120     end\n121     info = 'Objects on/off screen: ' <<\n122       \"#{@map.on_screen}/#{@map.off_screen}\"\n123     info_img = Gosu::Image.from_text(\n124       self, info, Gosu.default_font_name, 30)\n125     info_img.draw(10, 10, 1)\n126   end\n127 end\n128 \n129 GameWindow.new.show\n

\n\n

Run it, use WASD to navigate, up / down arrows to zoom and spacebar to reset the camera.

\n\n

$ ruby 02-warmup/coordinate_system.rb\n

\n\n

It doesn’t look impressive, but understanding the concept of different coordinate systems and being\nable to stitch them together is paramount to the success of our final product.

\n\n

\n $\"Prototype$

Prototype of separate coordinate systems

\n\n

Luckily for us, Gosu helps us by providing\nGosu::Window#translate\nthat handles camera offset,\nGosu::Window#scale that\naids zooming, and\nGosu::Window#rotate that\nwas not used yet, but will be great for shaking the view to emphasize explosions.

\n\n

Prototyping The Game

\n\n

Warming up was really important, but let’s combine everything we learned, add some new challenges,\nand build a small prototype with following features:

\n\n

Camera loosely follows tank.
Camera zooms automatically depending on tank speed.
You can temporarily override automatic camera zoom using keyboard.
Music and sound effects.
Randomly generated map.
Two modes: menu and gameplay.
Tank movement with WADS keys.
Tank aiming and shooting with mouse.
Collision detection (tanks don’t swim).
Explosions, visible bullet trajectories.
Bullet range limiting.

Sounds fun? Hell yes! However, before we start, we should plan ahead a little and think how our\ngame architecture will look like. We will also structure our code a little, so it will not be\nsmashed into one ruby class, as we did in earlier examples. Books should show good manners!

\n\n

Switching Between Game States

\n\n

First, let’s think how to hook into\nGosu::Window. Since we will have two game\nstates, State pattern naturally comes to mind.

\n\n

So, our GameWindow class could look like this:

\n\n

03-prototype/game_window.rb

\n\n

 1 class GameWindow < Gosu::Window\n 2 \n 3   attr_accessor :state\n 4 \n 5   def initialize\n 6     super(800, 600, false)\n 7   end\n 8 \n 9   def update\n10     @state.update\n11   end\n12 \n13   def draw\n14     @state.draw\n15   end\n16 \n17   def needs_redraw?\n18     @state.needs_redraw?\n19   end\n20 \n21   def button_down(id)\n22     @state.button_down(id)\n23   end\n24 \n25 end\n

\n\n

It has current @state, and all usual main loop actions are executed on that state instance.\nWe will add base class that all game states will extend. Let’s name it GameState:

\n\n

03-prototype/states/game_state.rb

\n\n

 1 class GameState\n 2 \n 3   def self.switch(new_state)\n 4     $window.state && $window.state.leave\n 5     $window.state = new_state\n 6     new_state.enter\n 7   end\n 8 \n 9   def enter\n10   end\n11 \n12   def leave\n13   end\n14 \n15   def draw\n16   end\n17 \n18   def update\n19   end\n20 \n21   def needs_redraw?\n22     true\n23   end\n24 \n25   def button_down(id)\n26   end\n27 end\n

\n\n

This class provides GameState.switch, that will change the state for our Gosu::Window, and all\nenter and leave methods when appropriate. These methods will be useful for things like\nswitching music.

\n\n

Notice that Gosu::Window is accessed using global $window variable, which will be considered an\nanti-pattern by most good programmers, but there is some logic behind this:

\n\n

There will be only one Gosu::Window instance.
It lives as long as the game runs.
It is used in some way by nearly all other classes, so we would have to pass it around all the\ntime.
Accessing it using Singleton or static utility class would not give any clear benefits, just add more complexity.

Chingu, another game framework built on top of Gosu, also uses\nglobal $window, so it’s probably not the worst idea ever.

\n\n

We will also need an entry point that would fire up the game and enter the first game state - the\nmenu.

\n\n

03-prototype/main.rb

\n\n

 1 require 'gosu'\n 2 require_relative 'states/game_state'\n 3 require_relative 'states/menu_state'\n 4 require_relative 'states/play_state'\n 5 require_relative 'game_window'\n 6 \n 7 module Game\n 8   def self.media_path(file)\n 9     File.join(File.dirname(File.dirname(\n10       __FILE__)), 'media', file)\n11   end\n12 end\n13 \n14 $window = GameWindow.new\n15 GameState.switch(MenuState.instance)\n16 $window.show\n

\n\n

In our entry point we also have a small helper which will help loading images and sounds using\nGame.media_path.

\n\n

The rest is obvious: we create GameWindow instance and store it in $window variable, as\ndiscussed before. Then we use GameState.switch) to load MenuState, and show the game window.

\n\n\n\n

This is how simple MenuState implementation looks like:

\n\n

03-prototype/states/menu_state.rb

\n\n

 1 require 'singleton'\n 2 class MenuState < GameState\n 3   include Singleton\n 4   attr_accessor :play_state\n 5 \n 6   def initialize\n 7     @message = Gosu::Image.from_text(\n 8       $window, \"Tanks Prototype\",\n 9       Gosu.default_font_name, 100)\n10   end\n11 \n12   def enter\n13     music.play(true)\n14     music.volume = 1\n15   end\n16 \n17   def leave\n18     music.volume = 0\n19     music.stop\n20   end\n21 \n22   def music\n23     @@music ||= Gosu::Song.new(\n24       $window, Game.media_path('menu_music.mp3'))\n25   end\n26 \n27   def update\n28     continue_text = @play_state ? \"C = Continue, \" : \"\"\n29     @info = Gosu::Image.from_text(\n30       $window, \"Q = Quit, #{continue_text}N = New Game\",\n31       Gosu.default_font_name, 30)\n32   end\n33 \n34   def draw\n35     @message.draw(\n36       $window.width / 2 - @message.width / 2,\n37       $window.height / 2 - @message.height / 2,\n38       10)\n39     @info.draw(\n40       $window.width / 2 - @info.width / 2,\n41       $window.height / 2 - @info.height / 2 + 200,\n42       10)\n43   end\n44 \n45   def button_down(id)\n46     $window.close if id == Gosu::KbQ\n47     if id == Gosu::KbC && @play_state\n48       GameState.switch(@play_state)\n49     end\n50     if id == Gosu::KbN\n51       @play_state = PlayState.new\n52       GameState.switch(@play_state)\n53     end\n54   end\n55 end\n

\n\n

It’s a Singleton, so\nwe can always get it with MenuState.instance.

\n\n

It starts playing menu_music.mp3 when you enter the menu, and stop the music when you leave it.\nInstance of Gosu::Song is cached in @@music class\nvariable to save resources.

\n\n

We have to know if play is already in progress, so we can add a possibility to go back to the\ngame. That’s why MenuState has @play_state variable, and either allows creating new PlayState\nwhen N key is pressed, or switches to existing @play_state if C key is pressed.

\n\n

Here comes the interesting part, implementing the play state.

\n\n

Implementing Play State

\n\n

Before we start implementing actual gameplay, we need to think what game entities we will be\nbuilding. We will need a Map that will hold our tiles and provide world coordinate system. We\nwill also need a Camera that will know how to float around and zoom. There will be Bullets\nflying around, and each bullet will eventually cause an Explosion.

\n\n

Having all that taken care of, PlayState should look pretty simple:

\n\n

03-prototype/states/play_state.rb

\n\n

 1 require_relative '../entities/map'\n 2 require_relative '../entities/tank'\n 3 require_relative '../entities/camera'\n 4 require_relative '../entities/bullet'\n 5 require_relative '../entities/explosion'\n 6 class PlayState < GameState\n 7 \n 8   def initialize\n 9     @map = Map.new\n10     @tank = Tank.new(@map)\n11     @camera = Camera.new(@tank)\n12     @bullets = []\n13     @explosions = []\n14   end\n15 \n16   def update\n17     bullet = @tank.update(@camera)\n18     @bullets << bullet if bullet\n19     @bullets.map(&:update)\n20     @bullets.reject!(&:done?)\n21     @camera.update\n22     $window.caption = 'Tanks Prototype. ' <<\n23       \"[FPS: #{Gosu.fps}. Tank @ #{@tank.x.round}:#{@tank.y.round}]\"\n24   end\n25 \n26   def draw\n27     cam_x = @camera.x\n28     cam_y = @camera.y\n29     off_x =  $window.width / 2 - cam_x\n30     off_y =  $window.height / 2 - cam_y\n31     $window.translate(off_x, off_y) do\n32       zoom = @camera.zoom\n33       $window.scale(zoom, zoom, cam_x, cam_y) do\n34         @map.draw(@camera)\n35         @tank.draw\n36         @bullets.map(&:draw)\n37       end\n38     end\n39     @camera.draw_crosshair\n40   end\n41 \n42   def button_down(id)\n43     if id == Gosu::MsLeft\n44       bullet = @tank.shoot(*@camera.mouse_coords)\n45       @bullets << bullet if bullet\n46     end\n47     $window.close if id == Gosu::KbQ\n48     if id == Gosu::KbEscape\n49       GameState.switch(MenuState.instance)\n50     end\n51   end\n52 \n53 end\n

\n\n

Update and draw calls are passed to the underlying game entities, so they can handle them the way\nthey want it to. Such encapsulation reduces complexity of the code and allows doing every piece of\nlogic where it belongs, while keeping it short and simple.

\n\n

There are a few interesting parts in this code. Both @tank.update and @tank.shoot may produce a\nnew bullet, if your tank’s fire rate is not exceeded, and if left mouse button is kept down, hence\nthe update. If bullet is produced, it is added to @bullets array, and they live their own\nlittle lifecycle, until they explode and are no longer used. @bullets.reject!(&:done?) cleans up\nthe garbage.

\n\n

PlayState#draw deserves extra explanation. @camera.x and @camera.y points to game\ncoordinates where Camera is currently looking at.\nGosu::Window#translate\ncreates a block within which all Gosu::Image draw\noperations are translated by given offset.\nGosu::Window#scale does the\nsame with Camera zoom.

\n\n

Crosshair is drawn without translating and scaling it, because it’s relative to screen, not to\nworld map.

\n\n

Basically, this draw method is the place that takes care drawing only what @camera can see.

\n\n

If it’s hard to understand how this works, get back to “Game Coordinate System” chapter and let it\nsink in.

\n\n

Implementing World Map

\n\n

We will start analyzing game entities with Map.

\n\n

03-prototype/entities/map.rb

\n\n

 1 require 'perlin_noise'\n 2 require 'gosu_texture_packer'\n 3 \n 4 class Map\n 5   MAP_WIDTH = 100\n 6   MAP_HEIGHT = 100\n 7   TILE_SIZE = 128\n 8 \n 9   def initialize\n10     load_tiles\n11     @map = generate_map\n12   end\n13 \n14   def find_spawn_point\n15     while true\n16       x = rand(0..MAP_WIDTH * TILE_SIZE)\n17       y = rand(0..MAP_HEIGHT * TILE_SIZE)\n18       if can_move_to?(x, y)\n19         return [x, y]\n20       else\n21         puts \"Invalid spawn point: #{[x, y]}\"\n22       end\n23     end\n24   end\n25 \n26   def can_move_to?(x, y)\n27     tile = tile_at(x, y)\n28     tile && tile != @water\n29   end\n30 \n31   def draw(camera)\n32     @map.each do |x, row|\n33       row.each do |y, val|\n34         tile = @map[x][y]\n35         map_x = x * TILE_SIZE\n36         map_y = y * TILE_SIZE\n37         if camera.can_view?(map_x, map_y, tile)\n38           tile.draw(map_x, map_y, 0)\n39         end\n40       end\n41     end\n42   end\n43 \n44   private\n45 \n46   def tile_at(x, y)\n47     t_x = ((x / TILE_SIZE) % TILE_SIZE).floor\n48     t_y = ((y / TILE_SIZE) % TILE_SIZE).floor\n49     row = @map[t_x]\n50     row[t_y] if row\n51   end\n52 \n53   def load_tiles\n54     tiles = Gosu::Image.load_tiles(\n55       $window, Game.media_path('ground.png'),\n56       128, 128, true)\n57     @sand = tiles[0]\n58     @grass = tiles[8]\n59     @water = Gosu::Image.new(\n60       $window, Game.media_path('water.png'), true)\n61   end\n62 \n63   def generate_map\n64     noises = Perlin::Noise.new(2)\n65     contrast = Perlin::Curve.contrast(\n66       Perlin::Curve::CUBIC, 2)\n67     map = {}\n68     MAP_WIDTH.times do |x|\n69       map[x] = {}\n70       MAP_HEIGHT.times do |y|\n71         n = noises[x * 0.1, y * 0.1]\n72         n = contrast.call(n)\n73         map[x][y] = choose_tile(n)\n74       end\n75     end\n76     map\n77   end\n78 \n79   def choose_tile(val)\n80     case val\n81     when 0.0..0.3 # 30% chance\n82       @water\n83     when 0.3..0.45 # 15% chance, water edges\n84       @sand\n85     else # 55% chance\n86       @grass\n87     end\n88   end\n89 end\n

\n\n

This implementation is very similar to the Map we had built in “Generating Random Map With\nPerlin Noise”, with some extra additions. can_move_to? verifies if tile under given coordinates\nis not water. Pretty simple, but it’s enough for our prototype.

\n\n

Also, when we draw the map we have to make sure if tiles we are drawing are currently visible by\nour camera, otherwise we will end up drawing off screen. camera.can_view? handles it. Current\nimplementation will probably be causing a bottleneck, since it brute forces through all the map\nrather than cherry-picking the visible region. We will probably have to get back and change it\nlater.

\n\n

find_spawn_point is one more addition. It keeps picking a random point on map and verifies if\nit’s not water using can_move_to?. When solid tile is found, it returns the coordinates, so our\nTank will be able to spawn there.

\n\n

Implementing Floating Camera

\n\n

If you played the original Grand Theft\nAuto or GTA 2, you should remember how fascinating the\ncamera was. It backed away when you were driving at high speeds, closed in when you were walking on\nfoot, and floated around as if a smart drone was following your protagonist from above.

\n\n

The following Camera implementation is far inferior to the one GTA had nearly two decades ago,\nbut it’s a start:

\n\n

03-prototype/entities/camera.rb

\n\n

 1 class Camera\n 2   attr_accessor :x, :y, :zoom\n 3 \n 4   def initialize(target)\n 5     @target = target\n 6     @x, @y = target.x, target.y\n 7     @zoom = 1\n 8   end\n 9 \n10   def can_view?(x, y, obj)\n11     x0, x1, y0, y1 = viewport\n12     (x0 - obj.width..x1).include?(x) &&\n13       (y0 - obj.height..y1).include?(y)\n14   end\n15 \n16   def mouse_coords\n17     x, y = target_delta_on_screen\n18     mouse_x_on_map = @target.x +\n19       (x + $window.mouse_x - ($window.width / 2)) / @zoom\n20     mouse_y_on_map = @target.y +\n21       (y + $window.mouse_y - ($window.height / 2)) / @zoom\n22     [mouse_x_on_map, mouse_y_on_map].map(&:round)\n23   end\n24 \n25   def update\n26     @x += @target.speed if @x < @target.x - $window.width / 4\n27     @x -= @target.speed if @x > @target.x + $window.width / 4\n28     @y += @target.speed if @y < @target.y - $window.height / 4\n29     @y -= @target.speed if @y > @target.y + $window.height / 4\n30 \n31     zoom_delta = @zoom > 0 ? 0.01 : 1.0\n32     if $window.button_down?(Gosu::KbUp)\n33       @zoom -= zoom_delta unless @zoom < 0.7\n34     elsif $window.button_down?(Gosu::KbDown)\n35       @zoom += zoom_delta unless @zoom > 10\n36     else\n37       target_zoom = @target.speed > 1.1 ? 0.85 : 1.0\n38       if @zoom <= (target_zoom - 0.01)\n39         @zoom += zoom_delta / 3\n40       elsif @zoom > (target_zoom + 0.01)\n41         @zoom -= zoom_delta / 3\n42       end\n43     end\n44   end\n45 \n46   def to_s\n47     \"FPS: #{Gosu.fps}. \" <<\n48       \"#{@x}:#{@y} @ #{'%.2f' % @zoom}. \" <<\n49       'WASD to move, arrows to zoom.'\n50   end\n51 \n52   def target_delta_on_screen\n53     [(@x - @target.x) * @zoom, (@y - @target.y) * @zoom]\n54   end\n55 \n56   def draw_crosshair\n57     x = $window.mouse_x\n58     y = $window.mouse_y\n59     $window.draw_line(\n60       x - 10, y, Gosu::Color::RED,\n61       x + 10, y, Gosu::Color::RED, 100)\n62     $window.draw_line(\n63       x, y - 10, Gosu::Color::RED,\n64       x, y + 10, Gosu::Color::RED, 100)\n65   end\n66 \n67   private\n68 \n69   def viewport\n70     x0 = @x - ($window.width / 2)  / @zoom\n71     x1 = @x + ($window.width / 2)  / @zoom\n72     y0 = @y - ($window.height / 2) / @zoom\n73     y1 = @y + ($window.height / 2) / @zoom\n74     [x0, x1, y0, y1]\n75   end\n76 end\n

\n\n

Our Camera has @target that it tries to follow, @x and @y that it\ncurrently is looking at, and @zoom level.

\n\n

All the magic happens in update method. It keeps track of the distance between @target and\nadjust itself to stay nearby. And when @target.speed shows some movement momentum, camera slowly\nbacks away.

\n\n

Camera also tels if you can_view? an object at some\ncoordinates, so when other entities draw themselves, they can check if there is a need for that.

\n\n

Another noteworthy method is mouse_coords. It translates mouse position on screen to mouse\nposition on map, so the game will know where you are targeting your guns.

\n\n

Implementing The Tank

\n\n

Most of our tank code will be taken from “Player Movement With Keyboard And Mouse”:

\n\n

03-prototype/entities/camera.rb

\n\n

 1 class Camera\n 2   attr_accessor :x, :y, :zoom\n 3 \n 4   def initialize(target)\n 5     @target = target\n 6     @x, @y = target.x, target.y\n 7     @zoom = 1\n 8   end\n 9 \n10   def can_view?(x, y, obj)\n11     x0, x1, y0, y1 = viewport\n12     (x0 - obj.width..x1).include?(x) &&\n13       (y0 - obj.height..y1).include?(y)\n14   end\n15 \n16   def mouse_coords\n17     x, y = target_delta_on_screen\n18     mouse_x_on_map = @target.x +\n19       (x + $window.mouse_x - ($window.width / 2)) / @zoom\n20     mouse_y_on_map = @target.y +\n21       (y + $window.mouse_y - ($window.height / 2)) / @zoom\n22     [mouse_x_on_map, mouse_y_on_map].map(&:round)\n23   end\n24 \n25   def update\n26     @x += @target.speed if @x < @target.x - $window.width / 4\n27     @x -= @target.speed if @x > @target.x + $window.width / 4\n28     @y += @target.speed if @y < @target.y - $window.height / 4\n29     @y -= @target.speed if @y > @target.y + $window.height / 4\n30 \n31     zoom_delta = @zoom > 0 ? 0.01 : 1.0\n32     if $window.button_down?(Gosu::KbUp)\n33       @zoom -= zoom_delta unless @zoom < 0.7\n34     elsif $window.button_down?(Gosu::KbDown)\n35       @zoom += zoom_delta unless @zoom > 10\n36     else\n37       target_zoom = @target.speed > 1.1 ? 0.85 : 1.0\n38       if @zoom <= (target_zoom - 0.01)\n39         @zoom += zoom_delta / 3\n40       elsif @zoom > (target_zoom + 0.01)\n41         @zoom -= zoom_delta / 3\n42       end\n43     end\n44   end\n45 \n46   def to_s\n47     \"FPS: #{Gosu.fps}. \" <<\n48       \"#{@x}:#{@y} @ #{'%.2f' % @zoom}. \" <<\n49       'WASD to move, arrows to zoom.'\n50   end\n51 \n52   def target_delta_on_screen\n53     [(@x - @target.x) * @zoom, (@y - @target.y) * @zoom]\n54   end\n55 \n56   def draw_crosshair\n57     x = $window.mouse_x\n58     y = $window.mouse_y\n59     $window.draw_line(\n60       x - 10, y, Gosu::Color::RED,\n61       x + 10, y, Gosu::Color::RED, 100)\n62     $window.draw_line(\n63       x, y - 10, Gosu::Color::RED,\n64       x, y + 10, Gosu::Color::RED, 100)\n65   end\n66 \n67   private\n68 \n69   def viewport\n70     x0 = @x - ($window.width / 2)  / @zoom\n71     x1 = @x + ($window.width / 2)  / @zoom\n72     y0 = @y - ($window.height / 2) / @zoom\n73     y1 = @y + ($window.height / 2) / @zoom\n74     [x0, x1, y0, y1]\n75   end\n76 end\n

\n\n

Tank has to be aware of the Map to check where it’s moving, and it uses Camera to find out\nwhere to aim the guns. When it shoots, it produces instances of Bullet, that are simply\nreturned to the caller. Tank won’t keep track of them, it’s “fire and forget”.

\n\n

Implementing Bullets And Explosions

\n\n

Bullets will require some simple vector math. You have a point that moves along the vector with\nsome speed. It also needs to limit the maximum vector length, so if you try to aim too far, the\nbullet will only go as far as it can reach.

\n\n

03-prototype/entities/bullet.rb

\n\n

 1 class Bullet\n 2   COLOR = Gosu::Color::BLACK\n 3   MAX_DIST = 300\n 4   START_DIST = 20\n 5 \n 6   def initialize(source_x, source_y, target_x, target_y)\n 7     @x, @y = source_x, source_y\n 8     @target_x, @target_y = target_x, target_y\n 9     @x, @y = point_at_distance(START_DIST)\n10     if trajectory_length > MAX_DIST\n11       @target_x, @target_y = point_at_distance(MAX_DIST)\n12     end\n13     sound.play\n14   end\n15 \n16   def draw\n17     unless arrived?\n18       $window.draw_quad(@x - 2, @y - 2, COLOR,\n19                         @x + 2, @y - 2, COLOR,\n20                         @x - 2, @y + 2, COLOR,\n21                         @x + 2, @y + 2, COLOR,\n22                         1)\n23     else\n24       @explosion ||= Explosion.new(@x, @y)\n25       @explosion.draw\n26     end\n27   end\n28 \n29   def update\n30     fly_distance = (Gosu.milliseconds - @fired_at) * 0.001 * @speed\n31     @x, @y = point_at_distance(fly_distance)\n32     @explosion && @explosion.update\n33   end\n34 \n35   def arrived?\n36     @x == @target_x && @y == @target_y\n37   end\n38 \n39   def done?\n40      exploaded?\n41   end\n42 \n43   def exploaded?\n44     @explosion && @explosion.done?\n45   end\n46 \n47   def fire(speed)\n48     @speed = speed\n49     @fired_at = Gosu.milliseconds\n50     self\n51   end\n52 \n53   private\n54 \n55   def sound\n56     @@sound ||= Gosu::Sample.new(\n57       $window, Game.media_path('fire.mp3'))\n58   end\n59 \n60   def trajectory_length\n61     d_x = @target_x - @x\n62     d_y = @target_y - @y\n63     Math.sqrt(d_x * d_x + d_y * d_y)\n64   end\n65 \n66   def point_at_distance(distance)\n67     return [@target_x, @target_y] if distance > trajectory_length\n68     distance_factor = distance.to_f / trajectory_length\n69     p_x = @x + (@target_x - @x) * distance_factor\n70     p_y = @y + (@target_y - @y) * distance_factor\n71     [p_x, p_y]\n72   end\n73 end\n

\n\n

Possibly the most interesting part of Bullet implementation is point_at_distance method. It\nreturns coordinates of point that is between bullet source, which is point that bullet was fired\nfrom, and it’s target, which is the destination point. The returned point is as far away from\nsource point as distance tells it to.

\n\n

After bullet has done flying, it explodes with fanfare. In our prototype Explosion is a part of\nBullet, because it’s the only thing that triggers it. Therefore Bullet has two stages of it’s\nlifecycle. First it flies towards the target, then it’s exploding. That brings us to Explosion:

\n\n

03-prototype/entities/explosion.rb

\n\n

 1 class Explosion\n 2   FRAME_DELAY = 10 # ms\n 3 \n 4   def animation\n 5     @@animation ||=\n 6     Gosu::Image.load_tiles(\n 7       $window, Game.media_path('explosion.png'), 128, 128, false)\n 8   end\n 9 \n10   def sound\n11     @@sound ||= Gosu::Sample.new(\n12       $window, Game.media_path('explosion.mp3'))\n13   end\n14 \n15   def initialize(x, y)\n16     sound.play\n17     @x, @y = x, y\n18     @current_frame = 0\n19   end\n20 \n21   def update\n22     @current_frame += 1 if frame_expired?\n23   end\n24 \n25   def draw\n26     return if done?\n27     image = current_frame\n28     image.draw(\n29       @x - image.width / 2 + 3,\n30       @y - image.height / 2 - 35,\n31       20)\n32   end\n33 \n34   def done?\n35     @done ||= @current_frame == animation.size\n36   end\n37 \n38   private\n39 \n40   def current_frame\n41     animation[@current_frame % animation.size]\n42   end\n43 \n44   def frame_expired?\n45     now = Gosu.milliseconds\n46     @last_frame ||= now\n47     if (now - @last_frame) > FRAME_DELAY\n48       @last_frame = now\n49     end\n50   end\n51 end\n

\n\n

There is nothing fancy about this implementation. Most of it is taken from “Images And Animation”\nchapter.

\n\n

Running The Prototype

\n\n

We have walked through all the code. You can get it\nat GitHub.

\n\n

Now it’s time to give it a spin. There is a video of me playing\nit available on YouTube, but it’s always best to\nexperience it firsthand. Run main.rb to start the game:

\n\n

$ ruby 03-prototype/main.rb\n

\n\n

Hit N to start new game.

\n\n

\n $\"Tanks$

Tanks Prototype menu

\n\n

Time to go crazy!

\n\n

\n $\"Tanks$

Tanks Prototype gameplay

\n\n

One thing should be bugging you at this point. FPS shows only 30, rather than 60. That means our\nprototype is slow. We will put it back to 60 FPS in next chapter.

\n\n

Optimizing Game Performance

\n\n

To make games that are fast and don’t require a powerhouse to run, we must learn how to find and\nfix bottlenecks. Good news is that if you wasn’t thinking about performance to begin with, your\nprogram can usually be optimized to run twice as fast just by eliminating one or two biggest\nbottlenecks.

\n\n

We will be using a copy of the prototype code to keep both optimized and original version,\ntherefore if you are exploring sample code, look at 04-prototype-optimized.

\n\n

Profiling Ruby Code To Find Bottlenecks

\n\n

We will try to find bottlenecks in our Tanks prototype game by profiling it with\nruby-prof.

\n\n

It’s a ruby gem, just install it like this:

\n\n

$ gem install ruby-prof\n

\n\n

There are several ways you can use ruby-prof, so we will begin with the easiest one. Instead of\nrunning the game with ruby, we will run it with ruby-prof:

\n\n

$ ruby-prof 03-prototype/main.rb\n

\n\n

The game will run, but everything will be ten times slower as usual, because every call to every\nfunction is being recorded, and after you exit the program, profiling output will be dumped\ndirectly to your console.

\n\n

Downside of this approach is that we are going to profile everything there is, including the\nsuper-slow map generation that uses Perlin Noise. We don’t want to optimize that, so in order to\nfind bottlenecks in our play state rather than map generation, we have to keep playing at dreadful\n2 FPS for at least 30 seconds.

\n\n

This was the output of first “naive” profiling session:

\n\n

\n $\"Initial$

Initial profiling results

\n\n

It’s obvious, that Camera#viewport and Camera#can_view? are top CPU burners. This means either\nthat our implementation is either very bad, or the assumption that checking if camera can view\nobject is slower than drawing the object off screen.

\n\n

Here are those slow methods:

\n\n

class Camera\n  # ...\n  def can_view?(x, y, obj)\n    x0, x1, y0, y1 = viewport\n    (x0 - obj.width..x1).include?(x) &&\n      (y0 - obj.height..y1).include?(y)\n  end\n  # ...\n  def viewport\n    x0 = @x - ($window.width / 2)  / @zoom\n    x1 = @x + ($window.width / 2)  / @zoom\n    y0 = @y - ($window.height / 2) / @zoom\n    y1 = @y + ($window.height / 2) / @zoom\n    [x0, x1, y0, y1]\n  end\n  # ...\nend\n

\n\n

It doesn’t look fundamentally broken, so we will try our “checking is slower than rendering”\nhypothesis by short-circuiting can_view? to return true every time:

\n\n

class Camera\n  # ...\n  def can_view?(x, y, obj)\n    return true # short circuiting\n    x0, x1, y0, y1 = viewport\n    (x0 - obj.width..x1).include?(x) &&\n      (y0 - obj.height..y1).include?(y)\n  end\n  # ...\nend\n

\n\n

After saving camera.rb and running the game without profiling, you will notice a significant\nspeedup. Hypothesis was correct, checking visibility is more expensive than simply rendering it.\nThat means we can throw away Camera#can_view? and calls to it.

\n\n

But before doing that, let’s profile once again:

\n\n

\n $\"Profiling$

Profiling results after short-circuiting Camera#can_view?

\n\n

We can see Camera#can_view? is still in top 3, so we will remove\nif camera.can_view?(map_x, map_y, tile) from Map#draw and for now keep it like this:

\n\n

class Map\n  # ...\n  def draw(camera)\n    @map.each do |x, row|\n      row.each do |y, val|\n        tile = @map[x][y]\n        map_x = x * TILE_SIZE\n        map_y = y * TILE_SIZE\n        tile.draw(map_x, map_y, 0)\n      end\n    end\n  end\n  # ...\nend\n

\n\n

After completely removing Camera#can_view?, profiling session looks like dead-end - no more low\nhanging fruits on top:

\n\n

\n $\"Profiling$

Profiling results after removing Camera#can_view?

\n\n

The game still doesn’t feel fast enough, FPS occasionally keeps dropping down to ~45, so we will\nhave to do profile our code in smarter way.

\n\n

Advanced Profiling Techniques

\n\n

We would get more accuracy when profiling only what we want to optimize. In our case it is\neverything that happens in PlayState, except for Map generation. This time we will have to use\nruby-prof API to hook into places we need.

\n\n

Map generation happens in PlayState initializer, so we will leverage GameState#enter and\nGameState#leave to start and stop profiling, since it happens after state is initialized. Here is\nhow we hook in:

\n\n

require 'ruby-prof'\nclass PlayState < GameState\n  # ...\n  def enter\n    RubyProf.start\n  end\n\n  def leave\n    result = RubyProf.stop\n    printer = RubyProf::FlatPrinter.new(result)\n    printer.print(STDOUT)\n  end\n  # ...\nend\n

\n\n

Then we run the game as usual:

\n\n

$ ruby 04-prototype-optimized/main.rb\n

\n\n

Now, after we press N to start new game, Map generation happens relatively fast, and then\nprofiling kicks in, FPS drops to 15. After moving around and shooting for a while we hit Esc to\nreturn to the menu, and at that point PlayState#leave spits profiling results out to the console:

\n\n

\n $\"Profiling$

Profiling results for PlayState

\n\n

We can see that\nGosu::Image#draw takes up to\n20% of all execution time. Then goes\nGosu::Window#caption, but\nwe need it to measure FPS, so we will leave it alone, and finally we can see\nHash#each, which is guaranteed to\nbe the one from Map#draw, and it triggers all those Gosu::Image#draw calls.

\n\n

Optimizing Inefficient Code

\n\n

According to profiling results, we need to optimize this method:

\n\n

class Map\n  # ...\n  def draw(camera)\n    @map.each do |x, row|\n      row.each do |y, val|\n        tile = @map[x][y]\n        map_x = x * TILE_SIZE\n        map_y = y * TILE_SIZE\n        tile.draw(map_x, map_y, 0)\n      end\n    end\n  end\n  # ...\nend\n

\n\n

But we have to optimize it in more clever way than we did before. If instead of looping through all\nmap rows and columns and blindly rendering every tile or checking if tile is visible we could\ncalculate the exact map cells that need to be displayed, we would reduce method complexity\nand get major performance boost. Let’s do that.

\n\n

We will use Camera#viewport to return map boundaries that are visible by camera, then divide those boundaries by Map#TILE_SIZE to get tile numbers instead of pixels, and retrieve them from the map.

\n\n

class Map\n  # ...\n  def draw(camera)\n    viewport = camera.viewport\n    viewport.map! { |p| p / TILE_SIZE }\n    x0, x1, y0, y1 = viewport.map(&:to_i)\n    (x0..x1).each do |x|\n      (y0..y1).each do |y|\n        row = @map[x]\n        if row\n          tile = @map[x][y]\n          map_x = x * TILE_SIZE\n          map_y = y * TILE_SIZE\n          tile.draw(map_x, map_y, 0)\n        end\n      end\n    end\n  end\n

\n\n

This optimization yielded astounding results. We are now getting nearly stable 60 FPS even when\nprofiling the code! Compare that to 2 FPS while profiling when we started.

\n\n

\n $\"Profiling$

Profiling results for PlayState after Map#draw optimization

\n\n

Now we just have to do something about that\nGosu::Window#caption,\nbecause it is consuming 1/3 of our CPU cycles! Even though game is already flying so fast that we\nwill have to reduce tank and bullet speeds to make it look more realistic, we cannot let ourselves\nleave this low hanging fruit remain unpicked.

\n\n

We will update the caption once per second, it should remove the bottleneck:

\n\n

class PlayState < GameState\n  # ...\n  def update\n    # ...\n    update_caption\n  end\n  # ...\n  private\n\n  def update_caption\n    now = Gosu.milliseconds\n    if now - (@caption_updated_at || 0) > 1000\n      $window.caption = 'Tanks Prototype. ' <<\n        \"[FPS: #{Gosu.fps}. \" <<\n        \"Tank @ #{@tank.x.round}:#{@tank.y.round}]\"\n      @caption_updated_at = now\n    end\n  end\nend\n

\n\n

Now it’s getting hard to get FPS to drop below 58, and profiling results show that there are\n no more bottlenecks:

\n\n

\n $\"Profiling$

Profiling results for PlayState after introducing Gosu::Window#caption cache

\n\n

We can now sleep well at night.

\n\n

Profiling On Demand

\n\n

When you develop a game, you may want to turn on profiling now and then. To avoid commenting\nout or adding and removing profiling every time you want to do so, use this trick:

\n\n

# ...\nrequire 'ruby-prof' if ENV['ENABLE_PROFILING']\nclass PlayState < GameState\n  # ...\n  def enter\n    RubyProf.start if ENV['ENABLE_PROFILING']\n  end\n\n  def leave\n    if ENV['ENABLE_PROFILING']\n      result = RubyProf.stop\n      printer = RubyProf::FlatPrinter.new(result)\n      printer.print(STDOUT)\n    end\n  end\n\n  def button_down(id)\n    # ...\n    if id == Gosu::KbQ\n      leave\n      $window.close\n    end\n  end\n  # ...\nend\n

\n\n

Now, to enable profiling, simply start your game with ENABLE_PROFILING=1 environmental variable,\nlike this:

\n\n

$ ENABLE_PROFILING=1 ruby-prof 03-prototype/main.rb\n

\n\n

Adjusting Game Speed For Variable Performance

\n\n

You should have noticed that our optimized Tanks prototype runs way too fast. Tanks and bullets\nshould travel same distance no matter how fast or slow the code is.

\n\n

One would expect\nGosu::Window#update_interval\nto be designed exactly for that purpose, but it returns 16.6666 in both original and optimized\nversion of the prototype, so you can guess it is the desired interval, not the actual one.

\n\n

To find out actual update interval, we will use\nGosu.milliseconds and\ncalculate it ourselves. To do that, we will introduce Game#track_update_interval that will be\ncalled in GameWindow#update, and Game#update_interval which will retrieve actual update\ninterval, so we can use it to adjust our run speed.

\n\n

We will also add Game#adjust_speed method\nthat will take arbitrary speed value and shift it so is as fast as it was when the game was running\nat 30 FPS. The formula is simple, if 60 FPS expects to call Gosu::Window#update every 16.66\nms, our speed adjustment will divide actual update rate from 33.33, which roughly equals to\n16.66 * 2. So, if bullet would fly 100 pixels per update in 30 FPS, adjusted speed will change it\nto 50 pixels at 60 FPS.

\n\n

Here is the implementation:

\n\n

# 04-prototype-optimized/main.rb\nmodule Game\n  # ...\n  def self.track_update_interval\n    now = Gosu.milliseconds\n    @update_interval = (now - (@last_update ||= 0)).to_f\n    @last_update = now\n  end\n\n  def self.update_interval\n    @update_interval ||= $window.update_interval\n  end\n\n  def self.adjust_speed(speed)\n    speed * update_interval / 33.33\n  end\nend\n\n# 04-prototype-optimized/game_window.rb\nclass GameWindow < Gosu::Window\n  # ...\n  def update\n    Game.track_update_interval\n    @state.update\n  end\n  # ...\nend\n

\n\n

Now, to fix that speed problem, we will need to apply Game.adjust_speed to tank, bullet and\ncamera movements.

\n\n

Here are all the changes needed to make our game run at roughly same speed in different conditions:

\n\n

# 04-prototype-optimized/entities/tank.rb\nclass Tank\n  # ...\n  def update(camera)\n    # ...\n    shift = Game.adjust_speed(speed)\n    new_x -= shift if $window.button_down?(Gosu::KbA)\n    new_x += shift if $window.button_down?(Gosu::KbD)\n    new_y -= shift if $window.button_down?(Gosu::KbW)\n    new_y += shift if $window.button_down?(Gosu::KbS)\n    # ...\n  end\n  # ...\nend\n\n# 04-prototype-optimized/entities/bullet.rb\nclass Bullet\n  # ...\n  def update\n    # ...\n    fly_speed = Game.adjust_speed(@speed)\n    fly_distance = (Gosu.milliseconds - @fired_at) * 0.001 * fly_speed\n    @x, @y = point_at_distance(fly_distance)\n    # ...\n  end\n  # ...\nend\n\n# 04-prototype-optimized/entities/camera.rb\nclass Camera\n  # ...\n  def update\n    shift = Game.adjust_speed(@target.speed)\n    @x += shift if @x < @target.x - $window.width / 4\n    @x -= shift if @x > @target.x + $window.width / 4\n    @y += shift if @y < @target.y - $window.height / 4\n    @y -= shift if @y > @target.y + $window.height / 4\n\n    zoom_delta = @zoom > 0 ? 0.01 : 1.0\n    zoom_delta = Game.adjust_speed(zoom_delta)\n    # ...\n  end\n  # ...\nend\n

\n\n

There is one more trick to make the game playable even at very low FPS. You can simulate such\nconditions by adding sleep 0.3 to GameWindow#draw method. At that framerate game cursor is very\nunresponsive, so you may want to start showing native mouse cursor when things get ugly, i.e. when\nupdate interval exceeds 200 milliseconds:

\n\n

# 04-prototype-optimized/game_window.rb\nclass GameWindow < Gosu::Window\n  # ...\n  def needs_cursor?\n    Game.update_interval > 200\n  end\n  # ...\nend\n

\n\n

Frame Skipping

\n\n

You will see strange things happening at very low framerates. For example, bullet explosions are\nshowing up frame by frame, so explosion speed seems way too slow and unrealistic. To avoid that, we\nwill modify our Explosion class to employ frame skipping if update rate is too slow:

\n\n

# 04-prototype-optimized/explosion.rb\nclass Explosion\n  FRAME_DELAY = 16.66 # ms\n  # ...\n  def update\n    advance_frame\n  end\n\n  def done?\n    @done ||= @current_frame >= animation.size\n  end\n  # ...\n  private\n  # ...\n  def advance_frame\n    now = Gosu.milliseconds\n    delta = now - (@last_frame ||= now)\n    if delta > FRAME_DELAY\n      @last_frame = now\n    end\n    @current_frame += (delta / FRAME_DELAY).floor\n  end\nend\n

\n\n

Now our prototype is playable even at lower frame rates.

\n\n

Refactoring The Prototype

\n\n

At this point you may be thinking where to go next. We want to implement enemies, collision\ndetection and AI, but design of current prototype is already limiting. Code is becoming tightly\ncoupled, there is no clean separation between different domains.

\n\n

If we were to continue building on top of our prototype, things would get ugly quickly. Thus we\nwill untangle the spaghetti and rewrite some parts from scratch to achieve elegance.

\n\n

Game Programming Patterns

\n\n

I would like to tip my hat to Robert Nystrom, who wrote this amazing book called Game Programming\nPatterns. The book is available online for free, it is a\nrelatively quick read - I’ve devoured it with pleasure in roughly 4 hours. If you are guessing that\nthis chapter is inspired by that book, you are absolutely right.

\n\n

Component pattern is especially noteworthy.\nWe will be using it to do major housekeeping, and it is great time to do so, because we haven’t\nimplemented much of the game yet.

\n\n

What Is Wrong With Current Design

\n\n

Until this point we have been building the code in monolithic fashion. Tank class holds the code\nthat:

\n\n

Loads all ground unit sprites. If some other class handled it, we could reuse the code to load\nother units.
Handles sound effects.
Uses Gosu::Song for moving sounds. That limits\nonly one tank movement sound per whole game. Basically, we abused Gosu here.
Handles keyboard and mouse. If we were to create AI that controls the tank, we would not be able to reuse Tank class because of this.
Draws graphics on screen.
Calculates physical properties, like speed, acceleration.
Detects movement collisions.

Bullet is not perfect either:

\n\n

It renders it’s graphics.
It handles it’s movement trajectories and other physics.
It treats Explosion as part of it’s own lifecycle.
Draws graphics on screen.
Handles sound effects.

Even the relatively small Explosion class is too monolithic:

\n\n

It loads it’s graphics.
It handles rendering, animation and frame skipping
It loads and plays it’s sound effects.

Decoupling Using Component Pattern

\n\n

Best design separates concerns in code so that everything has it’s own place, and every class\nhandles only one thing. Let’s try splitting up Tank class into components that handle specific\ndomains:

\n\n

\n $\"Decoupled$

Decoupled Tank

\n\n

We will introduce GameObject class will contain shared functionality for all game objects\n(Tank, Bullet, Explosion), each of them would have it’s own set of components. Every\ncomponent will have it’s parent object, so it will be able to interact with it, change it’s\nattributes, or possibly invoke other components if it comes to that.

\n\n

\n $\"Game$

Game objects and their components

\n\n

All these objects will be held within\nObjectPool, which would not care to know\nif object is a tank or a bullet. Purpose of ObjectPool is a little different\n in Ruby, since GC will take\ncare of memory fragmentation for us, but we still need a single place that knows about every object\nin the game.

\n\n

\n $\"Object$

Object Pool

\n\n

PlayState would then iterate through @object_pool.objects and invoke update and draw methods.

\n\n

Now, let’s begin by implementing base class for GameObject:

\n\n

05-refactor/entities/game_object.rb

\n\n

 1 class GameObject\n 2   def initialize(object_pool)\n 3     @components = []\n 4     @object_pool = object_pool\n 5     @object_pool.objects << self\n 6   end\n 7 \n 8   def components\n 9     @components\n10   end\n11 \n12   def update\n13     @components.map(&:update)\n14   end\n15 \n16   def draw(viewport)\n17     @components.each { |c| c.draw(viewport) }\n18   end\n19 \n20   def removable?\n21     @removable\n22   end\n23 \n24   def mark_for_removal\n25     @removable = true\n26   end\n27 \n28   protected\n29 \n30   def object_pool\n31     @object_pool\n32   end\n33 end\n

\n\n

When GameObject is initialized, it registers itself with ObjectPool and prepares empty\n@components array. Concrete GameObject classes should initialize Components so that array\nwould not be empty.

\n\n

update and draw methods would cycle through @components and delegate those calls to each of\nthem in a sequence. It is important to update all components first, and only then draw them.\nKeep in mind that @components array order has significance. First elements will always be updated\nand drawn before last ones.

\n\n

We will also provide removable? method that\nwould return true for objects that mark_for_removal was invoked on. This way we will be able to\nweed out old bullets and explosions and feed them to GC.

\n\n

Next up, base Component class:

\n\n

05-refactor/entities/components/component.rb

\n\n

 1 class Component\n 2   def initialize(game_object = nil)\n 3     self.object = game_object\n 4   end\n 5 \n 6   def update\n 7     # override\n 8   end\n 9 \n10   def draw(viewport)\n11     # override\n12   end\n13 \n14   protected\n15 \n16   def object=(obj)\n17     if obj\n18       @object = obj\n19       obj.components << self\n20     end\n21   end\n22 \n23   def x\n24     @object.x\n25   end\n26 \n27   def y\n28     @object.y\n29   end\n30 \n31   def object\n32     @object\n33   end\n34 end\n

\n\n

It registers itself with GameObject#components, provides some protected methods to access parent\nobject and it’s most often called properties - x and y.

\n\n

Refactoring Explosion

\n\n

Explosion was probably the smallest class, so we will extract it’s components first.

\n\n

05-refactor/entities/explosion.rb

\n\n

 1 class Explosion < GameObject\n 2   attr_accessor :x, :y\n 3 \n 4   def initialize(object_pool, x, y)\n 5     super(object_pool)\n 6     @x, @y = x, y\n 7     ExplosionGraphics.new(self)\n 8     ExplosionSounds.play\n 9   end\n10 end\n

\n\n

It is much cleaner than before. ExplosionGraphics will be a Component that handles animation,\nand ExplosionSounds will play a sound.

\n\n

05-refactor/entities/components/explosion_graphics.rb

\n\n

 1 class ExplosionGraphics < Component\n 2   FRAME_DELAY = 16.66 # ms\n 3 \n 4   def initialize(game_object)\n 5     super\n 6     @current_frame = 0\n 7   end\n 8 \n 9   def draw(viewport)\n10     image = current_frame\n11     image.draw(\n12       x - image.width / 2 + 3,\n13       y - image.height / 2 - 35,\n14       20)\n15   end\n16 \n17   def update\n18     now = Gosu.milliseconds\n19     delta = now - (@last_frame ||= now)\n20     if delta > FRAME_DELAY\n21       @last_frame = now\n22     end\n23     @current_frame += (delta / FRAME_DELAY).floor\n24     object.mark_for_removal if done?\n25   end\n26 \n27   private\n28 \n29   def current_frame\n30     animation[@current_frame % animation.size]\n31   end\n32 \n33   def done?\n34     @done ||= @current_frame >= animation.size\n35   end\n36 \n37   def animation\n38     @@animation ||=\n39     Gosu::Image.load_tiles(\n40       $window, Utils.media_path('explosion.png'),\n41       128, 128, false)\n42   end\n43 end\n

\n\n

Everything that is related to animating the explosion is now clearly separated.\nmark_for_removal is called on the explosion after it’s animation is done.

\n\n

05-refactor/entities/components/explosion_sounds.rb

\n\n

 1 class ExplosionSounds\n 2   class << self\n 3     def play\n 4       sound.play\n 5     end\n 6 \n 7     private\n 8 \n 9     def sound\n10       @@sound ||= Gosu::Sample.new(\n11         $window, Utils.media_path('explosion.mp3'))\n12     end\n13   end\n14 end\n

\n\n

Since explosion sounds are triggered only once, when it starts to explode, ExplosionSounds is a\nstatic class with play method.

\n\n

Refactoring Bullet

\n\n

Now, let’s go up a little and reimplement our Bullet:

\n\n

05-refactor/entities/bullet.rb

\n\n

 1 class Bullet < GameObject\n 2   attr_accessor :x, :y, :target_x, :target_y, :speed, :fired_at\n 3 \n 4   def initialize(object_pool, source_x, source_y, target_x, target_y)\n 5     super(object_pool)\n 6     @x, @y = source_x, source_y\n 7     @target_x, @target_y = target_x, target_y\n 8     BulletPhysics.new(self)\n 9     BulletGraphics.new(self)\n10     BulletSounds.play\n11   end\n12 \n13   def explode\n14     Explosion.new(object_pool, @x, @y)\n15     mark_for_removal\n16   end\n17 \n18   def fire(speed)\n19     @speed = speed\n20     @fired_at = Gosu.milliseconds\n21   end\n22 end\n

\n\n

All physics, graphics and sounds are extracted into individual components, and instead of managing\nExplosion, it just registers a new Explosion with ObjectPool and marks\nitself for removal in explode method.

\n\n

05-refactor/entities/components/bullet_physics.rb

\n\n

 1 class BulletPhysics < Component\n 2   START_DIST = 20\n 3   MAX_DIST = 300\n 4 \n 5   def initialize(game_object)\n 6     super\n 7     object.x, object.y = point_at_distance(START_DIST)\n 8     if trajectory_length > MAX_DIST\n 9       object.target_x, object.target_y = point_at_distance(MAX_DIST)\n10     end\n11   end\n12 \n13   def update\n14     fly_speed = Utils.adjust_speed(object.speed)\n15     fly_distance = (Gosu.milliseconds - object.fired_at) * 0.001 * fly_speed\n16     object.x, object.y = point_at_distance(fly_distance)\n17     object.explode if arrived?\n18   end\n19 \n20   def trajectory_length\n21     d_x = object.target_x - x\n22     d_y = object.target_y - y\n23     Math.sqrt(d_x * d_x + d_y * d_y)\n24   end\n25 \n26   def point_at_distance(distance)\n27     if distance > trajectory_length\n28       return [object.target_x, object.target_y]\n29     end\n30     distance_factor = distance.to_f / trajectory_length\n31     p_x = x + (object.target_x - x) * distance_factor\n32     p_y = y + (object.target_y - y) * distance_factor\n33     [p_x, p_y]\n34   end\n35 \n36   private\n37 \n38   def arrived?\n39     x == object.target_x && y == object.target_y\n40   end\n41 end\n

\n\n

BulletPhysics is where the most of Bullet ended up at. It does all the calculations and\ntriggers Bullet#explode when ready. When we will be implementing collision detection, the\nimplementation will go somewhere here.

\n\n

05-refactor/entities/components/bullet_graphics.rb

\n\n

 1 class BulletGraphics < Component\n 2   COLOR = Gosu::Color::BLACK\n 3 \n 4   def draw(viewport)\n 5     $window.draw_quad(x - 2, y - 2, COLOR,\n 6                       x + 2, y - 2, COLOR,\n 7                       x - 2, y + 2, COLOR,\n 8                       x + 2, y + 2, COLOR,\n 9                       1)\n10   end\n11 \n12 end\n

\n\n

After pulling away Bullet graphics code, it looks very small and elegant. We will probably never\nhave to edit anything here again.

\n\n

05-refactor/entities/components/bullet_sounds.rb

\n\n

 1 class BulletSounds\n 2   class << self\n 3     def play\n 4       sound.play\n 5     end\n 6 \n 7     private\n 8 \n 9     def sound\n10       @@sound ||= Gosu::Sample.new(\n11         $window, Utils.media_path('fire.mp3'))\n12     end\n13   end\n14 end\n

\n\n

Just like ExplosionSounds, BulletSounds are stateless and static. We could make it just like a\nregular component, but consider it our little optimization.

\n\n

Refactoring Tank

\n\n

Time to take a look at freshly decoupled Tank:

\n\n

05-refactor/entities/tank.rb

\n\n

 1 class Tank < GameObject\n 2   SHOOT_DELAY = 500\n 3   attr_accessor :x, :y, :throttle_down, :direction, :gun_angle, :sounds, :physics\n 4 \n 5   def initialize(object_pool, input)\n 6     super(object_pool)\n 7     @input = input\n 8     @input.control(self)\n 9     @physics = TankPhysics.new(self, object_pool)\n10     @graphics = TankGraphics.new(self)\n11     @sounds = TankSounds.new(self)\n12     @direction = @gun_angle = 0.0\n13   end\n14 \n15   def shoot(target_x, target_y)\n16     if Gosu.milliseconds - (@last_shot || 0) > SHOOT_DELAY\n17       @last_shot = Gosu.milliseconds\n18       Bullet.new(object_pool, @x, @y, target_x, target_y).fire(100)\n19     end\n20   end\n21 end\n

\n\n

Tank class was reduced over 5 times. We could go further and extract Gun component, but for now\nit’s simple enough already. Now, the components.

\n\n

05-refactor/entities/components/tank_physics.rb

\n\n

 1 class TankPhysics < Component\n 2   attr_accessor :speed\n 3 \n 4   def initialize(game_object, object_pool)\n 5     super(game_object)\n 6     @object_pool = object_pool\n 7     @map = object_pool.map\n 8     game_object.x, game_object.y = @map.find_spawn_point\n 9     @speed = 0.0\n10   end\n11 \n12   def can_move_to?(x, y)\n13     @map.can_move_to?(x, y)\n14   end\n15 \n16   def moving?\n17     @speed > 0\n18   end\n19 \n20   def update\n21     if object.throttle_down\n22       accelerate\n23     else\n24       decelerate\n25     end\n26     if @speed > 0\n27       new_x, new_y = x, y\n28       shift = Utils.adjust_speed(@speed)\n29       case @object.direction.to_i\n30       when 0\n31         new_y -= shift\n32       when 45\n33         new_x += shift\n34         new_y -= shift\n35       when 90\n36         new_x += shift\n37       when 135\n38         new_x += shift\n39         new_y += shift\n40       when 180\n41         new_y += shift\n42       when 225\n43         new_y += shift\n44         new_x -= shift\n45       when 270\n46         new_x -= shift\n47       when 315\n48         new_x -= shift\n49         new_y -= shift\n50       end\n51       if can_move_to?(new_x, new_y)\n52         object.x, object.y = new_x, new_y\n53       else\n54         object.sounds.collide if @speed > 1\n55         @speed = 0.0\n56       end\n57     end\n58   end\n59 \n60   private\n61 \n62   def accelerate\n63     @speed += 0.08 if @speed < 5\n64   end\n65 \n66   def decelerate\n67     @speed -= 0.5 if @speed > 0\n68     @speed = 0.0 if @speed < 0.01 # damp\n69   end\n70 end\n

\n\n

While we had to rip player input away from it’s movement, we got ourselves a benefit - tank now\nboth accelerates and decelerates. When directional buttons are no longer pressed, tank keeps moving\nin last direction, but quickly decelerates and stops. Another addition that would have been more\ndifficult to implement on previous Tank is collision sound. When Tank abruptly stops by hitting\nsomething (for now it’s only water), collision sound is played. We will have to fix that, because\nmetal bang is not appropriate when you stop on the edge of a river, but we now did it for the sake\nof science.

\n\n

05-refactor/entities/components/tank_graphics.rb

\n\n

 1 class TankGraphics < Component\n 2   def initialize(game_object)\n 3     super(game_object)\n 4     @body = units.frame('tank1_body.png')\n 5     @shadow = units.frame('tank1_body_shadow.png')\n 6     @gun = units.frame('tank1_dualgun.png')\n 7   end\n 8 \n 9   def draw(viewport)\n10     @shadow.draw_rot(x - 1, y - 1, 0, object.direction)\n11     @body.draw_rot(x, y, 1, object.direction)\n12     @gun.draw_rot(x, y, 2, object.gun_angle)\n13   end\n14 \n15   private\n16 \n17   def units\n18     @@units = Gosu::TexturePacker.load_json(\n19       $window, Utils.media_path('ground_units.json'), :precise)\n20   end\n21 end\n

\n\n

Again, graphics are neatly packed and separated from everything else. Eventually we should optimize\ndraw to take viewport into consideration, but it’s good enough for now, especially when we have\nonly one tank in the game.

\n\n

05-refactor/entities/components/tank_sounds.rb

\n\n

 1 class TankSounds < Component\n 2   def update\n 3     if object.physics.moving?\n 4       if @driving && @driving.paused?\n 5         @driving.resume\n 6       elsif @driving.nil?\n 7         @driving = driving_sound.play(1, 1, true)\n 8       end\n 9     else\n10       if @driving && @driving.playing?\n11         @driving.pause\n12       end\n13     end\n14   end\n15 \n16   def collide\n17     crash_sound.play(1, 0.25, false)\n18   end\n19 \n20   private\n21 \n22   def driving_sound\n23     @@driving_sound ||= Gosu::Sample.new(\n24       $window, Utils.media_path('tank_driving.mp3'))\n25   end\n26 \n27   def crash_sound\n28     @@crash_sound ||= Gosu::Sample.new(\n29       $window, Utils.media_path('crash.ogg'))\n30   end\n31 end\n

\n\n

Unlike Explosion and Bullet, Tank sounds are stateful. We have to keep track of\ntank_driving.mp3, which is no longer Gosu::Song,\nbut Gosu::Sample, like it should have been.

\n\n

When Gosu::Sample#play is\ninvoked, Gosu::SampleInstance is\nreturned, and we have full control over it. Now we are ready to play sounds for more than one tank\nat once.

\n\n

05-refactor/entities/components/player_input.rb

\n\n

 1 class PlayerInput < Component\n 2   def initialize(camera)\n 3     super(nil)\n 4     @camera = camera\n 5   end\n 6 \n 7   def control(obj)\n 8     self.object = obj\n 9   end\n10 \n11   def update\n12     d_x, d_y = @camera.target_delta_on_screen\n13     atan = Math.atan2(($window.width / 2) - d_x - $window.mouse_x,\n14                       ($window.height / 2) - d_y - $window.mouse_y)\n15     object.gun_angle = -atan * 180 / Math::PI\n16     motion_buttons = [Gosu::KbW, Gosu::KbS, Gosu::KbA, Gosu::KbD]\n17 \n18     if any_button_down?(*motion_buttons)\n19       object.throttle_down = true\n20       object.direction = change_angle(object.direction, *motion_buttons)\n21     else\n22       object.throttle_down = false\n23     end\n24 \n25     if Utils.button_down?(Gosu::MsLeft)\n26       object.shoot(*@camera.mouse_coords)\n27     end\n28   end\n29 \n30   private\n31 \n32   def any_button_down?(*buttons)\n33     buttons.each do |b|\n34       return true if Utils.button_down?(b)\n35     end\n36     false\n37   end\n38 \n39   def change_angle(previous_angle, up, down, right, left)\n40     if Utils.button_down?(up)\n41       angle = 0.0\n42       angle += 45.0 if Utils.button_down?(left)\n43       angle -= 45.0 if Utils.button_down?(right)\n44     elsif Utils.button_down?(down)\n45       angle = 180.0\n46       angle -= 45.0 if Utils.button_down?(left)\n47       angle += 45.0 if Utils.button_down?(right)\n48     elsif Utils.button_down?(left)\n49       angle = 90.0\n50       angle += 45.0 if Utils.button_down?(up)\n51       angle -= 45.0 if Utils.button_down?(down)\n52     elsif Utils.button_down?(right)\n53       angle = 270.0\n54       angle -= 45.0 if Utils.button_down?(up)\n55       angle += 45.0 if Utils.button_down?(down)\n56     end\n57     angle = (angle + 360) % 360 if angle && angle < 0\n58     (angle || previous_angle)\n59   end\n60 end\n

\n\n

We finally come to a place where keyboard and mouse input is handled and converted to Tank\ncommands. We could have used Command pattern\nto decouple everything even further.

\n\n

Refactoring PlayState

\n\n

05-refactor/game_states/play_state.rb

\n\n

 1 require 'ruby-prof' if ENV['ENABLE_PROFILING']\n 2 class PlayState < GameState\n 3   attr_accessor :update_interval\n 4 \n 5   def initialize\n 6     @map = Map.new\n 7     @camera = Camera.new\n 8     @object_pool = ObjectPool.new(@map)\n 9     @tank = Tank.new(@object_pool, PlayerInput.new(@camera))\n10     @camera.target = @tank\n11   end\n12 \n13   def enter\n14     RubyProf.start if ENV['ENABLE_PROFILING']\n15   end\n16 \n17   def leave\n18     if ENV['ENABLE_PROFILING']\n19       result = RubyProf.stop\n20       printer = RubyProf::FlatPrinter.new(result)\n21       printer.print(STDOUT)\n22     end\n23   end\n24 \n25   def update\n26     @object_pool.objects.map(&:update)\n27     @object_pool.objects.reject!(&:removable?)\n28     @camera.update\n29     update_caption\n30   end\n31 \n32   def draw\n33     cam_x = @camera.x\n34     cam_y = @camera.y\n35     off_x =  $window.width / 2 - cam_x\n36     off_y =  $window.height / 2 - cam_y\n37     viewport = @camera.viewport\n38     $window.translate(off_x, off_y) do\n39       zoom = @camera.zoom\n40       $window.scale(zoom, zoom, cam_x, cam_y) do\n41         @map.draw(viewport)\n42         @object_pool.objects.map { |o| o.draw(viewport) }\n43       end\n44     end\n45     @camera.draw_crosshair\n46   end\n47 \n48   def button_down(id)\n49     if id == Gosu::KbQ\n50       leave\n51       $window.close\n52     end\n53     if id == Gosu::KbEscape\n54       GameState.switch(MenuState.instance)\n55     end\n56   end\n57 \n58   private\n59 \n60   def update_caption\n61     now = Gosu.milliseconds\n62     if now - (@caption_updated_at || 0) > 1000\n63       $window.caption = 'Tanks Prototype. ' <<\n64         \"[FPS: #{Gosu.fps}. \" <<\n65         \"Tank @ #{@tank.x.round}:#{@tank.y.round}]\"\n66       @caption_updated_at = now\n67     end\n68   end\n69 end\n

\n\n

Implementation of PlayState is now also a little simpler. It doesn’t update @tank or @bullets\nindividually anymore. Instead, it uses ObjectPool and does all object operations in bulk.

\n\n

Other Improvements

\n\n

05-refactor/main.rb

\n\n

 1 #!/usr/bin/env ruby\n 2 \n 3 require 'gosu'\n 4 \n 5 root_dir = File.dirname(__FILE__)\n 6 require_pattern = File.join(root_dir, '**/*.rb')\n 7 @failed = []\n 8 \n 9 # Dynamically require everything\n10 Dir.glob(require_pattern).each do |f|\n11   next if f.end_with?('/main.rb')\n12   begin\n13     require_relative f.gsub(\"#{root_dir}/\", '')\n14   rescue\n15     # May fail if parent class not required yet\n16     @failed << f\n17   end\n18 end\n19 \n20 # Retry unresolved requires\n21 @failed.each do |f|\n22   require_relative f.gsub(\"#{root_dir}/\", '')\n23 end\n24 \n25 $window = GameWindow.new\n26 GameState.switch(MenuState.instance)\n27 $window.show\n

\n\n

Finally, we made some improvements to main.rb - it now recursively requires all *.rb files\nwithin same directory, so we don’t have to worry about it in other classes.

\n\n

05-refactor/utils.rb

\n\n

 1 module Utils\n 2   def self.media_path(file)\n 3     File.join(File.dirname(File.dirname(\n 4       __FILE__)), 'media', file)\n 5   end\n 6 \n 7   def self.track_update_interval\n 8     now = Gosu.milliseconds\n 9     @update_interval = (now - (@last_update ||= 0)).to_f\n10     @last_update = now\n11   end\n12 \n13   def self.update_interval\n14     @update_interval ||= $window.update_interval\n15   end\n16 \n17   def self.adjust_speed(speed)\n18     speed * update_interval / 33.33\n19   end\n20 \n21   def self.button_down?(button)\n22     @buttons ||= {}\n23     now = Gosu.milliseconds\n24     now = now - (now % 150)\n25     if $window.button_down?(button)\n26       @buttons[button] = now\n27       true\n28     elsif @buttons[button]\n29       if now == @buttons[button]\n30         true\n31       else\n32         @buttons.delete(button)\n33         false\n34       end\n35     end\n36   end\n37 end\n

\n\n

Another notable change is renaming Game module into Utils. The name finally makes more sense, I\nhave no idea why I put utility methods into Game module in the first place. Also, Utils\nreceived button_down? method, that solves the issue of changing tank direction when button is\nimmediately released. It made very difficult to stop at diagonal angle, because when you depressed\ntwo buttons, 16 ms was enough for Gosu to think “he released W, and S is still pressed, so let’s\nchange direction to S”. Utils#button_down? gives a soft 150 ms window to synchronize button\nrelease. Now controls feel more natural.

\n\n

Simulating Physics

\n\n

To make the game more realistic, we will spice things up with some physics. This is the feature set\nwe are going to implement:

\n\n

Collision detection. Tank will bump into other objects - stationary tanks. Bullets will not go\nthrough them either.
Terrain effects. Tank will go fast on grass, slower on sand.

Adding Enemy Objects

\n\n

It’s boring to play alone, so we will make a quick change and spawn some stationary tanks that will\nbe deployed randomly around the map. They will be stationary in the beginning, but we will still\nneed a dummy AI class to replace PlayerInput:

\n\n

06-physics/entities/components/ai_input.rb

\n\n

1 class AiInput < Component\n2   def control(obj)\n3     self.object = obj\n4   end\n5 end\n

\n\n

A quick and dirty way to spawn some tanks would be when initializing PlayState:

\n\n

class PlayState < GameState\n  # ...\n  def initialize\n    @map = Map.new\n    @camera = Camera.new\n    @object_pool = ObjectPool.new(@map)\n    @tank = Tank.new(@object_pool, PlayerInput.new(@camera))\n    @camera.target = @tank\n    # ...\n    50.times do\n      Tank.new(@object_pool, AiInput.new)\n    end\n  end\n  # ...\nend\n

\n\n

And unless we want all stationary tanks face same direction, we will randomize it:

\n\n

class Tank < GameObject\n  # ...\n  def initialize(object_pool, input)\n    # ...\n    @direction = rand(0..7) * 45\n    @gun_angle = rand(0..360)\n  end\n  # ...\nend\n

\n\n

Fire up the game, and wander around frozen tanks. You can pass through them as if they were ghosts,\nbut we will fix that in a moment.

\n\n

\n $\"Brain$

Brain dead enemies

\n\n

Adding Bounding Boxes And Detecting Collisions

\n\n

We want our collision detection to be pixel perfect, that means we need to have a bounding box and\ncheck colisions against it. Get ready for some math!

\n\n

First, we need to find a correct way to construct a bounding box. Tank has it’s body image, so\nlet’s see how it’s boundaries look like. We will add some code to TankGraphics component to see\nit:

\n\n

class TankGraphics < Component\n  def draw(viewport)\n    # ...\n    draw_bounding_box\n  end\n\n  def draw_bounding_box\n    $window.rotate(object.direction, x, y) do\n      w = @body.width\n      h = @body.height\n      $window.draw_quad(\n        x - w / 2, y - h / 2, Gosu::Color::RED,\n        x + w / 2, y - h / 2, Gosu::Color::RED,\n        x + w / 2, y + h / 2, Gosu::Color::RED,\n        x - w / 2, y + h / 2, Gosu::Color::RED,\n        100)\n    end\n  end\n  # ...\nend\n

\n\n

Result is pretty good, we have tank shaped box, so we will be using body image dimensions to determine\nour bounding box corners:

\n\n

\n $\"Tank's$

Tank’s bounding box visualized

\n\n

There is one problem here though.\nGosu::Window#rotate does\nthe rotation math for us, and we need to perform these calculations on our own. We have four points\nthat we want to rotate around a center point. It’s not very difficult to find how to do this. Here\nis a Ruby method for you:

\n\n

module Utils\n  # ...\n  def self.rotate(angle, around_x, around_y, *points)\n    result = []\n    points.each_slice(2) do |x, y|\n      r_x = Math.cos(angle) * (x - around_x) -\n        Math.sin(angle) * (y - around_y) + around_x\n      r_y = Math.sin(angle) * (x - around_x) +\n        Math.cos(angle) * (y - around_y) + around_y\n      result << r_x\n      result << r_y\n    end\n    result\n  end\n  # ...\nend\n

\n\n

We can now calculate edges of our bounding box, but we need one more function which tells if point\nis inside a polygon. This problem has been solved million times before, so just poke the internet\nfor it and drink from the information firehose until you understand how to do this.

\n\n

If you wasn’t familiar with the term yet, by now you should discover what\nvertex is. In geometry, a vertex (plural\nvertices) is a special kind of point that describes the corners or intersections of geometric\nshapes.

\n\n

Here’s what I ended up writing:

\n\n

module Utils\n  # ...\n  # http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html\n  def self.point_in_poly(testx, testy, *poly)\n    nvert = poly.size / 2 # Number of vertices in poly\n    vertx = []\n    verty = []\n    poly.each_slice(2) do |x, y|\n      vertx << x\n      verty << y\n    end\n    inside = false\n    j = nvert - 1\n    (0..nvert - 1).each do |i|\n      if (((verty[i] > testy) != (verty[j] > testy)) &&\n         (testx < (vertx[j] - vertx[i]) * (testy - verty[i]) /\n         (verty[j] - verty[i]) + vertx[i]))\n        inside = !inside\n      end\n      j = i\n    end\n    inside\n  end\n  # ...\n

\n\n

It is Jordan curve theorem reimplemented in\nRuby. Looks ugly, but it actually works, and is pretty fast too.

\n\n

Also, this works on more sophisticated polygons, and our tank is shaped more like an H rather than\na rectangle, so we could define a pixel perfect polygon. Some pen and paper will help.

\n\n

class TankPhysics < Component\n  #...\n\n  # Tank box looks like H. Vertices:\n  # 1   2   5   6\n  #     3   4\n  #\n  #    10   9\n  # 12 11   8   7\n  def box\n    w = box_width / 2 - 1\n    h = box_height / 2 - 1\n    tw = 8 # track width\n    fd = 8 # front depth\n    rd = 6 # rear depth\n    Utils.rotate(object.direction, x, y,\n                 x + w,      y + h,      #1\n                 x + w - tw, y + h,      #2\n                 x + w - tw, y + h - fd, #3\n\n                 x - w + tw, y + h - fd, #4\n                 x - w + tw, y + h,      #5\n                 x - w,      y + h,      #6\n\n                 x - w,      y - h,      #7\n                 x - w + tw, y - h,      #8\n                 x - w + tw, y - h + rd, #9\n\n                 x + w - tw, y - h + rd, #10\n                 x + w - tw, y - h,      #11\n                 x + w,      y - h,      #12\n                )\n  end\n  # ...\nend\n

\n\n

To visually see it, we will improve our draw_bounding_box method:

\n\n

class TankGraphics < Component\n  # ...\n  DEBUG_COLORS = [\n    Gosu::Color::RED,\n    Gosu::Color::BLUE,\n    Gosu::Color::YELLOW,\n    Gosu::Color::WHITE\n  ]\n  # ...\n  def draw_bounding_box\n    i = 0\n    object.box.each_slice(2) do |x, y|\n      color = DEBUG_COLORS[i]\n      $window.draw_triangle(\n        x - 3, y - 3, color,\n        x,     y,     color,\n        x + 3, y - 3, color,\n        100)\n      i = (i + 1) % 4\n    end\n  end\n  # ...\n

\n\n

Now we can visually test bounding box edges and see that they actually are where they belong.

\n\n

\n $\"High$

High precision bounding boxes

\n\n

Time to pimp our TankPhysics to detect those collisions. While our algorithm is pretty fast, it\ndoesn’t make sense to check collisions for objects that are pretty far apart. This is why we need\nour ObjectPool to know how to query objects in close proximity.

\n\n

class ObjectPool\n  # ...\n  def nearby(object, max_distance)\n    @objects.select do |obj|\n      distance = Utils.distance_between(\n        obj.x, obj.y, object.x, object.y)\n      obj != object && distance < max_distance\n    end\n  end\nend\n

\n\n

Back to TankPhysics:

\n\n

class TankPhysics < Component\n  # ...\n  def can_move_to?(x, y)\n    old_x, old_y = object.x, object.y\n    object.x = x\n    object.y = y\n    return false unless @map.can_move_to?(x, y)\n    @object_pool.nearby(object, 100).each do |obj|\n      if collides_with_poly?(obj.box)\n        # Allow to get unstuck\n        old_distance = Utils.distance_between(\n          obj.x, obj.y, old_x, old_y)\n        new_distance = Utils.distance_between(\n          obj.x, obj.y, x, y)\n        return false if new_distance < old_distance\n      end\n    end\n    true\n  ensure\n    object.x = old_x\n    object.y = old_y\n  end\n  # ...\n  private\n\n  def collides_with_poly?(poly)\n    if poly\n      poly.each_slice(2) do |x, y|\n        return true if Utils.point_in_poly(x, y, *box)\n      end\n      box.each_slice(2) do |x, y|\n        return true if Utils.point_in_poly(x, y, *poly)\n      end\n    end\n    false\n  end\n  # ...\nend\n

\n\n

It’s probably not the most elegant solution you could come up with, but can_move_to? temporarily\nchanges Tank location to make a collision test, and then reverts old coordinates just before\nreturning the result. Now our tanks stop with banging sound when they hit each other.

\n\n

\n $\"Tanks$

Tanks colliding

\n\n

Catching Bullets

\n\n

Right now bullets fly right through our tanks, and we want them to collide. It’s a pretty simple\nchange, which mostly affects BulletPhysics class:

\n\n

# 06-physics/entities/components/bullet_physics.rb\nclass BulletPhysics < Component\n  # ...\n  def update\n    # ...\n    check_hit\n    object.explode if arrived?\n  end\n  # ...\n  private\n\n  def check_hit\n    @object_pool.nearby(object, 50).each do |obj|\n      next if obj == object.source # Don't hit source tank\n      if Utils.point_in_poly(x, y, *obj.box)\n        object.target_x = x\n        object.target_y = y\n        return\n      end\n    end\n  end\n  # ...\nend\n

\n\n

Now bullets finally hit, but don’t do any damage yet. We will come back to that soon.

\n\n

\n $\"Bullet$

Bullet hitting enemy tank

\n\n

Implementing Turn Speed Penalties

\n\n

Tanks cannot make turns and go into reverse at full speed while keeping it’s inertia, right? It is\neasy to implement. Since it’s related to physics, we will delegate changing Tank’s @direction\nto our TankPhysics class:

\n\n

# 06-physics/entities/components/player_input.rb\nclass PlayerInput < Component\n  # ...\n  def update\n    # ...\n    motion_buttons = [Gosu::KbW, Gosu::KbS, Gosu::KbA, Gosu::KbD]\n\n    if any_button_down?(*motion_buttons)\n      object.throttle_down = true\n      object.physics.change_direction(\n        change_angle(object.direction, *motion_buttons))\n    else\n      object.throttle_down = false\n    end\n    # ...\n  end\n  # ...\nend\n\n# 06-physics/entities/components/tank_physics.rb\nclass TankPhysics < Component\n  # ...\n  def change_direction(new_direction)\n    change = (new_direction - object.direction + 360) % 360\n    change = 360 - change if change > 180\n    if change > 90\n      @speed = 0\n    elsif change > 45\n      @speed *= 0.33\n    elsif change > 0\n      @speed *= 0.66\n    end\n    object.direction = new_direction\n  end\n  # ...\nend\n

\n\n

Implementing Terrain Speed Penalties

\n\n

Now, let’s see how can we make terrain influence our movement. It sounds reasonable for\nTankPhysics to consult with Map about speed penalty of current tile:

\n\n

# 06-physics/entities/map.rb\nclass Map\n  # ...\n  def movement_penalty(x, y)\n    tile = tile_at(x, y)\n    case tile\n    when @sand\n      0.33\n    else\n      0\n    end\n  end\n  # ...\nend\n\n# 06-physics/entities/components/tank_physics.rb\nclass TankPhysics < Component\n  # ...\n  def update\n    # ...\n      speed = apply_movement_penalty(@speed)\n      shift = Utils.adjust_speed(speed)\n    # ...\n  end\n  # ...\n\n  private\n\n  def apply_movement_penalty(speed)\n    speed * (1.0 - @map.movement_penalty(x, y))\n  end\n  # ...\nend\n

\n\n

This makes all tanks move 33% slower on sand.

\n\n

Implementing Health And Damage

\n\n

I know you have been waiting for this. We will be implementing health system and most importantly,\ndamage. Soo we will be ready to blow shit up.

\n\n

To implement this, we need to:

\n\n

Add TankHealth component. Start with 100 health.
Render tank health next to tank itself.
Inflict damage to tank when it is in explosion zone
Render different sprite for dead tank.
Cut off player input when tank is dead.

Adding Health Component

\n\n

If we didn’t have Component system in place, it would be way more difficult. Now we just kick in\na new class:

\n\n

07-damage/entities/components/tank_health.rb

\n\n

 1 class TankHealth < Component\n 2   attr_accessor :health\n 3 \n 4   def initialize(object, object_pool)\n 5     super(object)\n 6     @object_pool = object_pool\n 7     @health = 100\n 8     @health_updated = true\n 9     @last_damage = Gosu.milliseconds\n10   end\n11 \n12   def update\n13     update_image\n14   end\n15 \n16   def update_image\n17     if @health_updated\n18       if dead?\n19         text = '✝'\n20         font_size = 25\n21       else\n22         text = @health.to_s\n23         font_size = 18\n24       end\n25       @image = Gosu::Image.from_text(\n26           $window, text,\n27           Gosu.default_font_name, font_size)\n28       @health_updated = false\n29     end\n30   end\n31 \n32   def dead?\n33     @health < 1\n34   end\n35 \n36   def inflict_damage(amount)\n37     if @health > 0\n38       @health_updated = true\n39       @health = [@health - amount.to_i, 0].max\n40       if @health < 1\n41         Explosion.new(@object_pool, x, y)\n42       end\n43     end\n44   end\n45 \n46   def draw(viewport)\n47     @image.draw(\n48       x - @image.width / 2,\n49       y - object.graphics.height / 2 -\n50       @image.height, 100)\n51   end\n52 end\n

\n\n

It hooks itself into the game right away, after we initialize it in Tank class:

\n\n

class Tank < GameObject\n  attr_accessor :health\n  # ...\n  def initialize(object_pool, input)\n    # ...\n    @health = TankHealth.new(self, object_pool)\n    # ..\n  end\n  # ..\nend\n

\n\n

Inflicting Damage With Bullets

\n\n

There are two ways to inflict damage - directly and indirectly. When bullet hits enemy tank\n(collides with tank bounding box), we should inflict direct damage. It can be done in\nBulletPhysics#check_hit method that we already had:

\n\n

class BulletPhysics < Component\n  # ...\n  def check_hit\n    @object_pool.nearby(object, 50).each do |obj|\n      next if obj == object.source # Don't hit source tank\n      if Utils.point_in_poly(x, y, *obj.box)\n        # Direct hit - extra damage\n        obj.health.inflict_damage(20)\n        object.target_x = x\n        object.target_y = y\n        return\n      end\n    end\n  end\n  # ...\nend\n

\n\n

Finally, Explosion itself should inflict additional damage to anything that are nearby. The\neffect will be diminishing and it will be determined by object distance.

\n\n

class Explosion < GameObject\n  # ...\n  def initialize(object_pool, x, y)\n    # ...\n    inflict_damage\n  end\n\n  private\n\n  def inflict_damage\n    object_pool.nearby(self, 100).each do |obj|\n      if obj.class == Tank\n        obj.health.inflict_damage(\n          Math.sqrt(3 * 100 - Utils.distance_between(\n              obj.x, obj.y, x, y)))\n      end\n    end\n  end\nend\n

\n\n

This is it, we are ready to deal damage. But we want to see if we actually killed somebody, so\nTankGraphics should be aware of health and should draw different set of sprites when tank is\ndead. Here is what we need to change in our current TankGraphics to achieve the result:

\n\n

class TankGraphics < Component\n  # ...\n  def initialize(game_object)\n    super(game_object)\n    @body_normal = units.frame('tank1_body.png')\n    @shadow_normal = units.frame('tank1_body_shadow.png')\n    @gun_normal = units.frame('tank1_dualgun.png')\n    @body_dead = units.frame('tank1_body_destroyed.png')\n    @shadow_dead = units.frame('tank1_body_destroyed_shadow.png')\n    @gun_dead = nil\n  end\n\n  def update\n    if object.health.dead?\n      @body = @body_dead\n      @gun = @gun_dead\n      @shadow = @shadow_dead\n    else\n      @body = @body_normal\n      @gun = @gun_normal\n      @shadow = @shadow_normal\n    end\n  end\n\n  def draw(viewport)\n    @shadow.draw_rot(x - 1, y - 1, 0, object.direction)\n    @body.draw_rot(x, y, 1, object.direction)\n    @gun.draw_rot(x, y, 2, object.gun_angle) if @gun\n  end\n  # ...\nend\n

\n\n

Now we can blow them up and enjoy the view:

\n\n

\n $\"Target$

Target practice

\n\n

But what if we blow ourselves up by shooting nearby? We would still be able to move around. To fix\nthis, we will simply cut out player input when we are dead:

\n\n

class PlayerInput < Component\n  # ...\n  def update\n    return if object.health.dead?\n    # ...\n  end\n  # ...\nend\n

\n\n

And to prevent tank from throttling forever if the pedal was down before it got killed:

\n\n

class TankPhysics < Component\n  # ...\n  def update\n    if object.throttle_down && !object.health.dead?\n      accelerate\n    else\n      decelerate\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

That’s it. All we need right now is some resistance from those brain dead enemies. We will spark\nsome life into them in next chapter.

\n\n

Creating Artificial Intelligence

\n\n

Artificial Intelligence is a subject so vast that we will barely scratch the surface.\nAI in Video Games\nis usually heavily simplified and therefore easier to implement.

\n\n

There is this wonderful series of articles called\nDesigning Artificial Intelligence for Games\nthat I highly recommend reading to get a feeling how game AI should be done. We will be\ncontinuing our work on top of what we already have, example code for this chapter will be in 08-ai.

\n\n

Designing AI Using Finite State Machine

\n\n

Non player tanks in our game will be lone rangers, hunting everything that moves while trying to\nsurvive. We will use Finite State Machine to implement tank behavior.

\n\n

First, we need to think “what would a tank do?” How about this scenario:

\n\n

Tank wanders around, minding it’s own business.
Tank encounters another tank. It then starts doing evasive moves and tries hitting the enemy.
Enemy took some damage and started driving away. Tank starts chasing the enemy trying to finish\nit.
Another tank appears and fires a couple of accurate shots, dealing serious damage. Our tank\nstarts running away, because if it kept receiving damage at such rate, it would die very soon.
Tank keeps fleeing and looking for safety until it gets cornered or the opponent looks damaged\ntoo. Then tank goes into it’s final battle.

We can now draw a Finite State Machine using this scenario:

\n\n

\n $\"Vigilante$

Vigilante Tank FSM

\n\n

If you are on a path to become a game developer, FSM should not stand for Flying Spaghetti\nMonster for you anymore.

\n\n

Implementing AI Vision

\n\n

To make opponents realistic, we have to give them senses. Let’s create a class for that:

\n\n

08-ai/entities/components/ai/vision.rb

\n\n

 1 class AiVision\n 2   CACHE_TIMEOUT = 500\n 3   attr_reader :in_sight\n 4 \n 5   def initialize(viewer, object_pool, distance)\n 6     @viewer = viewer\n 7     @object_pool = object_pool\n 8     @distance = distance\n 9   end\n10 \n11   def update\n12     @in_sight = @object_pool.nearby(@viewer, @distance)\n13   end\n14 \n15   def closest_tank\n16     now = Gosu.milliseconds\n17     @closest_tank = nil\n18     if now - (@cache_updated_at ||= 0) > CACHE_TIMEOUT\n19       @closest_tank = nil\n20       @cache_updated_at = now\n21     end\n22     @closest_tank ||= find_closest_tank\n23   end\n24 \n25   private\n26 \n27   def find_closest_tank\n28     @in_sight.select do |o|\n29       o.class == Tank && !o.health.dead?\n30     end.sort do |a, b|\n31       x, y = @viewer.x, @viewer.y\n32       d1 = Utils.distance_between(x, y, a.x, a.y)\n33       d2 = Utils.distance_between(x, y, b.x, b.y)\n34       d1 <=> d2\n35     end.first\n36   end\n37 end\n

\n\n

It uses ObjectPool to put nearby objects in sight, and gets a short term focus on one closest\ntank. Closest tank is cached for 500 milliseconds for two reasons:

\n\n

Performance. Uncached version would do Array#select and Array#sort 60 times per second, now\nit will do 2 times.
Focus. When you choose a target, you should keep it a little longer. This should also avoid\n“jitters”, when tank would shake between two nearby targets that are within same distance.

Controlling Tank Gun

\n\n

After we made AiVision, we can now use it to automatically aim and shoot at closest tank. It\nshould work like this:

\n\n

Every instance of the gun has it’s own unique combination of speed, accuracy and aggressiveness.
Gun will automatically target closest tank in sight.
If no other tank is in sight, gun will target in same direction as tank’s body.
If other tank is aimed at and within shooting distance, gun will make a decision once in a while\nwhether it should shoot or not, based on aggressiveness level. Aggressive tanks will be trigger\nhappy all the time, while less aggressive ones will make small random pauses between shots.
Gun will have a “desired” angle that it will be automatically adjusting to, according to it’s speed.

Here is the implementation:

\n\n

08-ai/entities/components/ai/gun.rb

\n\n

  1 class AiGun\n  2   DECISION_DELAY = 1000\n  3   attr_reader :target, :desired_gun_angle\n  4 \n  5   def initialize(object, vision)\n  6     @object = object\n  7     @vision = vision\n  8     @desired_gun_angle = rand(0..360)\n  9     @retarget_speed = rand(1..5)\n 10     @accuracy = rand(0..10)\n 11     @aggressiveness = rand(1..5)\n 12   end\n 13 \n 14   def adjust_angle\n 15     adjust_desired_angle\n 16     adjust_gun_angle\n 17   end\n 18 \n 19   def update\n 20     if @vision.in_sight.any?\n 21       if @vision.closest_tank != @target\n 22         change_target(@vision.closest_tank)\n 23       end\n 24     else\n 25       @target = nil\n 26     end\n 27 \n 28     if @target\n 29       if (0..10 - rand(0..@accuracy)).include?(\n 30         (@desired_gun_angle - @object.gun_angle).abs.round)\n 31         distance = distance_to_target\n 32         if distance - 50 <= BulletPhysics::MAX_DIST\n 33           target_x, target_y = Utils.point_at_distance(\n 34             @object.x, @object.y, @object.gun_angle,\n 35             distance + 10 - rand(0..@accuracy))\n 36           if can_make_new_decision? && @object.can_shoot? &&\n 37               should_shoot?\n 38             @object.shoot(target_x, target_y)\n 39           end\n 40         end\n 41       end\n 42     end\n 43   end\n 44 \n 45   def distance_to_target\n 46     Utils.distance_between(\n 47       @object.x, @object.y, @target.x, @target.y)\n 48   end\n 49 \n 50 \n 51   def should_shoot?\n 52     rand * @aggressiveness > 0.5\n 53   end\n 54 \n 55   def can_make_new_decision?\n 56     now = Gosu.milliseconds\n 57     if now - (@last_decision ||= 0) > DECISION_DELAY\n 58       @last_decision = now\n 59       true\n 60     end\n 61   end\n 62 \n 63   def adjust_desired_angle\n 64     @desired_gun_angle = if @target\n 65        Utils.angle_between(\n 66         @object.x, @object.y, @target.x, @target.y)\n 67     else\n 68       @object.direction\n 69     end\n 70   end\n 71 \n 72   def change_target(new_target)\n 73     @target = new_target\n 74     adjust_desired_angle\n 75   end\n 76 \n 77   def adjust_gun_angle\n 78     actual = @object.gun_angle\n 79     desired = @desired_gun_angle\n 80     if actual > desired\n 81       if actual - desired > 180 # 0 -> 360 fix\n 82         @object.gun_angle = (actual + @retarget_speed) % 360\n 83         if @object.gun_angle < desired\n 84           @object.gun_angle = desired # damp\n 85         end\n 86       else\n 87         @object.gun_angle = [actual - @retarget_speed, desired].max\n 88       end\n 89     elsif actual < desired\n 90       if desired - actual > 180 # 360 -> 0 fix\n 91         @object.gun_angle = (360 + actual - @retarget_speed) % 360\n 92         if @object.gun_angle > desired\n 93           @object.gun_angle = desired # damp\n 94         end\n 95       else\n 96         @object.gun_angle = [actual + @retarget_speed, desired].min\n 97       end\n 98     end\n 99   end\n100 end\n

\n\n

There is some math involved, but it is pretty straightforward. We need to find out an angle between\ntwo points, to know where our gun should point, and the other thing we need is coordinates of point\nwhich is in some distance away from source at given angle. Here are those functions:

\n\n

module Utils\n  # ...\n  def self.angle_between(x, y, target_x, target_y)\n    dx = target_x - x\n    dy = target_y - y\n    (180 - Math.atan2(dx, dy) * 180 / Math::PI) + 360 % 360\n  end\n\n  def self.point_at_distance(source_x, source_y, angle, distance)\n    angle = (90 - angle) * Math::PI / 180\n    x = source_x + Math.cos(angle) * distance\n    y = source_y - Math.sin(angle) * distance\n    [x, y]\n  end\n  # ...\nend\n

\n\n

Implementing AI Input

\n\n

At this point our tanks can already defend themselves, even through motion is not yet implemented.\nLet’s wire everything we have in AiInput class that we had prepared earlier. We\nwill need a blank TankMotionFSM class with 3 argument initializer and empty update,\non_collision(with) and on_damage(amount) methods for it to work:

\n\n

08-ai/entities/components/ai_input.rb

\n\n

 1 class AiInput < Component\n 2   UPDATE_RATE = 200 # ms\n 3 \n 4   def initialize(object_pool)\n 5     @object_pool = object_pool\n 6     super(nil)\n 7     @last_update = Gosu.milliseconds\n 8   end\n 9 \n10   def control(obj)\n11     self.object = obj\n12     @vision = AiVision.new(obj, @object_pool,\n13                            rand(700..1200))\n14     @gun = AiGun.new(obj, @vision)\n15     @motion = TankMotionFSM.new(obj, @vision, @gun)\n16   end\n17 \n18   def on_collision(with)\n19     @motion.on_collision(with)\n20   end\n21 \n22   def on_damage(amount)\n23     @motion.on_damage(amount)\n24   end\n25 \n26   def update\n27     return if object.health.dead?\n28     @gun.adjust_angle\n29     now = Gosu.milliseconds\n30     return if now - @last_update < UPDATE_RATE\n31     @last_update = now\n32     @vision.update\n33     @gun.update\n34     @motion.update\n35   end\n36 end\n

\n\n

It adjust gun angle all the time, but does updates at UPDATE_RATE to save CPU power. AI is\nusually one of the most CPU intensive things in games, so it’s a common practice to execute it less\noften. Refreshing enemy brains 5 per second is enough to make them deadly.

\n\n

Make sure you spawn some AI controlled tanks in PlayState and try killing them now. I bet they\nwill eventually get you even while standing still. You can also make tanks spawn below mouse cursor\nwhen you press T key:

\n\n

class PlayState < GameState\n  # ...\n  def initialize\n    # ...\n    10.times do |i|\n      Tank.new(@object_pool, AiInput.new(@object_pool))\n    end\n  end\n  # ...\n  def button_down(id)\n    # ...\n    if id == Gosu::KbT\n      t = Tank.new(@object_pool,\n                   AiInput.new(@object_pool))\n      t.x, t.y = @camera.mouse_coords\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

Implementing Tank Motion States

\n\n

This is the place where we will need Finite State Machine to get things right. We will design it\nlike this:

\n\n

\nTankMotionFSM will decide which motion state tank should be in, considering various\nparameters, e.g. existence of target or lack thereof, health, etc.
There will be TankMotionState base class that will offer common methods like drive, wait\nand on_collision.
Concrete motion classes will implement update, change_direction and other methods, that will\nfiddle with Tank#throttle_down and Tank#direction to make it move and turn.

We will begin with TankMotionState:

\n\n

08-ai/entities/components/ai/tank_motion_state.rb

\n\n

 1 class TankMotionState\n 2   def initialize(object, vision)\n 3     @object = object\n 4     @vision = vision\n 5   end\n 6 \n 7   def enter\n 8     # Override if necessary\n 9   end\n10 \n11   def change_direction\n12     # Override\n13   end\n14 \n15   def wait_time\n16     # Override and return a number\n17   end\n18 \n19   def drive_time\n20     # Override and return a number\n21   end\n22 \n23   def turn_time\n24     # Override and return a number\n25   end\n26 \n27   def update\n28     # Override\n29   end\n30 \n31   def wait\n32     @sub_state = :waiting\n33     @started_waiting = Gosu.milliseconds\n34     @will_wait_for = wait_time\n35     @object.throttle_down = false\n36   end\n37 \n38   def drive\n39     @sub_state = :driving\n40     @started_driving = Gosu.milliseconds\n41     @will_drive_for = drive_time\n42     @object.throttle_down = true\n43   end\n44 \n45   def should_change_direction?\n46     return true unless @changed_direction_at\n47     Gosu.milliseconds - @changed_direction_at >\n48       @will_keep_direction_for\n49   end\n50 \n51   def substate_expired?\n52     now = Gosu.milliseconds\n53     case @sub_state\n54     when :waiting\n55       true if now - @started_waiting > @will_wait_for\n56     when :driving\n57       true if now - @started_driving > @will_drive_for\n58     else\n59       true\n60     end\n61   end\n62 \n63   def on_collision(with)\n64     change = case rand(0..100)\n65     when 0..30\n66       -90\n67     when 30..60\n68       90\n69     when 60..70\n70       135\n71     when 80..90\n72       -135\n73     else\n74       180\n75     end\n76     @object.physics.change_direction(\n77       @object.direction + change)\n78   end\n79 end\n

\n\n

Nothing extraordinary here, and we need a concrete implementation to get a feeling how it would\nwork, therefore let’s examine TankRoamingState. It will be the default state which tank would be\nin if there were no enemies around.

\n\n

Tank Roaming State

\n\n

08-ai/entities/components/ai/tank_roaming_state.rb

\n\n

 1 class TankRoamingState < TankMotionState\n 2   def initialize(object, vision)\n 3     super\n 4     @object = object\n 5     @vision = vision\n 6   end\n 7 \n 8   def update\n 9     change_direction if should_change_direction?\n10     if substate_expired?\n11       rand > 0.3 ? drive : wait\n12     end\n13   end\n14 \n15   def change_direction\n16     change = case rand(0..100)\n17     when 0..30\n18       -45\n19     when 30..60\n20       45\n21     when 60..70\n22       90\n23     when 80..90\n24       -90\n25     else\n26       0\n27     end\n28     if change != 0\n29       @object.physics.change_direction(\n30         @object.direction + change)\n31     end\n32     @changed_direction_at = Gosu.milliseconds\n33     @will_keep_direction_for = turn_time\n34   end\n35 \n36   def wait_time\n37     rand(500..2000)\n38   end\n39 \n40   def drive_time\n41     rand(1000..5000)\n42   end\n43 \n44   def turn_time\n45     rand(2000..5000)\n46   end\n47 end\n

\n\n

The logic here:

\n\n

Tank will randomly change direction every turn_time interval, which is between 2 and 5\nseconds.
Tank will choose to drive (80% chance) or to stand still (20% chance).
If tank chose to drive, it will keep driving for drive_time, which is between 1 and 5 seconds.
Same goes with waiting, but wait_time (0.5 - 2 seconds) will be used for duration.
Direction changes and driving / waiting are independent.

This will make an impression that our tank is driving around looking for enemies.

\n\n

Tank Fighting State

\n\n

When tank finally sees an opponent, it will start fighting. Fighting motion should be more\nenergetic than roaming, we will need a sharper set of choices in change_direction among other\nthings.

\n\n

08-ai/entities/components/ai/tank_fighting_state.rb

\n\n

 1 class TankFightingState < TankMotionState\n 2   def initialize(object, vision)\n 3     super\n 4     @object = object\n 5     @vision = vision\n 6   end\n 7 \n 8   def update\n 9     change_direction if should_change_direction?\n10     if substate_expired?\n11       rand > 0.2 ? drive : wait\n12     end\n13   end\n14 \n15   def change_direction\n16     change = case rand(0..100)\n17     when 0..20\n18       -45\n19     when 20..40\n20       45\n21     when 40..60\n22       90\n23     when 60..80\n24       -90\n25     when 80..90\n26       135\n27     when 90..100\n28       -135\n29     end\n30     @object.physics.change_direction(\n31       @object.direction + change)\n32     @changed_direction_at = Gosu.milliseconds\n33     @will_keep_direction_for = turn_time\n34   end\n35 \n36   def wait_time\n37     rand(300..1000)\n38   end\n39 \n40   def drive_time\n41     rand(2000..5000)\n42   end\n43 \n44   def turn_time\n45     rand(500..2500)\n46   end\n47 end\n

\n\n

We will have much less waiting and much more driving and turning.

\n\n

Tank Chasing State

\n\n

If opponent is fleeing, we will want to set our direction towards the opponent and hit pedal to the\nmetal. No waiting here. AiGun#desired_gun_angle will point directly to our enemy.

\n\n

08-ai/entities/components/ai/tank_chasing_state.rb

\n\n

 1 class TankChasingState < TankMotionState\n 2   def initialize(object, vision, gun)\n 3     super(object, vision)\n 4     @object = object\n 5     @vision = vision\n 6     @gun = gun\n 7   end\n 8 \n 9   def update\n10     change_direction if should_change_direction?\n11     drive\n12   end\n13 \n14   def change_direction\n15     @object.physics.change_direction(\n16       @gun.desired_gun_angle -\n17       @gun.desired_gun_angle % 45)\n18 \n19     @changed_direction_at = Gosu.milliseconds\n20     @will_keep_direction_for = turn_time\n21   end\n22 \n23   def drive_time\n24     10000\n25   end\n26 \n27   def turn_time\n28     rand(300..600)\n29   end\n30 end\n

\n\n

Tank Fleeing State

\n\n

Now, if our health is low, we will do the opposite of chasing. Gun will be pointing and shooting at the\nopponent, but we want body to move away, so we won’t get ourselves killed. It is very similar to\nTankChasingState where change_direction adds extra 180 degrees to the equation, but there is\none more thing. Tank can only flee for a while. Then it gets itself together and goes into final\nbattle. That’s why we provide can_flee? method that TankMotionFSM will consult with before\nentering fleeing state.

\n\n

We have implemented all the states, that means we are moments away from actually playable prototype\nwith tank bots running around and fighting with you and each other.

\n\n

Wiring Tank Motion States Into Finite State Machine

\n\n

Implementing TankMotionFSM after we have all motion states ready is surprisingly easy:

\n\n

08-ai/entities/components/ai/tank_motion_fsm.rb

\n\n

 1 class TankMotionFSM\n 2   STATE_CHANGE_DELAY = 500\n 3 \n 4   def initialize(object, vision, gun)\n 5     @object = object\n 6     @vision = vision\n 7     @gun = gun\n 8     @roaming_state = TankRoamingState.new(object, vision)\n 9     @fighting_state = TankFightingState.new(object, vision)\n10     @fleeing_state = TankFleeingState.new(object, vision, gun)\n11     @chasing_state = TankChasingState.new(object, vision, gun)\n12     set_state(@roaming_state)\n13   end\n14 \n15   def on_collision(with)\n16     @current_state.on_collision(with)\n17   end\n18 \n19   def on_damage(amount)\n20     if @current_state == @roaming_state\n21       set_state(@fighting_state)\n22     end\n23   end\n24 \n25   def update\n26     choose_state\n27     @current_state.update\n28   end\n29 \n30   def set_state(state)\n31     return unless state\n32     return if state == @current_state\n33     @last_state_change = Gosu.milliseconds\n34     @current_state = state\n35     state.enter\n36   end\n37 \n38   def choose_state\n39     return unless Gosu.milliseconds -\n40       (@last_state_change) > STATE_CHANGE_DELAY\n41     if @gun.target\n42       if @object.health.health > 40\n43         if @gun.distance_to_target > BulletPhysics::MAX_DIST\n44           new_state = @chasing_state\n45         else\n46           new_state = @fighting_state\n47         end\n48       else\n49         if @fleeing_state.can_flee?\n50           new_state = @fleeing_state\n51         else\n52           new_state = @fighting_state\n53         end\n54       end\n55     else\n56       new_state = @roaming_state\n57     end\n58     set_state(new_state)\n59   end\n60 end\n

\n\n

All the logic is in choose_state method, which is pretty ugly and procedural, but it does the\njob. The code should be easy to understand, so instead of describing it, here is a picture worth\nthousand words:

\n\n

\n $\"First$

First real battle

\n\n

You may notice a new crosshair, which replaced the old one that was never visible:

\n\n

class Camera\n  # ...\n  def draw_crosshair\n    factor = 0.5\n    x = $window.mouse_x\n    y = $window.mouse_y\n    c = crosshair\n    c.draw(x - c.width * factor / 2,\n           y - c.height * factor / 2,\n           1000, factor, factor)\n  end\n  # ...\n  private\n\n  def crosshair\n    @crosshair ||= Gosu::Image.new(\n      $window, Utils.media_path('c_dot.png'), false)\n  end\nend\n

\n\n

However this new crosshair didn’t help me win, I got my ass kicked badly. Increasing game window\nsize helped, but we obviously need to fine tune many things in this AI, to make it smart and\nchallenging rather than dumb and deadly accurate.

\n\n

Making The Prototype Playable

\n\n

Right now we have a somewhat playable, but boring prototype without any scores or winning\nconditions. You can just run around and shoot other tanks. Nobody would play a game like this,\nhence we need to to add the missing parts. There is a crazy amount of them. It is time to give it a\nthorough play through and write down all the ideas and pain points about the prototype.

\n\n

Here is my list:

\n\n

Enemy tanks do not respawn.
Enemy tanks shoot at my current location, not at where I will be when bullet\nhits me.
Enemy tanks don’t avoid collisions.
Random maps are boring and lack detail, could use more tiles or random environment objects.
Bullets are hard to see on green surface.
Hard to tell where enemies are coming from, radar would help.
Sounds play at full volume even when something happens across the whole map.
My tank should respawn after it’s dead.
Motion and firing mechanics seem clumsy.
Map boundaries are visible when you come to the edge.
Enemy tank movement patterns need polishing and improvement.
Both my tank and enemies don’t have any identity. Sometimes hard to distinguish who is who.
No idea who has most kills. HUD with score and some state that displays score details would\nhelp.
Would be great to have random powerups like health, extra damage.
Explosions don’t leave a trace.
Tanks could leave trails.
Dead tanks keep piling up and cluttering the map.
Camera should be scouting ahead of you when you move, not dragging behind.
Bullets seem to accelerate.

This will keep us busy for a while, but in the end we will probably have something that will\nhopefully be able to entertain people for more than 3 minutes.

\n\n

Some items on this list are easy fixes. After playing around with Pixelmator for 15 minutes, I\nended up with a bullet that is visible on both light and dark backgrounds:

\n\n

\n $\"Highly$

Highly visible bullet

\n\n

Motion and firing mechanics will either have to be tuned setting by setting, or rewritten from\nscratch. Implementing score system, powerups and improving enemy AI deserve to have chapters of\ntheir own. The rest can be taken care of right away.

\n\n

Drawing Water Beyond Map Boundaries

\n\n

We don’t want to see darkness when we come to the edge of game world. Luckily, it is a trivial fix.\nIn Map#draw we check if tile exists in map before drawing it. When tile does not exist, we can\ndraw water instead. And we can always fallback to water tile in Map#tile_at:

\n\n

class Map\n  # ...\n  def draw(viewport)\n    viewport.map! { |p| p / TILE_SIZE }\n    x0, x1, y0, y1 = viewport.map(&:to_i)\n    (x0..x1).each do |x|\n      (y0..y1).each do |y|\n        row = @map[x]\n        map_x = x * TILE_SIZE\n        map_y = y * TILE_SIZE\n        if row\n          tile = @map[x][y]\n          if tile\n            tile.draw(map_x, map_y, 0)\n          else\n            @water.draw(map_x, map_y, 0)\n          end\n        else\n          @water.draw(map_x, map_y, 0)\n        end\n      end\n    end\n  end\n  # ...\n  private\n  # ...\n  def tile_at(x, y)\n    t_x = ((x / TILE_SIZE) % TILE_SIZE).floor\n    t_y = ((y / TILE_SIZE) % TILE_SIZE).floor\n    row = @map[t_x]\n    row ? row[t_y] : @water\n  end\n  # ...\nend\n

\n\n

Now the edge looks much better:

\n\n

\n $\"Map$

Map edge

\n\n

Generating Tree Clusters

\n\n

To make the map more fun to play at, we will generate some trees. Let’s start with Tree class:

\n\n

09-polishing/entities/tree.rb

\n\n

 1 class Tree < GameObject\n 2   attr_reader :x, :y, :health, :graphics\n 3 \n 4   def initialize(object_pool, x, y, seed)\n 5     super(object_pool)\n 6     @x, @y = x, y\n 7     @graphics = TreeGraphics.new(self, seed)\n 8     @health = Health.new(self, object_pool, 30, false)\n 9     @angle = rand(-15..15)\n10   end\n11 \n12   def on_collision(object)\n13     @graphics.shake(object.direction)\n14   end\n15 \n16   def box\n17     [x, y]\n18   end\n19 end\n

\n\n

Nothing fancy here, we want it to shake on collision, and it has graphics and health. seed will\nused to generate clusters of similar trees. Let’s take a look at TreeGraphics:

\n\n

09-polishing/entities/components/tree_graphics.rb

\n\n

 1 class TreeGraphics < Component\n 2   SHAKE_TIME = 100\n 3   SHAKE_COOLDOWN = 200\n 4   SHAKE_DISTANCE = [2, 1, 0, -1, -2, -1, 0, 1, 0, -1, 0]\n 5   def initialize(object, seed)\n 6     super(object)\n 7     load_sprite(seed)\n 8   end\n 9 \n10   def shake(direction)\n11     now = Gosu.milliseconds\n12     return if @shake_start &&\n13       now - @shake_start < SHAKE_TIME + SHAKE_COOLDOWN\n14     @shake_start = now\n15     @shake_direction = direction\n16     @shaking = true\n17   end\n18 \n19   def adjust_shake(x, y, shaking_for)\n20     elapsed = [shaking_for, SHAKE_TIME].min / SHAKE_TIME.to_f\n21     frame = ((SHAKE_DISTANCE.length - 1) * elapsed).floor\n22     distance = SHAKE_DISTANCE[frame]\n23     Utils.point_at_distance(x, y, @shake_direction, distance)\n24   end\n25 \n26   def draw(viewport)\n27     if @shaking\n28       shaking_for = Gosu.milliseconds - @shake_start\n29       shaking_x, shaking_y = adjust_shake(\n30         center_x, center_y, shaking_for)\n31       @tree.draw(shaking_x, shaking_y, 5)\n32       if shaking_for >= SHAKE_TIME\n33         @shaking = false\n34       end\n35     else\n36       @tree.draw(center_x, center_y, 5)\n37     end\n38     Utils.mark_corners(object.box) if $debug\n39   end\n40 \n41   def height\n42     @tree.height\n43   end\n44 \n45   def width\n46     @tree.width\n47   end\n48 \n49   private\n50 \n51   def load_sprite(seed)\n52     frame_list = trees.frame_list\n53     frame = frame_list[(frame_list.size * seed).round]\n54     @tree = trees.frame(frame)\n55   end\n56 \n57   def center_x\n58     @center_x ||= x - @tree.width / 2\n59   end\n60 \n61   def center_y\n62     @center_y ||= y - @tree.height / 2\n63   end\n64 \n65   def trees\n66     @@trees ||= Gosu::TexturePacker.load_json($window,\n67       Utils.media_path('trees_packed.json'))\n68   end\n69 end\n

\n\n

Shaking is probably the most interesting part here. When shake is called, graphics will start\ndrawing tree shifted in given direction by amount defined in SHAKE_DISTANCE array. draw will be\nstepping through SHAKE_DISTANCE depending on SHAKE_TIME, and it will not be shaken again for\nSHAKE_COOLDOWN period, to avoid infinite shaking while driving into it.

\n\n

We also need some adjustments to TankPhysics and Tank to be able to hit trees. First, we want\nto create an empty on_collision(object) method in GameObject class, so all game objects will\nbe able to collide.

\n\n

Then, TankPhysics starts calling Tank#on_collision when collision is detected:

\n\n

class Tank < GameObject\n  # ...\n  def on_collision(object)\n    return unless object\n    # Avoid recursion\n    if object.class == Tank\n      # Inform AI about hit\n      object.input.on_collision(object)\n    else\n      # Call only on non-tanks to avoid recursion\n      object.on_collision(self)\n    end\n    # Bullets should not slow Tanks down\n    if object.class != Bullet\n      @sounds.collide if @physics.speed > 1\n    end\n  end\n  # ...\nend\n

\n\n

The final ingredient to our Tree is Health, which is extracted from TankHealth to reduce\nduplication. TankHealth now extends it:

\n\n

09-polishing/entities/components/health.rb

\n\n

 1 class Health < Component\n 2   attr_accessor :health\n 3 \n 4   def initialize(object, object_pool, health, explodes)\n 5     super(object)\n 6     @explodes = explodes\n 7     @object_pool = object_pool\n 8     @initial_health = @health = health\n 9     @health_updated = true\n10   end\n11 \n12   def restore\n13     @health = @initial_health\n14     @health_updated = true\n15   end\n16 \n17   def dead?\n18     @health < 1\n19   end\n20 \n21   def update\n22     update_image\n23   end\n24 \n25   def inflict_damage(amount)\n26     if @health > 0\n27       @health_updated = true\n28       @health = [@health - amount.to_i, 0].max\n29       after_death if dead?\n30     end\n31   end\n32 \n33   def draw(viewport)\n34     return unless draw?\n35     @image && @image.draw(\n36       x - @image.width / 2,\n37       y - object.graphics.height / 2 -\n38       @image.height, 100)\n39   end\n40 \n41   protected\n42 \n43   def draw?\n44     $debug\n45   end\n46 \n47   def update_image\n48     return unless draw?\n49     if @health_updated\n50       text = @health.to_s\n51       font_size = 18\n52       @image = Gosu::Image.from_text(\n53           $window, text,\n54           Gosu.default_font_name, font_size)\n55       @health_updated = false\n56     end\n57   end\n58 \n59   def after_death\n60     if @explodes\n61       if Thread.list.count < 8\n62         Thread.new do\n63           sleep(rand(0.1..0.3))\n64           Explosion.new(@object_pool, x, y)\n65           sleep 0.3\n66           object.mark_for_removal\n67         end\n68       else\n69         Explosion.new(@object_pool, x, y)\n70         object.mark_for_removal\n71       end\n72     else\n73       object.mark_for_removal\n74     end\n75   end\n76 end\n

\n\n

Yes, you can make tree explode when it’s destroyed. And it causes cool chain reactions blowing up\nwhole tree clusters. But let’s not do that, because we will add something more appropriate for\nexplosions.

\n\n

Our Tree is ready to fill the landscape. We will do it in Map class, which will now need\nto know about ObjectPool, because trees will go there.

\n\n

class Map\n  # ...\n  def initialize(object_pool)\n    load_tiles\n    @object_pool = object_pool\n    object_pool.map = self\n    @map = generate_map\n    generate_trees\n  end\n  # ...\n  def generate_trees\n    noises = Perlin::Noise.new(2)\n    contrast = Perlin::Curve.contrast(\n      Perlin::Curve::CUBIC, 2)\n    trees = 0\n    target_trees = rand(300..500)\n    while trees < target_trees do\n      x = rand(0..MAP_WIDTH * TILE_SIZE)\n      y = rand(0..MAP_HEIGHT * TILE_SIZE)\n      n = noises[x * 0.001, y * 0.001]\n      n = contrast.call(n)\n      if tile_at(x, y) == @grass && n > 0.5\n        Tree.new(@object_pool, x, y, n * 2 - 1)\n        trees += 1\n      end\n    end\n  end\n  # ...\nend\n

\n\n

Perlin noise is used in similar fashion as it was when we generated map tiles. We allow creating\ntrees only if noise level is above 0.5, and use noise level as seed value - n * 2 - 1 will be a\nnumber between 0 and 1 when n is in 0.5..1 range. And we only allow creating trees on grass\ntiles.

\n\n

Now our map looks a little better:

\n\n

\n $\"Hiding$

Hiding among procedurally generated trees

\n\n

Generating Random Objects

\n\n

Trees are great, but we want more detail. Let’s spice things up with explosive boxes and barrels.\nThey will be using the same class with single sprite sheet, so while the sprite will be chosen\nrandomly, behavior will be the same. This new class will be called Box:

\n\n

09-polishing/entities/box.rb

\n\n

 1 class Box < GameObject\n 2   attr_reader :x, :y, :health, :graphics, :angle\n 3 \n 4   def initialize(object_pool, x, y)\n 5     super(object_pool)\n 6     @x, @y = x, y\n 7     @graphics = BoxGraphics.new(self)\n 8     @health = Health.new(self, object_pool, 10, true)\n 9     @angle = rand(-15..15)\n10   end\n11 \n12   def on_collision(object)\n13     return unless object.physics.speed > 1.0\n14     @x, @y = Utils.point_at_distance(@x, @y, object.direction, 2)\n15     @box = nil\n16   end\n17 \n18   def box\n19     return @box if @box\n20     w = @graphics.width / 2\n21     h = @graphics.height / 2\n22     # Bounding box adjusted to trim shadows\n23     @box = [x - w + 4,     y - h + 8,\n24             x + w , y - h + 8,\n25             x + w , y + h,\n26             x - w + 4,     y + h]\n27     @box = Utils.rotate(@angle, @x, @y, *@box)\n28   end\n29 end\n

\n\n

It will be generated with slight random angle, to preserve realistic shadows but give an impression\nof chaotic placement. Tanks will also be able to push boxes a little on collision, but only when\ngoing fast enough. Health component is the same one that Tree has, but initialized with less\nhealth and explosive flag is true, so the box will blow up after one hit and deal extra damage to\nthe surroundings.

\n\n

BoxGraphics is nothing fancy, it just loads random sprite upon initialization:

\n\n

09-polishing/entities/components/box_graphics.rb

\n\n

 1 class BoxGraphics < Component\n 2   def initialize(object)\n 3     super(object)\n 4     load_sprite\n 5   end\n 6 \n 7   def draw(viewport)\n 8     @box.draw_rot(x, y, 0, object.angle)\n 9     Utils.mark_corners(object.box) if $debug\n10   end\n11 \n12   def height\n13     @box.height\n14   end\n15 \n16   def width\n17     @box.width\n18   end\n19 \n20   private\n21 \n22   def load_sprite\n23     frame = boxes.frame_list.sample\n24     @box = boxes.frame(frame)\n25   end\n26 \n27   def center_x\n28     @center_x ||= x - width / 2\n29   end\n30 \n31   def center_y\n32     @center_y ||= y - height / 2\n33   end\n34 \n35   def boxes\n36     @@boxes ||= Gosu::TexturePacker.load_json($window,\n37       Utils.media_path('boxes_barrels.json'))\n38   end\n39 end\n

\n\n

Time to generate boxes in our Map. It will be similar to trees, but we won’t need Perlin noise,\nsince there will be way fewer boxes than trees, so we don’t need to form patterns. All we need to\ndo is to check if we’re not generating box on water.

\n\n

class Map\n  # ...\n  def initialize(object_pool)\n    # ...\n    generate_boxes\n  end\n  # ...\n  def generate_boxes\n    boxes = 0\n    target_boxes = rand(10..30)\n    while boxes < target_boxes do\n      x = rand(0..MAP_WIDTH * TILE_SIZE)\n      y = rand(0..MAP_HEIGHT * TILE_SIZE)\n      if tile_at(x, y) != @water\n        Box.new(@object_pool, x, y)\n        boxes += 1\n      end\n    end\n  end\n  # ...\nend\n

\n\n

Now give it a go. Beautiful, isn’t it?

\n\n

\n $\"Boxes$

Boxes and barrels in the jungle

\n\n

Implementing A Radar

\n\n

With all the visual noise it is getting increasingly difficult to see enemy tanks. That’s why we\nwill implement a Radar to help ourselves.

\n\n

09-polishing/entities/radar.rb

\n\n

 1 class Radar\n 2   UPDATE_FREQUENCY = 1000\n 3   WIDTH = 150\n 4   HEIGHT = 100\n 5   PADDING = 10\n 6   # Black with 33% transparency\n 7   BACKGROUND = Gosu::Color.new(255 * 0.33, 0, 0, 0)\n 8   attr_accessor :target\n 9 \n10   def initialize(object_pool, target)\n11     @object_pool = object_pool\n12     @target = target\n13     @last_update = 0\n14   end\n15 \n16   def update\n17     if Gosu.milliseconds - @last_update > UPDATE_FREQUENCY\n18       @nearby = nil\n19     end\n20     @nearby ||= @object_pool.nearby(@target, 2000).select do |o|\n21       o.class == Tank && !o.health.dead?\n22     end\n23   end\n24 \n25   def draw\n26     x1, x2, y1, y2 = radar_coords\n27     $window.draw_quad(\n28       x1, y1, BACKGROUND,\n29       x2, y1, BACKGROUND,\n30       x2, y2, BACKGROUND,\n31       x1, y2, BACKGROUND,\n32       200)\n33     draw_tank(@target, Gosu::Color::GREEN)\n34     @nearby && @nearby.each do |t|\n35       draw_tank(t, Gosu::Color::RED)\n36     end\n37   end\n38 \n39   private\n40 \n41   def draw_tank(tank, color)\n42     x1, x2, y1, y2 = radar_coords\n43     tx = x1 + WIDTH / 2 + (tank.x - @target.x) / 20\n44     ty = y1 + HEIGHT / 2 +  (tank.y - @target.y) / 20\n45     if (x1..x2).include?(tx) && (y1..y2).include?(ty)\n46       $window.draw_quad(\n47         tx - 2, ty - 2, color,\n48         tx + 2, ty - 2, color,\n49         tx + 2, ty + 2, color,\n50         tx - 2, ty + 2, color,\n51         300)\n52     end\n53   end\n54 \n55   def radar_coords\n56     x1 = $window.width - WIDTH - PADDING\n57     x2 = $window.width - PADDING\n58     y1 = $window.height - HEIGHT - PADDING\n59     y2 = $window.height - PADDING\n60     [x1, x2, y1, y2]\n61   end\n62 end\n

\n\n

Radar, like Camera, also has a target. It uses ObjectPool to query nearby objects and filters\nout instances of alive Tank. Then it draws a transparent black background and small dots for each\ntank, green for target, red for the rest.

\n\n

To avoid querying ObjectPool too often, Radar updates itself only once every second.

\n\n

It is initialized, updated and drawn in PlayState, right after Camera:

\n\n

class PlayState < GameState\n  # ...\n  def initialize\n    # ...\n    @camera.target = @tank\n    @radar = Radar.new(@object_pool, @tank)\n    # ...\n  end\n  # ...\n  def update\n    # ...\n    @camera.update\n    @radar.update\n    # ...\n  end\n  # ...\n  def draw\n    # ...\n    @camera.draw_crosshair\n    @radar.draw\n  end\n  # ...\nend\n

\n\n

Time to enjoy the results.

\n\n

\n $\"Radar$

Radar in action

\n\n

Dynamic Sound Volume And Panning

\n\n

We have improved the visuals, but sound is still terrible. Like some superhero, you can hear\neverything that happens in the map, and it can drive you insane. We will fix that in a moment.

\n\n

The idea is to make everything that happens further away from camera target sound less loud, until\nthe sound fades away completely. To make player’s experience more immersive, we will also take\nadvantage of stereo speakers - sounds should appear to be coming from the right direction.

\n\n

Unfortunately,\nGosu::Sample#play_pan\ndoes not work as one would expect it to. If you play the sample with just a little panning, it\ncompletely cuts off the opposite channel, meaning that if you play a sample with pan level of 0.1\n(10% to the right), you would expect to hear something in left speaker as well. The actual behavior\nis that sound plays through the right speaker pretty loudly, and if you increase pan level to, say,\n0.7, you will hear the sound through right speaker again, but it will be way more silent.

\n\n

To implement realistic stereo sounds that come through both speakers when panned, we need to play\ntwo samples with opposite pan level. After some experimenting, I discovered that fiddling with\npan level makes things sound weird, while playing with volume produces softer, more subtle\neffect. This is what I ended up having:

\n\n

09-polishing/misc/stereo_sample.rb

\n\n

 1 class StereoSample\n 2   @@all_instances = []\n 3 \n 4   def self.register_instances(instances)\n 5     @@all_instances << instances\n 6   end\n 7 \n 8   def self.cleanup\n 9     @@all_instances.each do |instances|\n10       instances.each do |key, instance|\n11         unless instance.playing? || instance.paused?\n12           instances.delete(key)\n13         end\n14       end\n15     end\n16   end\n17 \n18   def initialize(window, sound_l, sound_r = sound_l)\n19     @sound_l = Gosu::Sample.new(window, sound_l)\n20     # Use same sample in mono -> stereo\n21     if sound_l == sound_r\n22       @sound_r = @sound_l\n23     else\n24       @sound_r = Gosu::Sample.new(window, sound_r)\n25     end\n26     @instances = {}\n27     self.class.register_instances(@instances)\n28   end\n29 \n30   def paused?(id = :default)\n31     i = @instances[\"#{id}_l\"]\n32     i && i.paused?\n33   end\n34 \n35   def playing?(id = :default)\n36     i = @instances[\"#{id}_l\"]\n37     i && i.playing?\n38   end\n39 \n40   def stopped?(id = :default)\n41     @instances[\"#{id}_l\"].nil?\n42   end\n43 \n44   def play(id = :default, pan = 0,\n45            volume = 1, speed = 1, looping = false)\n46     @instances[\"#{id}_l\"] = @sound_l.play_pan(\n47       -0.2, 0, speed, looping)\n48     @instances[\"#{id}_r\"] = @sound_r.play_pan(\n49       0.2, 0, speed, looping)\n50     volume_and_pan(id, volume, pan)\n51   end\n52 \n53   def pause(id = :default)\n54     @instances[\"#{id}_l\"].pause\n55     @instances[\"#{id}_r\"].pause\n56   end\n57 \n58   def resume(id = :default)\n59     @instances[\"#{id}_l\"].resume\n60     @instances[\"#{id}_r\"].resume\n61   end\n62 \n63   def stop\n64     @instances.delete(\"#{id}_l\").stop\n65     @instances.delete(\"#{id}_r\").stop\n66   end\n67 \n68   def volume_and_pan(id, volume, pan)\n69     if pan > 0\n70       pan_l = 1 - pan * 2\n71       pan_r = 1\n72     else\n73       pan_l = 1\n74       pan_r = 1 + pan * 2\n75     end\n76     pan_l *= volume\n77     pan_r *= volume\n78     @instances[\"#{id}_l\"].volume = [pan_l, 0.05].max\n79     @instances[\"#{id}_r\"].volume = [pan_r, 0.05].max\n80   end\n81 end\n

\n\n

StereoSample manages stereo playback of sample instances, and to avoid memory leaks, it has\ncleanup that scans all sample instances and removes samples that have finished playing. For this\nremoval to work, we need to place a call to StereoSample.cleanup inside PlayState#update\nmethod.

\n\n

To determine correct pan and volume, we will create some helper methods in Utils module:

\n\n

module Utils\n  HEARING_DISTANCE = 1000.0\n  # ...\n  def self.volume(object, camera)\n    return 1 if object == camera.target\n    distance = Utils.distance_between(\n      camera.target.x, camera.target.y,\n      object.x, object.y)\n    distance = [(HEARING_DISTANCE - distance), 0].max\n    distance / HEARING_DISTANCE\n  end\n\n  def self.pan(object, camera)\n    return 0 if object == camera.target\n    pan = object.x - camera.target.x\n    sig = pan > 0 ? 1 : -1\n    pan = (pan % HEARING_DISTANCE) / HEARING_DISTANCE\n    if sig > 0\n      pan\n    else\n      -1 + pan\n    end\n  end\n\n  def self.volume_and_pan(object, camera)\n    [volume(object, camera), pan(object, camera)]\n  end\nend\n

\n\n

Apparently, having access to Camera is necessary for calculating sound volume and pan, so we will\nadd attr_accessor :camera to ObjectPool class and assign it in PlayState constructor. You may\nwonder why we didn’t use Camera#target right away. The answer is that camera can change it’s\ntarget. E.g. when your tank dies, new instance will be generated when you respawn, so if all other\nobjects would still have the reference to your old tank, guess what you would hear?

\n\n

Remastered TankSounds component is probably the most elaborate example of how StereoSample should be used:

\n\n

09-polishing/entities/components/tank_sounds.rb

\n\n

 1 class TankSounds < Component\n 2   def initialize(object, object_pool)\n 3     super(object)\n 4     @object_pool = object_pool\n 5   end\n 6 \n 7   def update\n 8     id = object.object_id\n 9     if object.physics.moving?\n10       move_volume = Utils.volume(\n11         object, @object_pool.camera)\n12       pan = Utils.pan(object, @object_pool.camera)\n13       if driving_sound.paused?(id)\n14         driving_sound.resume(id)\n15       elsif driving_sound.stopped?(id)\n16         driving_sound.play(id, pan, 0.5, 1, true)\n17       end\n18       driving_sound.volume_and_pan(id, move_volume * 0.5, pan)\n19     else\n20       if driving_sound.playing?(id)\n21         driving_sound.pause(id)\n22       end\n23     end\n24   end\n25 \n26   def collide\n27     vol, pan = Utils.volume_and_pan(\n28       object, @object_pool.camera)\n29     crash_sound.play(self.object_id, pan, vol, 1, false)\n30   end\n31 \n32   private\n33 \n34   def driving_sound\n35     @@driving_sound ||= StereoSample.new(\n36       $window, Utils.media_path('tank_driving.mp3'))\n37   end\n38 \n39   def crash_sound\n40     @@crash_sound ||= StereoSample.new(\n41       $window, Utils.media_path('metal_interaction2.wav'))\n42   end\n43 end\n

\n\n

And this is how static ExplosionSounds looks like:

\n\n

09-polishing/entities/components/explosion_sounds.rb

\n\n

 1 class ExplosionSounds\n 2   class << self\n 3     def play(object, camera)\n 4       volume, pan = Utils.volume_and_pan(object, camera)\n 5       sound.play(object.object_id, pan, volume)\n 6     end\n 7 \n 8     private\n 9 \n10     def sound\n11       @@sound ||= StereoSample.new(\n12         $window, Utils.media_path('explosion.mp3'))\n13     end\n14   end\n15 end\n

\n\n

After wiring everything so that sound components have access to ObjectPool, the rest is\nstraightforward.

\n\n

Giving Enemies Identity

\n\n

Wouldn’t it be great if you could tell yourself apart from the enemies. Moreover, enemies could\nhave names, so you would know which one is more aggressive or have, you know, personal issues with\nsomeone.

\n\n

To do that we need to ask the player to input a nickname, and choose some funny names for each\nenemy AI. Here is a nice list we will grab: http://www.paulandstorm.com/wha/clown-names/

\n\n

We first compile everything into a text filed called names.txt, that looks like this:

\n\n

media/names.txt

\n\n

Strippy\nBoffo\nBuffo\nDrips\n...\n

\n\n

Now we need a class to parse the list and give out random names from it. We also want to limit name\nlength to something that displays nicely.

\n\n

09-polishing/misc/names.rb

\n\n

 1 class Names\n 2   def initialize(file)\n 3     @names = File.read(file).split(\"\\n\").reject do |n|\n 4       n.size > 12\n 5     end\n 6   end\n 7 \n 8   def random\n 9     name = @names.sample\n10     @names.delete(name)\n11     name\n12   end\n13 end\n

\n\n

Then we need to place those names somewhere. We could assign them to tanks, but think ahead - if\nour player and AI enemies will respawn, we should give names to inputs, because Tank is\nreplaceable, driver is not. Well, it is, but let’s not get too deep into it.

\n\n

For now we just add name parameter to PlayerInput and AiInput initializers, save it in @name\ninstance variable, and then add draw(viewport) method to make it render below the tank:

\n\n

# 09-polishing/entities/components/player_input.rb\nclass PlayerInput < Component\n  # Dark green\n  NAME_COLOR = Gosu::Color.argb(0xee084408)\n\n  def initialize(name, camera)\n    super(nil)\n    @name = name\n    @camera = camera\n  end\n  # ...\n  def draw(viewport)\n    @name_image ||= Gosu::Image.from_text(\n      $window, @name, Gosu.default_font_name, 20)\n    @name_image.draw(\n      x - @name_image.width / 2 - 1,\n      y + object.graphics.height / 2, 100,\n      1, 1, Gosu::Color::WHITE)\n    @name_image.draw(\n      x - @name_image.width / 2,\n      y + object.graphics.height / 2, 100,\n      1, 1, NAME_COLOR)\n  end\n  # ...\nend\n\n# 09-polishing/entities/components/ai_input.rb\nclass AiInput < Component\n  # Dark red\n  NAME_COLOR = Gosu::Color.argb(0xeeb10000)\n\n  def initialize(name, object_pool)\n    super(nil)\n    @object_pool = object_pool\n    @name = name\n    @last_update = Gosu.milliseconds\n  end\n  # ...\n  def draw(viewport)\n    @motion.draw(viewport)\n    @gun.draw(viewport)\n    @name_image ||= Gosu::Image.from_text(\n      $window, @name, Gosu.default_font_name, 20)\n    @name_image.draw(\n      x - @name_image.width / 2 - 1,\n      y + object.graphics.height / 2, 100,\n      1, 1, Gosu::Color::WHITE)\n    @name_image.draw(\n      x - @name_image.width / 2,\n      y + object.graphics.height / 2, 100,\n      1, 1, NAME_COLOR)\n  end\n  # ...\nend\n

\n\n

We can see that generic Input class can be easily extracted, but let’s follow the\nRule of three and\nnot do premature refactoring.

\n\n

Instead, run the game and enjoy dying from a bunch of mad clowns.

\n\n

\n $\"Identity$

Identity makes a difference

\n\n

Respawning Tanks And Removing Dead Ones

\n\n

To implement respawning we could use Map#find_spawn_point every time we wanted to respawn, but it\nmay get slow, because it brute forces the map for random spots that are not water. We don’t want\nour game to start freezing when tanks are respawning, so we will change how tank spawning works.\nInstead of looking for a new respawn point all the time, we will pre-generate several of them for\nreuse.

\n\n

class Map\n  # ...\n  def spawn_points(max)\n    @spawn_points = (0..max).map do\n      find_spawn_point\n    end\n    @spawn_points_pointer = 0\n  end\n\n  def spawn_point\n    @spawn_points[(@spawn_points_pointer += 1) % @spawn_points.size]\n  end\n  # ...\nend\n

\n\n

Here we have spawn_points method that prepares a number of spawn points and stores them in\n@spawn_points instance variable, and spawn_point method that cycles through all @spawn_points\nand returns them one by one. find_spawn_point can now become private.

\n\n

We will use Map#spawn_points when initializing PlayState and pass ObjectPool to PlayerInput\n(AiInput already has it), so that we will be able to call @object_pool.map.spawn_point when needed.

\n\n

class PlayState < GameState\n  # ...\n  def initialize\n    # ...\n    @map = Map.new(@object_pool)\n    @map.spawn_points(15)\n    @tank = Tank.new(@object_pool,\n      PlayerInput.new('Player', @camera, @object_pool))\n    # ...\n    10.times do |i|\n      Tank.new(@object_pool, AiInput.new(\n        @names.random, @object_pool))\n    end\n  end\n  # ...\nend\n

\n\n

When tank dies, we want it to stay dead for 5 seconds and then respawn in one of our predefined\nspawn points. We will achieve that by adding respawn method and calling it in PlayerInput#update and\nAiInput#update if tank is dead.

\n\n

# 09-polishing/entities/components/player_input.rb\nclass PlayerInput < Component\n  # ...\n  def update\n    return respawn if object.health.dead?\n    # ...\n  end\n  # ...\n  private\n\n  def respawn\n    if object.health.should_respawn?\n      object.health.restore\n      object.x, object.y = @object_pool.map.spawn_point\n      @camera.x, @camera.y = x, y\n      PlayerSounds.respawn(object, @camera)\n    end\n  end\n  # ...\nend\n\n# 09-polishing/entities/components/ai_input.rb\nclass AiInput < Component\n  # ...\n  def update\n    return respawn if object.health.dead?\n    # ...\n  end\n  # ...\n  private\n\n  def respawn\n    if object.health.should_respawn?\n      object.health.restore\n      object.x, object.y = @object_pool.map.spawn_point\n      PlayerSounds.respawn(object, @object_pool.camera)\n    end\n  end\nend\n

\n\n

We need some changes in TankHealth class too:

\n\n

class TankHealth < Health\n  RESPAWN_DELAY = 5000\n  # ...\n  def should_respawn?\n    Gosu.milliseconds - @death_time > RESPAWN_DELAY\n  end\n  # ...\n  def after_death\n    @death_time = Gosu.milliseconds\n    # ...\n  end\nend\n\nclass Health < Component\n  # ...\n  def restore\n    @health = @initial_health\n    @health_updated = true\n  end\n  # ...\nend\n

\n\n

It shouldn’t be hard to put everything together and enjoy the never ending gameplay.

\n\n

You may have noticed that we also added a sound that will be played when player respawns. A nice\n“whoosh”.

\n\n

09-polishing/entities/components/player_sounds.rb

\n\n

 1 class PlayerSounds\n 2   class << self\n 3     def respawn(object, camera)\n 4       volume, pan = Utils.volume_and_pan(object, camera)\n 5       respawn_sound.play(object.object_id, pan, volume * 0.5)\n 6     end\n 7 \n 8     private\n 9 \n10     def respawn_sound\n11       @@respawn ||= StereoSample.new(\n12         $window, Utils.media_path('respawn.wav'))\n13     end\n14   end\n15 end\n

\n\n

Displaying Explosion Damage Trails

\n\n

When something blows up, you expect it to leave a trail, right? In our case explosions disappear as\nif nothing has ever happened, and we just can’t leave it like this. Let’s introduce Damage game\nobject\nthat will be responsible for displaying explosion residue on sand and grass:

\n\n

09-polishing/entities/damage.rb

\n\n

 1 class Damage < GameObject\n 2   MAX_INSTANCES = 100\n 3   attr_accessor :x, :y\n 4   @@instances = []\n 5 \n 6   def initialize(object_pool, x, y)\n 7     super(object_pool)\n 8     DamageGraphics.new(self)\n 9     @x, @y = x, y\n10     track(self)\n11   end\n12 \n13   def effect?\n14     true\n15   end\n16 \n17   private\n18 \n19   def track(instance)\n20     if @@instances.size < MAX_INSTANCES\n21       @@instances << instance\n22     else\n23       out = @@instances.shift\n24       out.mark_for_removal\n25       @@instances << instance\n26     end\n27   end\n28 end\n

\n\n

Damage tracks it’s instances and starts removing old ones when MAX_INSTANCES are reached.\nWithout this optimization, the game would get increasingly slower every time somebody shoots.

\n\n

We have also added a new game object trait - effect? returns true on Damage and Explosion,\nfalse on Tank, Tree, Box and Bullet. That way we can filter out effects when querying\nObjectPool#nearby for collisions or enemies.

\n\n

09-polishing/entities/object_pool.rb

\n\n

 1 class ObjectPool\n 2   attr_accessor :objects, :map, :camera\n 3 \n 4   def initialize\n 5     @objects = []\n 6   end\n 7 \n 8   def nearby(object, max_distance)\n 9     non_effects.select do |obj|\n10       obj != object &&\n11         (obj.x - object.x).abs < max_distance &&\n12         (obj.y - object.y).abs < max_distance &&\n13         Utils.distance_between(\n14           obj.x, obj.y, object.x, object.y) < max_distance\n15     end\n16   end\n17 \n18   def non_effects\n19     @objects.reject(&:effect?)\n20   end\n21 end\n

\n\n

When it comes to rendering graphics, to make an impression of randomness, we will cycle through several different damage images and draw\nthem rotated:

\n\n

09-polishing/entities/components/damage_graphics.rb

\n\n

 1 class DamageGraphics < Component\n 2   def initialize(object_pool)\n 3     super\n 4     @image = images.sample\n 5     @angle = rand(0..360)\n 6   end\n 7 \n 8   def draw(viewport)\n 9     @image.draw_rot(x, y, 0, @angle)\n10   end\n11 \n12   private\n13 \n14   def images\n15     @@images ||= (1..4).map do |i|\n16       Gosu::Image.new($window,\n17         Utils.media_path(\"damage#{i}.png\"), false)\n18     end\n19   end\n20 end\n

\n\n

Explosion will be responsible for creating Damage instances on solid ground, just before\nexplosion animation starts:

\n\n

class Explosion < GameObject\n  def initialize(object_pool, x, y)\n    # ...\n    if @object_pool.map.can_move_to?(x, y)\n      Damage.new(@object_pool, @x, @y)\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

And this is how the result looks like:

\n\n

\n $\"Damaged$

Damaged battlefield

\n\n

Debugging Bullet Physics

\n\n

When playing the game, there is a feeling that bullets start out slow when fired and gain speed as time goes.\nLet’s review BulletPhysics#update and think why this is happening:

\n\n

class BulletPhysics < Component\n  # ...\n  def update\n    fly_speed = Utils.adjust_speed(object.speed)\n    fly_distance = (Gosu.milliseconds - object.fired_at) *\n      0.001 * fly_speed / 2\n    object.x, object.y = point_at_distance(fly_distance)\n    check_hit\n    object.explode if arrived?\n  end\n  # ...\nend\n

\n\n

Flaw here is very obvious. Gosu.milliseconds - object.fired_at will be increasingly bigger as\ntime goes, thus increasing fly_distance. The fix is straightforward - we want to calculate\nfly_distance using time passed between calls to BulletPhysics#update, like this:

\n\n

class BulletPhysics < Component\n  # ...\n  def update\n    fly_speed = Utils.adjust_speed(object.speed)\n    now = Gosu.milliseconds\n    @last_update ||= object.fired_at\n    fly_distance = (now - @last_update) * 0.001 * fly_speed\n    object.x, object.y = point_at_distance(fly_distance)\n    @last_update = now\n    check_hit\n    object.explode if arrived?\n  end\n  # ...\nend\n

\n\n

But if you would run the game now, bullets would fly so slow, that you would feel like Neo in The\nMatrix. To fix that, we will have to tell our tank to fire bullets a little faster.

\n\n

class Tank < GameObject\n  # ...\n  def shoot(target_x, target_y)\n    if can_shoot?\n      @last_shot = Gosu.milliseconds\n      Bullet.new(object_pool, @x, @y, target_x, target_y)\n        .fire(self, 1500) # Old value was 100\n    end\n  end\n  # ...\nend\n

\n\n

Now bullets fly like they are supposed to. I can only wonder why haven’t I noticed this bug in the\nvery beginning.

\n\n

Making Camera Look Ahead

\n\n

One of the most annoying things with current state of prototype is that Camera is dragging\nbehind instead of showing what is in the direction you are moving. To fix the issue, we need to\nchange the way how Camera moves around. First we need to know where Camera wants to be. We will\nuse Utils.point_at_distance to choose a spot ahead of the Tank. Then, Camera#update needs to be rewritten, so Camera can dynamically adjust to it’s desired\nspot. Here are the changes:

\n\n

class Camera\n  # ...\n  def desired_spot\n    if @target.physics.moving?\n      Utils.point_at_distance(\n        @target.x, @target.y,\n        @target.direction,\n        @target.physics.speed.ceil * 25)\n    else\n      [@target.x, @target.y]\n    end\n  end\n  # ...\n  def update\n    des_x, des_y = desired_spot\n    shift = Utils.adjust_speed(\n      @target.physics.speed).floor + 1\n    if @x < des_x\n      if des_x - @x < shift\n        @x = des_x\n      else\n        @x += shift\n      end\n    elsif @x > des_x\n      if @x - des_x < shift\n        @x = des_x\n      else\n        @x -= shift\n      end\n    end\n    if @y < des_y\n      if des_y - @y < shift\n        @y = des_y\n      else\n        @y += shift\n      end\n    elsif @y > des_y\n      if @y - des_y < shift\n        @y = des_y\n      else\n        @y -= shift\n      end\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

It wouldn’t win code style awards, but it does the job. Game is now much more playable.

\n\n

Reviewing The Changes

\n\n

Let’s get back to our list of improvements to see what we have done:

\n\n

Enemy tanks do not respawn.
Random maps are boring and lack detail, could use more tiles or random environment objects.
Bullets are hard to see on green surface.
Hard to tell where enemies are coming from, radar would help.
Sounds play at full volume even when something happens across The whole map.
My tank should respawn after it’s dead.
Map boundaries are visible when you come to the edge.
Both my tank and enemies don’t have any identity. Sometimes hard to distinguish who is who.
Explosions don’t leave a trace.
Dead tanks keep piling up and cluttering the map.
Camera should be scouting ahead of you when you move, not dragging behind.
Bullets seem to accelerate.

Not bad for a start. This is what we still need to cover in next couple of chapters:

\n\n

Enemy tanks shoot at my current location, not at where I will be when bullet\nhits me.
Enemy tanks don’t avoid collisions.
Enemy tank movement patterns need polishing and improvement.
No idea who has most kills. HUD with score and some state that displays score details would
Would be great to have random powerups like health, extra damage.
Motion and firing mechanics seem clumsy.\nhelp.
Tanks could leave trails.

I will add “Optimize ObjectPool performance”, because game starts slowing down when too many\nobjects are added to the pool, and profiling shows that Array#select, which is the heart of\nObjectPool#nearby, is the main cause. Speed is one of most important features of any game, so\nlet’s not hesitate to improve it.

\n\n

Dealing With Thousands Of Game Objects

\n\n

Gosu is blazing fast when it comes to drawing, but there are more things going on. Namely, we use\nObjectPool#nearby quite often to loop through thousands of objects 60 times per\nsecond to measure distances among them. This slows everything down when object pool grows.

\n\n

To demonstrate the effect, we will generate 1500 trees, 30 tanks, ~100 boxes and leave 1000 damage\ntrails from explosions. It was enough to drop FPS below 30:

\n\n

\n $\"Running$

Running slow with thousands of game objects

\n\n

Spatial Partitioning

\n\n

There is a solution for this particular problem is “Spatial Partitioning”, and the\nessence of it is that you have to use a tree-like data structure that divides space into regions,\nplaces objects there and lets you query itself in\nlogarithmic time, omitting\nobjects that fall out of query region. Spatial Partitioning is explained well in\nGame Programming Patterns.

\n\n

Probably the most appropriate data structure for our 2D game is\nquadtree. To quote Wikipedia, “quadtrees are most often\nused to partition a two-dimensional space by recursively subdividing it into four quadrants or\nregions.” Here is how it looks like:

\n\n

\n $\"Visual$

Visual representation of quadtree

\n\n

Implementing A Quadtree

\n\n

There are some implementations of quadtree available for Ruby -\nrquad,\nrubyquadtree and\nrubyquad, but it seems easy to implement, so we will build one\ntailored (read: closely coupled) to our game using the pseudo code from Wikipedia.

\n\n

Axis Aligned Bounding Box

\n\n

One of prerequisites of quadtree is Axis aligned bounding\nbox,\nsometimes referred to as “AABB”. It is simply a box that surrounds the shape but has edges that are\nin parallel with the axes of underlying coordinate system. The advantage of this box is that it\ngives a rough estimate where the shape is and is very efficient when it comes to querying if a\npoint is inside or outside it.

\n\n

\n $\"Axis$

Axis aligned bounding box with center point and half dimension

\n\n

To define axis aligned bounding box, we need it’s center point and half dimension vector, which\npoints from center point to one of the corners of the box, and two methods, one that tells if AABB\ncontains a point, and one that tells if AABB intersects with another AABB. This is how our\nimplementation looks like:

\n\n

10-partitioning/misc/axis_aligned_bounding_box.rb

\n\n

 1 class AxisAlignedBoundingBox\n 2   attr_reader :center, :half_dimension\n 3   def initialize(center, half_dimension)\n 4     @center = center\n 5     @half_dimension = half_dimension\n 6     @dhx = (@half_dimension[0] - @center[0]).abs\n 7     @dhy = (@half_dimension[1] - @center[1]).abs\n 8   end\n 9 \n10   def contains?(point)\n11     return false unless (@center[0] + @dhx) >= point[0]\n12     return false unless (@center[0] - @dhx) <= point[0]\n13     return false unless (@center[1] + @dhy) >= point[1]\n14     return false unless (@center[1] - @dhy) <= point[1]\n15     true\n16   end\n17 \n18   def intersects?(other)\n19     ocx, ocy = other.center\n20     ohx, ohy = other.half_dimension\n21     odhx = (ohx - ocx).abs\n22     return false unless (@center[0] + @dhx) >= (ocx - odhx)\n23     return false unless (@center[0] - @dhx) <= (ocx + odhx)\n24     odhy = (ohy - ocy).abs\n25     return false unless (@center[1] + @dhy) >= (ocy - odhy)\n26     return false unless (@center[1] - @dhy) <= (ocy + odhy)\n27     true\n28   end\n29 \n30   def to_s\n31     \"c: #{@center}, h: #{@half_dimension}\"\n32   end\n33 end\n

\n\n

If you dig in 10-partitioning/specs, you will find tests for this implementation too.

\n\n

The math used in AxisAlignedBoundingBox#contains? and AxisAlignedBoundingBox#intersects? is\nfairly simple and hopefully very fast, because these methods will be called billions of times\nthroughout the game.

\n\n

QuadTree For Game Objects

\n\n

To implement the glorious QuadTree itself, we need to initialize it with boundary, that is\ndefined by an instance of AxisAlignedBoundingBox and provide methods for inserting, removing and\nquerying the tree. Private QuadTree#subdivide method will be called when we try to insert an\nobject into a tree that has more objects than it’s NODE_CAPACITY.

\n\n

10-partitioning/misc/quad_tree.rb

\n\n

 1 class QuadTree\n 2   NODE_CAPACITY = 12\n 3   attr_accessor :ne, :nw, :se, :sw, :objects\n 4 \n 5   def initialize(boundary)\n 6     @boundary = boundary\n 7     @objects = []\n 8   end\n 9 \n10   def insert(game_object)\n11     return false unless @boundary.contains?(\n12       game_object.location)\n13 \n14     if @objects.size < NODE_CAPACITY\n15       @objects << game_object\n16       return true\n17     end\n18 \n19     subdivide unless @nw\n20 \n21     return true if @nw.insert(game_object)\n22     return true if @ne.insert(game_object)\n23     return true if @sw.insert(game_object)\n24     return true if @se.insert(game_object)\n25 \n26     # should never happen\n27     raise \"Failed to insert #{game_object}\"\n28   end\n29 \n30   def remove(game_object)\n31     return false unless @boundary.contains?(\n32       game_object.location)\n33     if @objects.delete(game_object)\n34       return true\n35     end\n36     return false unless @nw\n37     return true if @nw.remove(game_object)\n38     return true if @ne.remove(game_object)\n39     return true if @sw.remove(game_object)\n40     return true if @se.remove(game_object)\n41     false\n42   end\n43 \n44   def query_range(range)\n45     result = []\n46     unless @boundary.intersects?(range)\n47       return result\n48     end\n49 \n50     @objects.each do |o|\n51       if range.contains?(o.location)\n52         result << o\n53       end\n54     end\n55 \n56     # Not subdivided\n57     return result unless @ne\n58 \n59     result += @nw.query_range(range)\n60     result += @ne.query_range(range)\n61     result += @sw.query_range(range)\n62     result += @se.query_range(range)\n63 \n64     result\n65   end\n66 \n67   private\n68 \n69   def subdivide\n70     cx, cy = @boundary.center\n71     hx, hy = @boundary.half_dimension\n72     hhx = (cx - hx).abs / 2.0\n73     hhy = (cy - hy).abs / 2.0\n74     @nw = QuadTree.new(\n75       AxisAlignedBoundingBox.new(\n76         [cx - hhx, cy - hhy],\n77         [cx, cy]))\n78     @ne = QuadTree.new(\n79       AxisAlignedBoundingBox.new(\n80         [cx + hhx, cy - hhy],\n81         [cx, cy]))\n82     @sw = QuadTree.new(\n83       AxisAlignedBoundingBox.new(\n84         [cx - hhx, cy + hhy],\n85         [cx, cy]))\n86     @se = QuadTree.new(\n87       AxisAlignedBoundingBox.new(\n88         [cx + hhx, cy + hhy],\n89         [cx, cy]))\n90   end\n91 end\n

\n\n

This is a vanilla quadtree that stores instances of GameObject and uses GameObject#location for\nindexing objects in space. It also has specs that you can find in code samples.

\n\n

You can experiment with QuadTree#NODE_CAPACITY, but I found that values between 8 and 16 works\nbest, so I settled with 12.

\n\n

Integrating ObjectPool With QuadTree

\n\n

We have implemented a QuadTree, but it is not yet incorporated into our game. To do that, we will\nhook it into ObjectPool and try to keep the old interface intact, so that ObjectPool#nearby\nwill still work as usual, but will be able to cope with way more objects than before.

\n\n

10-partitioning/entities/object_pool.rb

\n\n

 1 class ObjectPool\n 2   attr_accessor :map, :camera, :objects\n 3 \n 4   def size\n 5     @objects.size\n 6   end\n 7 \n 8   def initialize(box)\n 9     @tree = QuadTree.new(box)\n10     @objects = []\n11   end\n12 \n13   def add(object)\n14     @objects << object\n15     @tree.insert(object)\n16   end\n17 \n18   def tree_remove(object)\n19     @tree.remove(object)\n20   end\n21 \n22   def tree_insert(object)\n23     @tree.insert(object)\n24   end\n25 \n26   def update_all\n27     @objects.map(&:update)\n28     @objects.reject! do |o|\n29       if o.removable?\n30         @tree.remove(o)\n31         true\n32       end\n33     end\n34   end\n35 \n36   def nearby(object, max_distance)\n37     cx, cy = object.location\n38     hx, hy = cx + max_distance, cy + max_distance\n39     # Fast, rough results\n40     results = @tree.query_range(\n41       AxisAlignedBoundingBox.new([cx, cy], [hx, hy]))\n42     # Sift through to select fine-grained results\n43     results.select do |o|\n44       o != object &&\n45         Utils.distance_between(\n46           o.x, o.y, object.x, object.y) <= max_distance\n47     end\n48   end\n49 \n50   def query_range(box)\n51     @tree.query_range(box)\n52   end\n53 end\n

\n\n

An old fashioned array of all objects is still used, because we still need to loop through\neverything and invoke GameObject#update. ObjectPool#query_range was introduced to quickly grab\nobjects that have to be rendered on screen, and ObjectPool#nearby now queries tree and measures\ndistances only on rough result set.

\n\n

This is how we will render things from now on:

\n\n

class PlayState < GameState\n  # ...\n  def draw\n    cam_x = @camera.x\n    cam_y = @camera.y\n    off_x =  $window.width / 2 - cam_x\n    off_y =  $window.height / 2 - cam_y\n    viewport = @camera.viewport\n    x1, x2, y1, y2 = viewport\n    box = AxisAlignedBoundingBox.new(\n      [x1 + (x2 - x1) / 2, y1 + (y2 - y1) / 2],\n      [x1 - Map::TILE_SIZE, y1 - Map::TILE_SIZE])\n    $window.translate(off_x, off_y) do\n      zoom = @camera.zoom\n      $window.scale(zoom, zoom, cam_x, cam_y) do\n        @map.draw(viewport)\n        @object_pool.query_range(box).map do |o|\n          o.draw(viewport)\n        end\n      end\n    end\n    @camera.draw_crosshair\n    @radar.draw\n  end\n  # ...\nend\n

\n\n

Moving Objects In QuadTree

\n\n

There is one more errand we now have to take care of. Everything works fine when things are static,\nbut when tanks and bullets move, we need to update them in our QuadTree. That’s why ObjectPool\nhas tree_remove and tree_insert, which are called from GameObject#move. From now on, the only\nway to change object’s location will be by using GameObject#move:

\n\n

class GameObject\n  attr_reader :x, :y, :location, :components\n  def initialize(object_pool, x, y)\n    @x, @y = x, y\n    @location = [x, y]\n    @components = []\n    @object_pool = object_pool\n    @object_pool.add(self)\n  end\n\n  def move(new_x, new_y)\n    return if new_x == @x && new_y == @y\n    @object_pool.tree_remove(self)\n    @x = new_x\n    @y = new_y\n    @location = [new_x, new_y]\n    @object_pool.tree_insert(self)\n  end\n  # ...\nend\n

\n\n

At this point we have to go through all the game objects and change how they initialize their base\nclass and update x and y coordinates, but we won’t cover that here. If in doubt, refer to code\nat 10-partitioning.

\n\n

Finally, FPS is back to stable 60 and we can focus on gameplay again.

\n\n

\n $\"Spatial$

Spatial partitioning saves the day

\n\n

Implementing Powerups

\n\n

Game would become more strategic if there were ways to repair your damaged tank, boost it’s speed\nor increase rate of fire by picking up various powerups. This should not be too difficult to\nimplement. We will use some of these images:

\n\n

\n $\"Powerups\"$

Powerups

\n\n

For now, there will be four kinds of powerups:

\n\n

\nRepair damage. Wrench badge will restore damaged tank’s health back to 100 when picked up.
\nHealth boost. Green +1 badge will add 25 health, up to 200 total, if you keep picking them up.
\nFire boost. Double bullet badge will increase reload speed by 25%, up to 200% if you keep picking\nthem up.
\nSpeed boost. Airplane badge will increase movement speed by 10%, up to 150% if you keep\npicking them up

These powerups will be placed randomly around the map, and will automatically respawn 30 seconds after\npickup.

\n\n

Implementing Base Powerup

\n\n

Before rushing forward to implement this, we have to do some research and think how to elegantly\nintegrate this into the whole game. First, let’s agree that Powerup is a GameObject. It will\nhave graphics, sounds and it’s coordinates. Effects can by applied by harnessing\nGameObject#on_collision - when Tank collides with Powerup, it gets it.

\n\n

11-powerups/entities/powerups/powerup.rb

\n\n

 1 class Powerup < GameObject\n 2   def initialize(object_pool, x, y)\n 3     super\n 4     PowerupGraphics.new(self, graphics)\n 5   end\n 6 \n 7   def box\n 8     [x - 8, y - 8,\n 9      x + 8, y - 8,\n10      x + 8, y + 8,\n11      x - 8, y + 8]\n12   end\n13 \n14   def on_collision(object)\n15     if pickup(object)\n16       PowerupSounds.play(object, object_pool.camera)\n17       remove\n18     end\n19   end\n20 \n21   def pickup(object)\n22     # override and implement application\n23   end\n24 \n25   def remove\n26     object_pool.powerup_respawn_queue.enqueue(\n27       respawn_delay,\n28       self.class, x, y)\n29     mark_for_removal\n30   end\n31 \n32   def respawn_delay\n33     30\n34   end\n35 end\n

\n\n

Ignore Powerup#remove, we will get to it when implementing PowerupRespawnQueue. The rest should be\nstraightforward.

\n\n

Implementing Powerup Graphics

\n\n

All powerups will use the same sprite sheet, so there could be a\nsingle PowerupGraphics class that will be rendering given sprite type. We will use\ngosu-texture-packer gem, since sprite sheet is conveniently packed already.

\n\n

11-powerups/entities/components/powerup_graphics.rb

\n\n

 1 class PowerupGraphics < Component\n 2   def initialize(object, type)\n 3     super(object)\n 4     @type = type\n 5   end\n 6 \n 7   def draw(viewport)\n 8     image.draw(x - 12, y - 12, 1)\n 9     Utils.mark_corners(object.box) if $debug\n10   end\n11 \n12   private\n13 \n14   def image\n15     @image ||= images.frame(\"#{@type}.png\")\n16   end\n17 \n18   def images\n19     @@images ||= Gosu::TexturePacker.load_json(\n20       $window, Utils.media_path('pickups.json'))\n21   end\n22 end\n

\n\n

Implementing Powerup Sounds

\n\n

It’s even simpler with sounds. All powerups will emit a mellow “bleep” when picked up, so\nPowerupSounds can be completely static, like ExplosionSounds or BulletSounds:

\n\n

11-powerups/entities/components/powerup_sounds.rb

\n\n

 1 class PowerupSounds\n 2   class << self\n 3     def play(object, camera)\n 4       volume, pan = Utils.volume_and_pan(object, camera)\n 5       sound.play(object.object_id, pan, volume)\n 6     end\n 7 \n 8     private\n 9 \n10     def sound\n11       @@sound ||= StereoSample.new(\n12         $window, Utils.media_path('powerup.mp3'))\n13     end\n14   end\n15 end\n

\n\n

Implementing Repair Damage Powerup

\n\n

Repairing broken tank is probably the most important powerup of them all, so let’s implement it\nfirst:

\n\n

11-powerups/entities/powerups/repair_powerup.rb

\n\n

 1 class RepairPowerup < Powerup\n 2   def pickup(object)\n 3     if object.class == Tank\n 4       if object.health.health < 100\n 5         object.health.restore\n 6       end\n 7       true\n 8     end\n 9   end\n10 \n11   def graphics\n12     :repair\n13   end\n14 end\n

\n\n

This was incredibly simple. Health#restore already existed since we had to respawn our tanks.\nWe can only hope other powerups are as simple to implement as this one.

\n\n

Implementing Health Boost

\n\n

Repairing damage is great, but how about boosting some extra health for upcoming battles? Health\nboost to the rescue:

\n\n

11-powerups/entities/powerups/health_powerup.rb

\n\n

 1 class HealthPowerup < Powerup\n 2   def pickup(object)\n 3     if object.class == Tank\n 4       object.health.increase(25)\n 5       true\n 6     end\n 7   end\n 8 \n 9   def graphics\n10     :life_up\n11   end\n12 end\n

\n\n

This time we have to implement Health#increase, but it is pretty simple:

\n\n

class Health < Component\n  # ...\n  def increase(amount)\n    @health = [@health + 25, @initial_health * 2].min\n    @health_updated = true\n  end\n  # ...\nend\n

\n\n

Since Tank has @initial_health equal to 100, increasing health won’t go over 200, which is\nexactly what we want.

\n\n

Implementing Fire Rate Boost

\n\n

How about boosting tank’s fire rate?

\n\n

11-powerups/entities/powerups/fire_rate_powerup.rb

\n\n

 1 class FireRatePowerup < Powerup\n 2   def pickup(object)\n 3     if object.class == Tank\n 4       if object.fire_rate_modifier < 2\n 5         object.fire_rate_modifier += 0.25\n 6       end\n 7       true\n 8     end\n 9   end\n10 \n11   def graphics\n12     :straight_gun\n13   end\n14 end\n

\n\n

We need to introduce @fire_rate_modifier in Tank class and use it when calling\nTank#can_shoot?:

\n\n

class Tank < GameObject\n  # ...\n  attr_accessor :fire_rate_modifier\n  # ...\n  def can_shoot?\n    Gosu.milliseconds - (@last_shot || 0) >\n      (SHOOT_DELAY / @fire_rate_modifier)\n  end\n  # ...\n  def reset_modifiers\n    @fire_rate_modifier = 1\n  end\n  # ...\nend\n

\n\n

Tank#reset_modifier should be called when respawning, since we want tanks to lose their powerups\nwhen they die. It can be done in TankHealth#after_death:

\n\n

class TankHealth < Health\n  # ...\n  def after_death\n    object.reset_modifiers\n    # ...\n  end\nend\n

\n\n

Implementing Tank Speed Boost

\n\n

Tank speed boost is very similar to fire rate powerup:

\n\n

11-powerups/entities/powerups/tank_speed_powerup.rb

\n\n

 1 class TankSpeedPowerup < Powerup\n 2   def pickup(object)\n 3     if object.class == Tank\n 4       if object.speed_modifier < 1.5\n 5         object.speed_modifier += 0.10\n 6       end\n 7       true\n 8     end\n 9   end\n10 \n11   def graphics\n12     :wingman\n13   end\n14 end\n

\n\n

We have to add @speed_modifier to Tank class and use it in TankPhysics#update when calculating\nmovement distance.

\n\n

# 11-powerups/entities/tank.rb\nclass Tank < GameObject\n  # ...\n  attr_accessor :speed_modifier\n  # ...\n  def reset_modifiers\n    # ...\n    @speed_modifier = 1\n  end\n  # ...\nend\n\n# 11-powerups/entities/components/tank_physics.rb\nclass TankPhysics < Component\n  # ...\n  def update\n    # ...\n      new_x, new_y = x, y\n      speed = apply_movement_penalty(@speed)\n      shift = Utils.adjust_speed(speed) * object.speed_modifier\n    # ...\n  end\n  # ...\nend\n

\n\n

Camera#update has also refer to Tank#speed_modifier, otherwise the operator will fail to catch\nup and camera will be lagging behind.

\n\n

class Camera\n  # ...\n  def update\n    # ...\n    shift = Utils.adjust_speed(\n      @target.physics.speed).floor *\n      @target.speed_modifier + 1\n    # ...\n  end\n  # ...\nend\n

\n\n

Spawning Powerups On Map

\n\n

Powerups are implemented, but not yet spawned. We will spawn 20 - 30 random powerups when\ngenerating the map:

\n\n

class Map\n  # ...\n  def initialize(object_pool)\n    # ...\n    generate_powerups\n  end\n  # ...\n  def generate_powerups\n    pups = 0\n    target_pups = rand(20..30)\n    while pups < target_pups do\n      x = rand(0..MAP_WIDTH * TILE_SIZE)\n      y = rand(0..MAP_HEIGHT * TILE_SIZE)\n      if tile_at(x, y) != @water\n        random_powerup.new(@object_pool, x, y)\n        pups += 1\n      end\n    end\n  end\n\n  def random_powerup\n    [HealthPowerup,\n     RepairPowerup,\n     FireRatePowerup,\n     TankSpeedPowerup].sample\n  end\n  # ...\nend\n

\n\n

The code is very similar to generating boxes. It’s probably not the best way to distribute powerups\non map, but it will have to do for now.

\n\n

Respawning Powerups After Pickup

\n\n

When we pick up a powerup, we want it to reappear in same spot 30 seconds later. A thought “we can\nstart a new Thread with sleep and initialize the same powerup there” sounds very bad, but I had\nit for a few seconds. Then PowerupRespawnQueue was born.

\n\n

First, let’s recall how Powerup#remove method looks like:

\n\n

class Powerup < GameObject\n  # ...\n  def remove\n    object_pool.powerup_respawn_queue.enqueue(\n      respawn_delay,\n      self.class, x, y)\n    mark_for_removal\n  end\n  # ...\nend\n

\n\n

Powerup enqueues itself for respawn when picked up, providing it’s class and coordinates.\nPowerupRespawnQueue holds this data and respawns powerups at right time with help of\nObjectPool:

\n\n

11-powerups/entities/powerups/powerup_respawn_queue.rb

\n\n

 1 class PowerupRespawnQueue\n 2   RESPAWN_DELAY = 1000\n 3   def initialize\n 4     @respawn_queue = {}\n 5     @last_respawn = Gosu.milliseconds\n 6   end\n 7 \n 8   def enqueue(delay_seconds, type, x, y)\n 9     respawn_at = Gosu.milliseconds + delay_seconds * 1000\n10     @respawn_queue[respawn_at.to_i] = [type, x, y]\n11   end\n12 \n13   def respawn(object_pool)\n14     now = Gosu.milliseconds\n15     return if now - @last_respawn < RESPAWN_DELAY\n16     @respawn_queue.keys.each do |k|\n17       next if k > now # not yet\n18       type, x, y = @respawn_queue.delete(k)\n19       type.new(object_pool, x, y)\n20     end\n21     @last_respawn = now\n22   end\n23 end\n

\n\n

PowerupRespawnQeueue#respawn is called from ObjectPool#update_all, but is throttled to run once per second for better performance.

\n\n

class ObjectPool\n  # ...\n  attr_accessor :powerup_respawn_queue\n  # ...\n  def update_all\n    # ...\n    @powerup_respawn_queue.respawn(self)\n  end\n  # ...\nend\n

\n\n

This is it, the game should now contain randomly placed powerups that respawn 30 seconds after\npicked up. Time to enjoy the result.

\n\n

\n $\"Playing$

Playing with powerups

\n\n

We haven’t done any changes to AI though, that means enemies will only be picking those powerups by\naccident, so now you have a significant advantage and the game has suddenly became too easy to\nplay. Don’t worry, we will be fixing that when overhauling the AI.

\n\n

Implementing Heads Up Display

\n\n

In order to know what’s happening, we need some sort of HUD. We already have crosshair and radar,\nbut they are scattered around in code. Now we want to display active powerup modifiers, so you\nwould know what is your fire rate and speed, and if it’s worth getting one more powerup before\ngoing into the next fight.

\n\n

Design Considerations

\n\n

While creating our HUD class, we will have to start building game stats, because we want to display\nnumber of kills our tank made. Stats topic will be covered in depth later, but for now let’s assume\nthat @tank.input.stats.kills gives us the kill count, which we want to draw in top-left corner of\nthe screen, along with player health and modifier values.

\n\n

HUD will also be responsible for drawing crosshair and radar.

\n\n

Rendering Text With Custom Font

\n\n

Previously, all text were rendered with Gosu.default_font_name, and we want something more fancy\nand more thematic, probably a dirty stencil based font like this\none:

\n\n

\n $\"Armalite$

Armalite Rifle font

\n\n

And one more fancy font will make our game title look good. Too bad we don’t have a title yet, but\n“Tanks Prototype” writen in a thematic way still looks pretty good.

\n\n

To have convenient access to these fonts, we will add a helper methods in Utils:

\n\n

module Utils\n  # ...\n  def self.title_font\n    media_path('top_secret.ttf')\n  end\n\n  def self.main_font\n    media_path('armalite_rifle.ttf')\n  end\n  # ...\nend\n

\n\n

Use it instead of Gosu.default_font_name:

\n\n

size = 20\nGosu::Image.from_text($window, \"Your text\", Utils.main_font, size)\n

\n\n

Implementing HUD Class

\n\n

After we have put everything together, we will get HUD class:

\n\n

12-stats/entities/hud.rb

\n\n

 1 class HUD\n 2   attr_accessor :active\n 3   def initialize(object_pool, tank)\n 4     @object_pool = object_pool\n 5     @tank = tank\n 6     @radar = Radar.new(@object_pool, tank)\n 7   end\n 8 \n 9   def player=(tank)\n10     @tank = tank\n11     @radar.target = tank\n12   end\n13 \n14   def update\n15     @radar.update\n16   end\n17 \n18   def health_image\n19     if @health.nil? || @tank.health.health != @health\n20       @health = @tank.health.health\n21       @health_image = Gosu::Image.from_text(\n22         $window, \"Health: #{@health}\", Utils.main_font, 20)\n23     end\n24     @health_image\n25   end\n26 \n27   def stats_image\n28     stats = @tank.input.stats\n29     if @stats_image.nil? || stats.changed_at <= Gosu.milliseconds\n30       @stats_image = Gosu::Image.from_text(\n31         $window, \"Kills: #{stats.kills}\", Utils.main_font, 20)\n32     end\n33     @stats_image\n34   end\n35 \n36   def fire_rate_image\n37     if @tank.fire_rate_modifier > 1\n38       if @fire_rate != @tank.fire_rate_modifier\n39         @fire_rate = @tank.fire_rate_modifier\n40         @fire_rate_image = Gosu::Image.from_text(\n41           $window, \"Fire rate: #{@fire_rate.round(2)}X\",\n42           Utils.main_font, 20)\n43       end\n44     else\n45       @fire_rate_image = nil\n46     end\n47     @fire_rate_image\n48   end\n49 \n50   def speed_image\n51     if @tank.speed_modifier > 1\n52       if @speed != @tank.speed_modifier\n53         @speed = @tank.speed_modifier\n54         @speed_image = Gosu::Image.from_text(\n55           $window, \"Speed: #{@speed.round(2)}X\",\n56           Utils.main_font, 20)\n57       end\n58     else\n59       @speed_image = nil\n60     end\n61     @speed_image\n62   end\n63 \n64   def draw\n65     if @active\n66       @object_pool.camera.draw_crosshair\n67     end\n68     @radar.draw\n69     offset = 20\n70     health_image.draw(20, offset, 1000)\n71     stats_image.draw(20, offset += 30, 1000)\n72     if fire_rate_image\n73       fire_rate_image.draw(20, offset += 30, 1000)\n74     end\n75     if speed_image\n76       speed_image.draw(20, offset += 30, 1000)\n77     end\n78   end\n79 end\n

\n\n

To use it, we need to hook into PlayState:

\n\n

class PlayState < GameState\n  # ...\n  def initialize\n    # ...\n    @hud = HUD.new(@object_pool, @tank)\n  end\n\n  def update\n    # ...\n    @hud.update\n  end\n\n  def draw\n    # ...\n    @hud.draw\n  end\n  # ...\nend\n

\n\n

Assuming you have mocked @tank.input.stats.kills in HUD, you should get a neat view showing\ninteresting things in top-left corner of the screen:

\n\n

\n $\"Shiny$

Shiny new HUD

\n\n

Implementing Game Statistics

\n\n

Games like one we are building are all about competition, and you cannot compete if you don’t know\nthe score. Let us introduce a class that will be responsible for keeping tabs on various statistics\nof every tank.

\n\n

12-stats/misc/stats.rb

\n\n

 1 class Stats\n 2   attr_reader :name, :kills, :deaths, :shots, :changed_at\n 3   def initialize(name)\n 4     @name = name\n 5     @kills = @deaths = @shots = @damage = @damage_dealt = 0\n 6     changed\n 7   end\n 8 \n 9   def add_kill(amount = 1)\n10     @kills += amount\n11     changed\n12   end\n13 \n14   def add_death\n15     @deaths += 1\n16     changed\n17   end\n18 \n19   def add_shot\n20     @shots += 1\n21     changed\n22   end\n23 \n24   def add_damage(amount)\n25     @damage += amount\n26     changed\n27   end\n28 \n29   def damage\n30     @damage.round\n31   end\n32 \n33   def add_damage_dealt(amount)\n34     @damage_dealt += amount\n35     changed\n36   end\n37 \n38   def damage_dealt\n39     @damage_dealt.round\n40   end\n41 \n42   def to_s\n43     \"[kills: #{@kills}, \" \\\n44       \"deaths: #{@deaths}, \" \\\n45       \"shots: #{@shots}, \" \\\n46       \"damage: #{damage}, \" \\\n47       \"damage_dealt: #{damage_dealt}]\"\n48   end\n49 \n50   private\n51 \n52   def changed\n53     @changed_at = Gosu.milliseconds\n54   end\n55 end\n

\n\n

While building the HUD, we established that Stats should belong to Tank#input, because it\ndefines who is controlling the tank. So, every instance of PlayerInput and AiInput has to have\nit’s own Stats:

\n\n

# 12-stats/entities/components/player_input.rb\nclass PlayerInput < Component\n  # ...\n  attr_reader :stats\n\n  def initialize(name, camera, object_pool)\n    # ...\n    @stats = Stats.new(name)\n  end\n  # ...\n  def on_damage(amount)\n    @stats.add_damage(amount)\n  end\n  # ...\nend\n\n# 12-stats/entities/components/ai_input.rb\nclass AiInput < Component\n  # ...\n  attr_reader :stats\n\n  def initialize(name, object_pool)\n    # ...\n    @stats = Stats.new(name)\n  end\n\n  def on_damage(amount)\n    # ...\n    @stats.add_damage(amount)\n  end\nend\n

\n\n

That itch to extract a base class from PlayerInput and AiInput is getting stronger, but we will\nhave to resist the urge, for now.

\n\n

Tracking Kills, Deaths and Damage

\n\n

To begin tracking kills, we need to know whom does every bullet belong to. Bullet already has\nsource attribute, which contains the tank that fired it, there will be no trouble to find out who\nwas the shooter when bullet gets a direct hit. But how about explosions? Bullets that hit the\nground nearby a tank deals indirect damage from the explosion.

\n\n

Solution is simple, we need to pass the source of the Bullet to the Explosion when it’s being\ninitialized.

\n\n

class Bullet < GameObject\n  # ...\n  def explode\n    Explosion.new(object_pool, @x, @y, @source)\n    # ...\n  end\n  # ...\nend\n

\n\n

Making Damage Personal

\n\n

Now that we have the source of every Bullet and Explosion they trigger, we can start passing\nthe cause of damage to Health#inflict_damage and incrementing the appropriate stats.

\n\n

# 12-stats/entities/components/health.rb\nclass Health < Component\n  # ...\n  def inflict_damage(amount, cause)\n    if @health > 0\n      @health_updated = true\n      if object.respond_to?(:input)\n        object.input.stats.add_damage(amount)\n        # Don't count damage to trees and boxes\n        if cause.respond_to?(:input) && cause != object\n          cause.input.stats.add_damage_dealt(amount)\n        end\n      end\n      @health = [@health - amount.to_i, 0].max\n      after_death(cause) if dead?\n    end\n  end\n  # ...\nend\n\n# 12-stats/entities/components/tank_health.rb\nclass TankHealth < Health\n  # ...\n  def after_death(cause)\n    # ...\n    object.input.stats.add_death\n    kill = object != cause ? 1 : -1\n    cause.input.stats.add_kill(kill)\n    # ...\n  end\n# ...\nend\n

\n\n

Tracking Damage From Chain Reactions

\n\n

There is one more way to cause damage. When you shoot a tree, box or barrel, it explodes, probably\ntriggering a chain reaction of explosions around it. If those explosions kill somebody, it would\nonly be fair to account that kill for the tank that triggered this chain reaction.

\n\n

To solve this, simply pass the cause of death to the Explosion that gets triggered afterwards.

\n\n

# 12-stats/entities/components/health.rb\nclass Health < Component\n  # ...\n  def after_death(cause)\n    if @explodes\n      Thread.new do\n        # ...\n        Explosion.new(@object_pool, x, y, cause)\n        # ...\n      end\n      # ...\n    end\n  end\nend\n\n# 12-stats/entities/components/tank_health.rb\nclass TankHealth < Health\n  # ...\n  def after_death(cause)\n    # ...\n    Thread.new do\n      # ...\n      Explosion.new(@object_pool, x, y, cause)\n    end\n  end\nend\n

\n\n

Now every bit of damage gets accounted for.

\n\n

Displaying Game Score

\n\n

Having all the data is useless unless we display it somehow. For this, let’s rethink our game\nstates. Now we have MenuState and PlayState. Both of them can switch one into another. What if\nwe introduced a PauseState, which would freeze the game and display the list of all tanks along\nwith their kills. Then MenuState would switch to PlayState, and from PlayState you would be\nable to get to PauseState.

\n\n

Let’s begin by implementing ScoreDisplay, that would print a sorted list of tank kills along with\ntheir names.

\n\n

12-stats/entities/score_display.rb

\n\n

 1 class ScoreDisplay\n 2   def initialize(object_pool)\n 3     tanks = object_pool.objects.select do |o|\n 4       o.class == Tank\n 5     end\n 6     stats = tanks.map(&:input).map(&:stats)\n 7     stats.sort! do |stat1, stat2|\n 8       stat2.kills <=> stat1.kills\n 9     end\n10     create_stats_image(stats)\n11   end\n12 \n13   def create_stats_image(stats)\n14     text = stats.map do |stat|\n15       \"#{stat.kills}: #{stat.name} \"\n16     end.join(\"\\n\")\n17     @stats_image = Gosu::Image.from_text(\n18       $window, text, Utils.main_font, 30)\n19   end\n20 \n21   def draw\n22     @stats_image.draw(\n23       $window.width / 2 - @stats_image.width / 2,\n24       $window.height / 4 + 30,\n25       1000)\n26   end\n27 end\n

\n\n

We will have to initialize ScoreDisplay every time when we want to show the updated score. Time\nto create the PauseState that would show the score.

\n\n

12-stats/game_states/pause_state.rb

\n\n

 1 require 'singleton'\n 2 class PauseState < GameState\n 3   include Singleton\n 4   attr_accessor :play_state\n 5 \n 6   def initialize\n 7     @message = Gosu::Image.from_text(\n 8       $window, \"Game Paused\",\n 9       Utils.title_font, 60)\n10   end\n11 \n12   def enter\n13     music.play(true)\n14     music.volume = 1\n15     @score_display = ScoreDisplay.new(@play_state.object_pool)\n16     @mouse_coords = [$window.mouse_x, $window.mouse_y]\n17   end\n18 \n19   def leave\n20     music.volume = 0\n21     music.stop\n22     $window.mouse_x, $window.mouse_y = @mouse_coords\n23   end\n24 \n25   def music\n26     @@music ||= Gosu::Song.new(\n27       $window, Utils.media_path('menu_music.mp3'))\n28   end\n29 \n30   def draw\n31     @play_state.draw\n32     @message.draw(\n33       $window.width / 2 - @message.width / 2,\n34       $window.height / 4 - @message.height,\n35       1000)\n36     @score_display.draw\n37   end\n38 \n39   def button_down(id)\n40     $window.close if id == Gosu::KbQ\n41     if id == Gosu::KbC && @play_state\n42       GameState.switch(@play_state)\n43     end\n44     if id == Gosu::KbEscape\n45       GameState.switch(@play_state)\n46     end\n47   end\n48 end\n

\n\n

You will notice that PauseState invokes PlayState#draw, but without PlayState#update this\nwill be a still image. We make sure we hide the crosshair and restore previous mouse location when\nresuming play state. That way player would not be able to cheat by pausing the game, targeting the\ntank while nothing moves and then unpausing ready to deal damage. Our HUD had attr_accessor\n:active exactly for this reason, but we need to switch it on and off in PlayState#enter and\nPlayState#leave.

\n\n

class PlayState < GameState\n  # ...\n  def button_down(id)\n    # ...\n    if id == Gosu::KbEscape\n      pause = PauseState.instance\n      pause.play_state = self\n      GameState.switch(pause)\n    end\n    # ...\n  end\n  # ...\n  def leave\n    StereoSample.stop_all\n    @hud.active = false\n  end\n\n  def enter\n    @hud.active = true\n  end\n  # ...\nend\n

\n\n

Time for a test drive.

\n\n

\n $\"Pausing$

Pausing the game to see the score

\n\n

For now, scoring most kills is relatively simple. This should change when we will tell enemy AI\nto collect powerups when appropriate.

\n\n

Building Advanced AI

\n\n

The AI we have right now can kick some ass, but it is too dumb for any seasoned gamer to compete\nwith. This is the list of current flaws:

\n\n

It does not navigate well, gets stuck among trees or somewhere near water.
It is not aware of powerups.
It could do better job at shooting.
It’s field of vision is too small, compared to player’s, who is equipped with radar.

We will tackle these issues in current chapter.

\n\n\n\n

Tanks shouldn’t behave like Roombas, randomly driving around and bumping into things. They could be\nnavigating like this:

\n\n

Consult with current AI state and find or update destination point.
If destination has changed, calculate shortest path to destination.
Move along the calculated path.
Repeat.

If this looks easy, let me assure you, it would probably require rewriting the majority of AI and\nMap code we have at this point, and it is pretty tricky to implement with procedurally generated\nmaps, because normally you would use a map editor to set up waypoints, navigation mesh or other\nhints for AI so it doesn’t get stuck. Sometimes it is better to have something working imperfectly\nover a perfect solution that never happens, thus we will use simple things that will make as much\nimpact as possible without rewriting half of the code.

\n\n

Generating Friendlier Maps

\n\n

One of main reasons why tanks get stuck is bad placement of spawn points. They don’t take trees and\nboxes into account, so enemy tank can spawn in the middle of a forest, with no chance of getting\nout without blowing things up. A simple fix would be to consult with ObjectPool before placing a\nspawn point only where there are no other game objects around in, say, 150 pixel radius:

\n\n

class Map\n  # ...\n  def find_spawn_point\n    while true\n      x = rand(0..MAP_WIDTH * TILE_SIZE)\n      y = rand(0..MAP_HEIGHT * TILE_SIZE)\n      if can_move_to?(x, y) &&\n          @object_pool.nearby_point(x, y, 150).empty?\n        return [x, y]\n      end\n    end\n  end\n  # ...\nend\n

\n\n

How about powerups? They can also spawn in the middle of a forest, and while tanks are not seeking\nthem yet, we will be implementing this behavior, and leading tanks into wilderness of trees is not\nthe best idea ever. Let’s fix it too:

\n\n

class Map\n  # ...\n  def generate_powerups\n    pups = 0\n    target_pups = rand(20..30)\n    while pups < target_pups do\n      x = rand(0..MAP_WIDTH * TILE_SIZE)\n      y = rand(0..MAP_HEIGHT * TILE_SIZE)\n      if tile_at(x, y) != @water &&\n          @object_pool.nearby_point(x, y, 150).empty?\n        random_powerup.new(@object_pool, x, y)\n        pups += 1\n      end\n    end\n  end\n  # ...\nend\n

\n\n

We could also reduce tree count, but that would make the map look worse, so we are going to keep\nthis in our pocket as a mean of last resort.

\n\n

Implementing Demo State To Observe AI

\n\n

Probably the best way to figure out if our AI is any good is to target one of AI tanks with our\ngame camera and see how it plays. It will give us a great visual testing tool that will allow\ntweaking AI settings and seeing if they perform better or worse. For that we will introduce\nDemoState where only AI tanks will be present in the map, and we will be able to switch camera\nfrom one tank to another.

\n\n

DemoState is very similar to PlayState, the main difference is that there is no player. We will\nextract create_tanks method that will be overridden in DemoState.

\n\n

class PlayState < GameState\n  attr_accessor :update_interval, :object_pool, :tank\n\n  def initialize\n    # ...\n    @camera = Camera.new\n    @object_pool.camera = @camera\n    create_tanks(4)\n  end\n  # ...\n  private\n\n  def create_tanks(amount)\n    @map.spawn_points(amount * 3)\n    @tank = Tank.new(@object_pool,\n      PlayerInput.new('Player', @camera, @object_pool))\n    amount.times do |i|\n      Tank.new(@object_pool, AiInput.new(\n        @names.random, @object_pool))\n    end\n    @camera.target = @tank\n    @hud = HUD.new(@object_pool, @tank)\n  end\n  # ...\nend\n

\n\n

We will also want to display a smaller version of score in top-right corner of the screen, so let’s\nadd some adjustments to ScoreDisplay:

\n\n

class ScoreDisplay\n  def initialize(object_pool, font_size=30)\n    @font_size = font_size\n    # ...\n  end\n\n  def create_stats_image(stats)\n    # ...\n    @stats_image = Gosu::Image.from_text(\n      $window, text, Utils.main_font, @font_size)\n  end\n  # ...\n  def draw_top_right\n    @stats_image.draw(\n      $window.width - @stats_image.width - 20,\n      20,\n      1000)\n  end\nend\n

\n\n

And here is the extended DemoState:

\n\n

13-advanced-ai/game_states/demo_state.rb

\n\n

 1 class DemoState < PlayState\n 2   attr_accessor :tank\n 3 \n 4   def enter\n 5     # Prevent reactivating HUD\n 6   end\n 7 \n 8   def update\n 9     super\n10     @score_display = ScoreDisplay.new(\n11       object_pool, 20)\n12   end\n13 \n14   def draw\n15     super\n16     @score_display.draw_top_right\n17   end\n18 \n19   def button_down(id)\n20     super\n21     if id == Gosu::KbSpace\n22       target_tank = @tanks.reject do |t|\n23         t == @camera.target\n24       end.sample\n25       switch_to_tank(target_tank)\n26     end\n27   end\n28 \n29   private\n30 \n31   def create_tanks(amount)\n32     @map.spawn_points(amount * 3)\n33     @tanks = []\n34     amount.times do |i|\n35       @tanks << Tank.new(@object_pool, AiInput.new(\n36         @names.random, @object_pool))\n37     end\n38     target_tank = @tanks.sample\n39     @hud = HUD.new(@object_pool, target_tank)\n40     @hud.active = false\n41     switch_to_tank(target_tank)\n42   end\n43 \n44   def switch_to_tank(tank)\n45     @camera.target = tank\n46     @hud.player = tank\n47     self.tank = tank\n48   end\n49 end\n

\n\n

To have a possibility to enter DemoState, we need to change MenuState a little:

\n\n

class MenuState < GameState\n  # ...\n  def update\n    text = \"Q: Quit\\nN: New Game\\nD: Demo\"\n    # ...\n  end\n  # ...\n  def button_down(id)\n    # ...\n    if id == Gosu::KbD\n      @play_state = DemoState.new\n      GameState.switch(@play_state)\n    end\n  end\nend\n

\n\n

Now, main menu has the option to enter demo state:

\n\n

\n $\"Overhauled$

Overhauled main menu

\n\n

\n $\"Observing$

Observing AI in demo state

\n\n

Visual AI Debugging

\n\n

After watching AI behavior in demo mode for a while, I was terrified. When playing game normally,\nyou usually see tanks in “fighting” state, which works pretty well, but when tanks go roaming, it’s\na complete disaster. They get stuck easily, they don’t go too far from the original location, they\nwait too much.

\n\n

Some things could be improved just by changing wait_time, turn_time and drive_time to\ndifferent values, but we certainly have to do bigger changes than that.

\n\n

On the other hand, “observe AI in action, tweak, repeat” cycle proved to be very effective, I will\ndefinitely use this technique in all my future games.

\n\n

To make visual debugging easier, build yourself some tooling. One way to do it is to have global\n$debug variable which you can toggle by pressing some button:

\n\n

class PlayState < GameState\n  # ...\n  def button_down(id)\n    # ...\n    if id == Gosu::KbF1\n      $debug = !$debug\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

Then add extra drawing instructions to your objects and their components. For example, this will\nmake Tank display it’s current TankMotionState implementation class beneath it:

\n\n

class TankMotionFSM\n  # ...\n  def set_state(state)\n    # ...\n    if $debug\n      @image = Gosu::Image.from_text(\n          $window, state.class.to_s,\n          Gosu.default_font_name, 18)\n    end\n  end\n  # ...\n  def draw(viewport)\n    if $debug\n      @image && @image.draw(\n        @object.x - @image.width / 2,\n        @object.y + @object.graphics.height / 2 -\n        @image.height, 100)\n    end\n  end\n  # ...\nend\n

\n\n

To mark tank’s desired gun angle as blue line and actual gun angle as red line, you can do this:

\n\n

class AiGun\n  # ...\n  def draw(viewport)\n    if $debug\n      color = Gosu::Color::BLUE\n      x, y = @object.x, @object.y\n      t_x, t_y = Utils.point_at_distance(x, y, @desired_gun_angle,\n                                         BulletPhysics::MAX_DIST)\n      $window.draw_line(x, y, color, t_x, t_y, color, 1001)\n      color = Gosu::Color::RED\n      t_x, t_y = Utils.point_at_distance(x, y, @object.gun_angle,\n                                         BulletPhysics::MAX_DIST)\n      $window.draw_line(x, y, color, t_x, t_y, color, 1000)\n    end\n  end\n  # ...\nend\n

\n\n

Finally, you can automatically mark collision box corners on your graphics components. Let’s take\nBoxGraphics for example:

\n\n

# 13-advanced-ai/misc/utils.rb\nmodule Utils\n  # ...\n  def self.mark_corners(box)\n    i = 0\n    box.each_slice(2) do |x, y|\n      color = DEBUG_COLORS[i]\n      $window.draw_triangle(\n        x - 3, y - 3, color,\n        x,     y,     color,\n        x + 3, y - 3, color,\n        100)\n      i = (i + 1) % 4\n    end\n  end\n  # ...\nend\n\n# 13-advanced-ai/entities/components/box_graphics.rb\nclass BoxGraphics < Component\n  # ..\n  def draw(viewport)\n    @box.draw_rot(x, y, 0, object.angle)\n    Utils.mark_corners(object.box) if $debug\n  end\n  # ...\nend\n

\n\n

As a developer, you can make yourself see nearly everything you want, make use of it.

\n\n

\n $\"Visual$

Visual debugging of AI behavior

\n\n

Although it hurts the framerate a little, it is very useful when building not only AI, but the\nrest of the game too. Using this visual debugging together with Demo mode, you can tweak all the AI\nvalues to make it shoot more often, fight better, and be more agile. We won’t go through this\nminor tuning, but you can find the changes by viewing changes introduced in 13-advanced-ai.

\n\n

Making AI Collect Powerups

\n\n

To even out the odds, we have to make AI seek powerups when they are required. The logic behind it\ncan be implemented using a couple of simple steps:

\n\n

AI would know what powerups are currently needed. This may vary from state to state, i.e. speed\nand fire rate powerups are nice to have when roaming, but not that important when fleeing after\ntaking heavy damage. And we don’t want AI to waste time and collect speed powerups when speed\nmodifier is already maxed out.
\nAiVision would return closest visible powerup, filtered by acceptable powerup types.
Some TankMotionState implementation would adjust tank direction towards closest visible\npowerup in change_direction method.

Finding Powerups In Sight

\n\n

To implement changes in AiVision, we will introduce closest_powerup method. It will query\nobjects in sight and filter them out by their class and distance.

\n\n

class AiVision\n  # ...\n  POWERUP_CACHE_TIMEOUT = 50\n  # ...\n  def closest_powerup(*suitable)\n    now = Gosu.milliseconds\n    @closest_powerup = nil\n    if now - (@powerup_cache_updated_at ||= 0) > POWERUP_CACHE_TIMEOUT\n      @closest_powerup = nil\n      @powerup_cache_updated_at = now\n    end\n    @closest_powerup ||= find_closest_powerup(*suitable)\n  end\n\n  private\n\n  def find_closest_powerup(*suitable)\n    if suitable.empty?\n      suitable = [FireRatePowerup,\n                  HealthPowerup,\n                  RepairPowerup,\n                  TankSpeedPowerup]\n    end\n    @in_sight.select do |o|\n      suitable.include?(o.class)\n    end.sort do |a, b|\n      x, y = @viewer.x, @viewer.y\n      d1 = Utils.distance_between(x, y, a.x, a.y)\n      d2 = Utils.distance_between(x, y, b.x, b.y)\n      d1 <=> d2\n    end.first\n  end\n  # ...\nend\n

\n\n

It is very similar to AiVision#closest_tank, and parts should probably be extracted to keep the\ncode dry, but we will not bother.

\n\n

Seeking Powerups While Roaming

\n\n

Roaming is when most picking should happen, because Tank sees no enemies in sight and needs to\nprepare for upcoming battles. Let’s see how can we implement this behavior while leveraging the\nnewly made AiVision#closest_powerup:

\n\n

class TankRoamingState < TankMotionState\n  # ...\n  def required_powerups\n    required = []\n    health = @object.health.health\n    if @object.fire_rate_modifier < 2 && health > 50\n      required << FireRatePowerup\n    end\n    if @object.speed_modifier < 1.5 && health > 50\n      required << TankSpeedPowerup\n    end\n    if health < 100\n      required << RepairPowerup\n    end\n    if health < 190\n      required << HealthPowerup\n    end\n    required\n  end\n\n  def change_direction\n    closest_powerup = @vision.closest_powerup(\n      *required_powerups)\n    if closest_powerup\n      @seeking_powerup = true\n      angle = Utils.angle_between(\n        @object.x, @object.y,\n        closest_powerup.x, closest_powerup.y)\n      @object.physics.change_direction(\n        angle - angle % 45)\n    else\n      @seeking_powerup = false\n      # ... choose random direction\n    end\n    @changed_direction_at = Gosu.milliseconds\n    @will_keep_direction_for = turn_time\n  end\n  # ...\n  def turn_time\n    if @seeking_powerup\n      rand(100..300)\n    else\n      rand(1000..3000)\n    end\n  end\nend\n

\n\n

It is simple as that, and our AI tanks are now getting buffed on their spare time.

\n\n

Seeking Health Powerups After Heavy Damage

\n\n

To seek health when damaged, we need to change TankFleeingState#change_direction:

\n\n

class TankFleeingState < TankMotionState\n  # ...\n  def change_direction\n    closest_powerup = @vision.closest_powerup(\n      RepairPowerup, HealthPowerup)\n    if closest_powerup\n      angle = Utils.angle_between(\n        @object.x, @object.y,\n        closest_powerup.x, closest_powerup.y)\n      @object.physics.change_direction(\n        angle - angle % 45)\n    else\n      # ... reverse from enemy\n    end\n    @changed_direction_at = Gosu.milliseconds\n    @will_keep_direction_for = turn_time\n  end\n  # ...\nend\n

\n\n

This small change tells AI to pick up health while fleeing. The interesting part is that when tank\npicks up RepairPowerup, it’s health gets fully restored and AI should switch back to\nTankFightingState. This simple thing is a major improvement in AI behavior.

\n\n

Evading Collisions And Getting Unstuck

\n\n

While observing AI navigation, it was noticeable that tanks often got stuck, even in simple\nsituations, like driving into a tree and hitting it repeatedly for a dozen of seconds. To reduce\nthe number of such occasions, we will introduce TankNavigatingState, which would help avoid\ncollisions, and TankStuckState, which would be responsible for driving out of dead ends as\nquickly as possible.

\n\n

To implement these states, we need to have a way to tell if tank can go forward and a way of\ngetting a direction which is not blocked by other objects. Let’s add a couple of methods to\nAiVision:

\n\n

class AiVision\n  # ...\n  def can_go_forward?\n    in_front = Utils.point_at_distance(\n      *@viewer.location, @viewer.direction, 40)\n    @object_pool.map.can_move_to?(*in_front) &&\n      @object_pool.nearby_point(*in_front, 40, @viewer)\n        .reject { |o| o.is_a? Powerup }.empty?\n  end\n\n  def closest_free_path(away_from = nil)\n    paths = []\n    5.times do |i|\n      if paths.any?\n        return farthest_from(paths, away_from)\n      end\n      radius = 55 - i * 5\n      range_x = range_y = [-radius, 0, radius]\n      range_x.shuffle.each do |x|\n        range_y.shuffle.each do |y|\n          x = @viewer.x + x\n          y = @viewer.y + y\n          if @object_pool.map.can_move_to?(x, y) &&\n              @object_pool.nearby_point(x, y, radius, @viewer)\n                .reject { |o| o.is_a? Powerup }.empty?\n            if away_from\n              paths << [x, y]\n            else\n              return [x, y]\n            end\n          end\n        end\n      end\n    end\n    false\n  end\n\n  alias :closest_free_path_away_from :closest_free_path\n  # ...\n  private\n\n  def farthest_from(paths, away_from)\n    paths.sort do |p1, p2|\n      Utils.distance_between(*p1, *away_from) <=>\n        Utils.distance_between(*p2, *away_from)\n    end.first\n  end\n  # ...\nend\n

\n\n

AiVision#can_go_forward? tells if tank can move ahead, and AiVision#closest_free_path finds a\npoint where tank can move without obstacles. You can also call\nAiVision#closest_free_path_away_from and provide coordinates you are trying to get away from.

\n\n

We will use closest_free_path methods in newly implemented tank motion states, and\ncan_go_forward? in TankMotionFSM, to make a decision when to jump into navigating or stuck\nstate.

\n\n

Those new states are nothing fancy:

\n\n

13-advanced-ai/entities/components/ai/tank_navigating_state.rb

\n\n

 1 class TankNavigatingState < TankMotionState\n 2   def initialize(object, vision)\n 3     @object = object\n 4     @vision = vision\n 5   end\n 6 \n 7   def update\n 8     change_direction if should_change_direction?\n 9     drive\n10   end\n11 \n12   def change_direction\n13     closest_free_path = @vision.closest_free_path\n14     if closest_free_path\n15       @object.physics.change_direction(\n16         Utils.angle_between(\n17           @object.x, @object.y, *closest_free_path))\n18     end\n19     @changed_direction_at = Gosu.milliseconds\n20     @will_keep_direction_for = turn_time\n21   end\n22 \n23   def wait_time\n24     rand(10..100)\n25   end\n26 \n27   def drive_time\n28     rand(1000..2000)\n29   end\n30 \n31   def turn_time\n32     rand(300..1000)\n33   end\n34 end\n

\n\n

TankNavigatingState simply chooses a random free path, changes direction to it and keeps driving.

\n\n

13-advanced-ai/entities/components/ai/tank_stuck_state.rb

\n\n

 1 class TankNavigatingState < TankMotionState\n 2   def initialize(object, vision)\n 3     @object = object\n 4     @vision = vision\n 5   end\n 6 \n 7   def update\n 8     change_direction if should_change_direction?\n 9     drive\n10   end\n11 \n12   def change_direction\n13     closest_free_path = @vision.closest_free_path\n14     if closest_free_path\n15       @object.physics.change_direction(\n16         Utils.angle_between(\n17           @object.x, @object.y, *closest_free_path))\n18     end\n19     @changed_direction_at = Gosu.milliseconds\n20     @will_keep_direction_for = turn_time\n21   end\n22 \n23   def wait_time\n24     rand(10..100)\n25   end\n26 \n27   def drive_time\n28     rand(1000..2000)\n29   end\n30 \n31   def turn_time\n32     rand(300..1000)\n33   end\n34 end\n

\n\n

TankStuckState is nearly the same, but it keeps driving away from @stuck_at point, which is set\nby TankMotionFSM upon transition to this state.

\n\n

class TankMotionFSM\n  STATE_CHANGE_DELAY = 500\n  LOCATION_CHECK_DELAY = 5000\n\n  def initialize(object, vision, gun)\n    # ...\n    @stuck_state = TankStuckState.new(object, vision, gun)\n    @navigating_state = TankNavigatingState.new(object, vision)\n    set_state(@roaming_state)\n  end\n  # ...\n  def choose_state\n    unless @vision.can_go_forward?\n      unless @current_state == @stuck_state\n        set_state(@navigating_state)\n      end\n    end\n    # Keep unstucking itself for a while\n    change_delay = STATE_CHANGE_DELAY\n    if @current_state == @stuck_state\n      change_delay *= 5\n    end\n    now = Gosu.milliseconds\n    return unless now - @last_state_change > change_delay\n    if @last_location_update.nil?\n      @last_location_update = now\n      @last_location = @object.location\n    end\n    if now - @last_location_update > LOCATION_CHECK_DELAY\n      puts \"checkin location\"\n      unless @last_location.nil? || @current_state.waiting?\n        if Utils.distance_between(*@last_location, *@object.location) < 20\n          set_state(@stuck_state)\n          @stuck_state.stuck_at = @object.location\n          return\n        end\n      end\n      @last_location_update = now\n      @last_location = @object.location\n    end\n    # ...\n  end\n  # ...\nend\n

\n\n

What this does is automatically change state to navigating when tank is about to hit an obstacle.\nIt also tracks tank location, and if tank hasn’t moved 20 pixels away from it’s original direction\nfor 5 seconds, it enters TankStuckState, which deliberately tries to navigate away from the\nstock_at spot.

\n\n

AI navigation has just got significantly better, and it didn’t take that many changes.

\n\n

Wrapping It Up

\n\n

Our journey into the world of game development has come to an end. We have learned enough to\nproduced a playable game, yet only scratched the surface. Writing this book was a very\nenlightening experience, and hopefully reading it inspired or helped someone to get a start.

\n\n

Lessons Learned

\n\n

Building this small tanks game and learning about game development with Ruby certainly had some\nnasty bumps along the way, some of them made my head hit the ceiling.

\n\n

Ruby Is Slow

\n\n

This shouldn’t be a shocker, because Ruby is a dynamic, interpreted language, but how exactly slow\nit is at some points was a staggering discovery. Probably the best evidence is that drawing map\ntiles off screen using native extensions was actually faster than doing Camera#can_view? checks\nthat involve simple integer arithmetic and range checks.

\n\n

If your game is going to deal with large number of entities, Ruby will start letting you down.\nDreaming about going pro? Go for C++, you won’t make a mistake here.

\n\n

Knowing this, keep in mind that Ruby is a wonderful language, that has it’s own strengths. It’s\ngreat for prototyping and dynamic things. Some 5-10 lines of Ruby could translate into 50-100 lines\nof C++. Also, knowing multiple languages makes you a better developer.

\n\n

Packaging Ruby Games Sucks

\n\n

Unless you are releasing your game for tech savvy guys who can gem install it, get ready to go\nthrough hell. There is no nice and easy way to create a\nstandalone executable application from Ruby code that involves native extensions. And you will go\nthrough hell once for every operating system you want to publish your game for.

\n\n

That’s not everything. Want to use the\nlatest Ruby version? Check if you can make a package for it in your target OS before you start\ncoding. Thinking of using something that relies on ImageMagick? Too bad, you probably won’t be able\nto package the game into a native standalone app, at least on OSX. If you are planning on releasing\nthe game, package early and package often, for every OS, and check if there will be no problems\nwith native extensions.

\n\n

Plan Networked Multiplayer Early

\n\n

If you are going to build a game, don’t make a mistake of thinking “I’ll just make it multiplayer\nlater”, start at the very beginning. This was a lesson I learned the hard way. There had to be a\nchapter in this book about turning Tanks into multiplayer, but it didn’t happen, because it would\nrequire a major rewrite of the code.

\n\n

Creating A Well Polished Game Requires Extraordinary Effort

\n\n

Hacking up a rough prototype is extremely fun. You get to build an engine, wire everything\ntogether. It definitely gives a sense of achievement. Turning it into a great game, however, is a\ndifferent story. You can spend hours or even days tweaking how game controls work and still remain\nunsatisfied. Every tiny detail can be pushed further. Prefer quality over quantity, and remember\nthat you probably cannot afford both and actually finish it within next couple of years.

\n\n

Start Small, Take Baby Steps

\n\n

Your first few games should be small experiments, prototypes or demos. Don’t attempt to build a\ngame you wanted to build forever with your first shot. Try reimplementing Tetris, Pacman or\nBejeweled instead. You will find it to be challenging enough, and when you will feel you have the\nskills to do something bigger, practice just a little more.

\n\n

Don’t Reinvent The Wheel

\n\n

Before doing anything, research. You will probably not get point in poly collision detection better\nthan W. Randolph Franklin did it in his research.\nEven if you think you can do it on your own, learn what others discovered before you. Learn from\nother’s mistakes, not your own.

\n\n

Special Thanks

\n\n

I would like to thank Julian Raschke for creating and maintaining\nGosu and for all the help on IRC, Gosu forums and GitHub. This book\nwould not exist without your enormous contribution to Ruby game development scene.

\n\n

Shout out goes to Shawn Anderson, creator of\nGamebox. Thank you for moral support and encouragement.\nStudying Gamebox source code taught me many things about Gosu and game development.

\n\n

You can find Julian, Shawn and more game development enthusiasts in #gosu on\nFreeNode.

\n\n

And most importantly, thank you for reading this book!

\n\n","tocStructure",[469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577],{"_75":76,"_42":77,"_69":-5,"_78":79,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":85,"_69":-5,"_78":86,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":89,"_69":-5,"_78":90,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":93,"_69":-5,"_78":94,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":98,"_69":-5,"_78":99,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":103,"_69":-5,"_78":104,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":106,"_69":-5,"_78":107,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":109,"_69":-5,"_78":110,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":113,"_69":-5,"_78":114,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":116,"_69":-5,"_78":117,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":120,"_69":-5,"_78":121,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":124,"_69":-5,"_78":125,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":128,"_69":-5,"_78":129,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":131,"_69":-5,"_78":132,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":134,"_69":-5,"_78":135,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":137,"_69":-5,"_78":138,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":140,"_69":-5,"_78":141,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":143,"_69":-5,"_78":144,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":146,"_69":-5,"_78":147,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":150,"_69":-5,"_78":151,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":153,"_69":-5,"_78":154,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":156,"_69":-5,"_78":157,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":159,"_69":-5,"_78":160,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":162,"_69":-5,"_78":163,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":165,"_69":-5,"_78":166,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":168,"_69":-5,"_78":169,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":171,"_69":-5,"_78":172,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":174,"_69":-5,"_78":175,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":178,"_69":-5,"_78":179,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":181,"_69":-5,"_78":182,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":184,"_69":-5,"_78":185,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":187,"_69":-5,"_78":188,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":190,"_69":-5,"_78":191,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":193,"_69":-5,"_78":194,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":196,"_69":-5,"_78":197,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":199,"_69":-5,"_78":200,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":202,"_69":-5,"_78":203,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":206,"_69":-5,"_78":207,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":209,"_69":-5,"_78":210,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":212,"_69":-5,"_78":213,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":215,"_69":-5,"_78":216,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":218,"_69":-5,"_78":219,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":221,"_69":-5,"_78":222,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":224,"_69":-5,"_78":225,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":228,"_69":-5,"_78":229,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":231,"_69":-5,"_78":232,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":234,"_69":-5,"_78":235,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":237,"_69":-5,"_78":238,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":241,"_69":-5,"_78":242,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":244,"_69":-5,"_78":245,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":247,"_69":-5,"_78":248,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":250,"_69":-5,"_78":251,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":253,"_69":-5,"_78":254,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":256,"_69":-5,"_78":257,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":260,"_69":-5,"_78":261,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":263,"_69":-5,"_78":264,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":266,"_69":-5,"_78":267,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":270,"_69":-5,"_78":271,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":273,"_69":-5,"_78":274,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":276,"_69":-5,"_78":277,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":279,"_69":-5,"_78":280,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":282,"_69":-5,"_78":283,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":285,"_69":-5,"_78":286,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":288,"_69":-5,"_78":289,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":292,"_69":-5,"_78":293,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":295,"_69":-5,"_78":296,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":298,"_69":-5,"_78":299,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":301,"_69":-5,"_78":302,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":304,"_69":-5,"_78":305,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":307,"_69":-5,"_78":308,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":310,"_69":-5,"_78":311,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":313,"_69":-5,"_78":314,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":316,"_69":-5,"_78":317,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":319,"_69":-5,"_78":320,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":322,"_69":-5,"_78":323,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":325,"_69":-5,"_78":326,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":329,"_69":-5,"_78":330,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":332,"_69":-5,"_78":333,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":335,"_69":-5,"_78":336,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":338,"_69":-5,"_78":339,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":341,"_69":-5,"_78":342,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":345,"_69":-5,"_78":346,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":348,"_69":-5,"_78":349,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":351,"_69":-5,"_78":352,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":354,"_69":-5,"_78":355,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":357,"_69":-5,"_78":358,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":360,"_69":-5,"_78":361,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":363,"_69":-5,"_78":364,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":366,"_69":-5,"_78":367,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":369,"_69":-5,"_78":370,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":372,"_69":-5,"_78":373,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":376,"_69":-5,"_78":377,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":379,"_69":-5,"_78":380,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":382,"_69":-5,"_78":383,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":385,"_69":-5,"_78":386,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":389,"_69":-5,"_78":390,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":392,"_69":-5,"_78":393,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":395,"_69":-5,"_78":396,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":398,"_69":-5,"_78":399,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":401,"_69":-5,"_78":402,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":405,"_69":-5,"_78":406,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":408,"_69":-5,"_78":409,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":411,"_69":-5,"_78":412,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":414,"_69":-5,"_78":415,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":417,"_69":-5,"_78":418,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":420,"_69":-5,"_78":421,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":423,"_69":-5,"_78":424,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":97,"_42":427,"_69":-5,"_78":428,"_71":80,"_100":-5,"_101":-5,"_83":-5},{"_75":76,"_42":430,"_69":-5,"_78":431,"_71":80,"_100":-5,"_101":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Getting The Sample Code

Table of Contents

A Boy Who Wanted To Create Worlds

Why Ruby?

What You Should Know Before Reading This Book

What Are We Going To Build?

Graphics

Game Development Library

Theme And Mechanics

Preparing The Tools

Getting Gosu to run on Mac Os X

Getting The Sample Code

Other Tools

Gosu Basics

Hello World

Screen Coordinates And Depth

Main Loop

Moving Things With Keyboard

Images And Animation

Music And Sound

Warming Up

Using Tilesets

Integrating With Texture Packer

Combining Tiles Into A Map

Using Tiled To Create Maps

Loading Tiled Maps With Gosu

Generating Random Map With Perlin Noise

Player Movement With Keyboard And Mouse

Game Coordinate System

Game Coordinates

Viewport Coordinates

Screen Coordinates

How To Put It All Together

Prototyping The Game

Switching Between Game States

Implementing Menu State

Implementing Play State

Implementing World Map

Implementing Floating Camera

Implementing The Tank

Implementing Bullets And Explosions

Running The Prototype

Optimizing Game Performance

Profiling Ruby Code To Find Bottlenecks

Advanced Profiling Techniques

Optimizing Inefficient Code

Profiling On Demand

Adjusting Game Speed For Variable Performance

Frame Skipping

Refactoring The Prototype

Game Programming Patterns

What Is Wrong With Current Design

Decoupling Using Component Pattern

Refactoring Explosion

Refactoring Bullet

Refactoring Tank

Refactoring PlayState

Other Improvements

Simulating Physics

Adding Enemy Objects

Adding Bounding Boxes And Detecting Collisions

Catching Bullets

Implementing Turn Speed Penalties

Implementing Terrain Speed Penalties

Implementing Health And Damage

Adding Health Component

Inflicting Damage With Bullets

Creating Artificial Intelligence

Designing AI Using Finite State Machine

Implementing AI Vision

Controlling Tank Gun

Implementing AI Input

Implementing Tank Motion States

Tank Roaming State

Tank Fighting State

Tank Chasing State

Tank Fleeing State

Wiring Tank Motion States Into Finite State Machine

Making The Prototype Playable

Drawing Water Beyond Map Boundaries