<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Rogue Codewright</title>
  <subtitle>Technical musings of Nathan Curtis</subtitle>
  <id>http://codewright.roguenet.org/</id>
  <link href="http://codewright.roguenet.org/"/>
  <link href="http://codewright.roguenet.org/feed.xml" rel="self"/>
  <updated>2014-09-29T00:00:00Z</updated>
  <author>
    <name>Nathan Curtis</name>
  </author>
  <entry>
    <title>Command-line AIR support</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2014/09/29/air-from-script/"/>
    <id>/blog/2014/09/29/air-from-script/</id>
    <published>2014-09-29T00:00:00Z</published>
    <updated>2014-09-29T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;p&gt;Running an Actionscript project from the command-line is not something that is frequently required
(and I would certainly not recommend using Actionscript as a general scripting language), but there
are corner cases where it is occasionally useful...&lt;/p&gt;</summary>
  </entry>
  <entry>
    <title>Lessons Learned from Diablo 3</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2014/09/19/lessons-learned-d3/"/>
    <id>/blog/2014/09/19/lessons-learned-d3/</id>
    <published>2014-09-19T00:00:00Z</published>
    <updated>2014-09-19T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;h3&gt;Launching a Bad Game&lt;/h3&gt;

&lt;p class="text-center"&gt;
&lt;img alt="Banner" src="//cdn.codewright.roguenet.org/blog/2014/09/19/lessons-learned-d3/banner.jpg"&gt;
&lt;/p&gt;

&lt;p&gt;&lt;a href="http://us.battle.net/d3/en/"&gt;Diablo 3&lt;/a&gt; has had a rocky history, to say the least. The initial
release date was May 15, 2012. The first night, a horde of enthusiasts descended on the game, which
was consequently &lt;a href="http://www.vg247.com/2012/05/17/blizzard-did-not-go-far-enough-prepping-diablo-iii-servers/"&gt;completely unplayable&lt;/a&gt;
because the servers...&lt;/p&gt;</summary>
  </entry>
  <entry>
    <title>Dealing with Stage3D Error 3702</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2014/07/23/dealing-with-error-3702/"/>
    <id>/blog/2014/07/23/dealing-with-error-3702/</id>
    <published>2014-07-23T00:00:00Z</published>
    <updated>2014-07-23T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;h3&gt;The Update (2014-07-24)&lt;/h3&gt;

&lt;p&gt;Today, I updated my Starling to the latest on github, and discovered what I wish I’d known a week
ago: this solution has been in place in Starling proper for a couple of months. Still, I went to
the trouble of typing it all...&lt;/p&gt;</summary>
  </entry>
  <entry>
    <title>Google Spreadsheets for Game Configuration</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2013/09/02/google-spreadsheet-to-json/"/>
    <id>/blog/2013/09/02/google-spreadsheet-to-json/</id>
    <published>2013-09-02T00:00:00Z</published>
    <updated>2013-09-02T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;p&gt;Dynamic game configuration is always useful, and doing it cheaply and easily is especially
important for small indy studios. Setting up a
&lt;a href="https://docs.google.com/spreadsheet/"&gt;Google Spreadsheet&lt;/a&gt; with your runtime configuration data
enables easy collaborative editing, and having a process that can read that data and export
JSON makes it easy to use that data at runtime in whatever client language you find suitable. In
this article I&amp;rsquo;m using &lt;a href="https://code.google.com/p/google-gson/"&gt;Gson&lt;/a&gt; for JSON serialization, but
it wouldn&amp;rsquo;t be difficult to use &lt;a href="http://jackson.codehaus.org/"&gt;Jackson&lt;/a&gt; instead, if that&amp;rsquo;s how you
roll.&lt;/p&gt;

&lt;p&gt;</summary>
  </entry>
  <entry>
    <title>Authentication in Ember.js</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2013/07/12/ember-auth/"/>
    <id>/blog/2013/07/12/ember-auth/</id>
    <published>2013-07-12T00:00:00Z</published>
    <updated>2013-07-12T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;p&gt;This post is about authentication, but it also covers a more general topic: setting up a framework
for ajax calls that accepts errors and reacts to them appropriately. When implementing my own
&lt;a href="http://emberjs.com/"&gt;Ember&lt;/a&gt; app, I decided against &lt;a href="https://github.com/emberjs/data"&gt;ember-data&lt;/a&gt;
and &lt;a href="https://github.com/heartsentwined/ember-auth"&gt;ember-auth&lt;/a&gt; because they&amp;rsquo;re both new enough that
the rough edges were causing me more headache than good while learning my way around Ember to begin
with. I also really struggled with getting basic auth such as this working while learning Ember,
so hopefully this will be useful to a few other Ember newbies out there.&lt;/p&gt;

&lt;p&gt;This guide was written for Ember 1.0.0-rc4, and originally published in May as a
&lt;a href="https://gist.github.com/roguenet/5687827"&gt;gist&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;</summary>
  </entry>
  <entry>
    <title>Alpha hit testing in Starling</title>
    <link rel="alternate" href="http://codewright.roguenet.org/blog/2013/07/08/alpha-hit-testing/"/>
    <id>/blog/2013/07/08/alpha-hit-testing/</id>
    <published>2013-07-08T00:00:00Z</published>
    <updated>2013-07-08T00:00:00Z</updated>
    <author>
      <name>Nathan Curtis</name>
    </author>
    <summary type="html">&lt;p&gt;In &lt;a href="http://gamua.com/starling/"&gt;Starling&lt;/a&gt;&amp;rsquo;s display stack, the default behavior for
&lt;code&gt;DisplayObject.hitTest&lt;/code&gt; is to use the &lt;code&gt;DisplayObject&lt;/code&gt;&amp;rsquo;s defined bounds, and only its
defined bounds to determine if a touch hits that sprite. My current game has levels with very
tightly packed assets, resulting in severely overlapping bounding boxes. Furthermore, on mobile
devices, we have tight memory constraints, making it impractical to keep the source &lt;code&gt;BitmapData&lt;/code&gt;
for an uploaded texture in memory.&lt;/p&gt;

&lt;p&gt;&lt;p class='text-center'&gt;
&lt;img alt="Overlapping child bounds" src="//cdn.codewright.roguenet.org/blog/2013/07/08/alpha-hit-testing/overlapping.png" /&gt;
&lt;/p&gt;</summary>
  </entry>
</feed>
