Bonderblog @ BruceOnder.com

Bonderblog @ BruceOnder.com

Bruce Onder  //  

Archive for

September 2010

Sep 22 / 10:37am

Some Indie Game Developer podcasts for you

If you're an indie game developer, or you are just interested in the indie game development scene, here are a couple great podcasts for you to check out:

http://www.gamedevradio.net/

Joseph Burchett puts together this podcast, wherein he interviews game developers, tool vendors, and other crazy people you should know more about.  Of particular note is the two-parter on Flash Game Design featuring a panel of developers who bring very different yet successful mindsets to game development.

http://www.indiegamepod.com/

This podcast by Action covers lots of "quick hit" interviews, most recently at the Casual Connect conference here in Seattle.  Blog articles often add further depth to the episodes.

What indie game dev podcasts do you listen to?

Sep 11 / 9:20pm

Article: Zynga’s Platinum Purchase Program Does Exist, Used Mostly for Internationals

Zynga’s Platinum Purchase Program Does Exist, Used Mostly for Internationals
http://www.insidesocialgames.com/2010/09/10/zyngas-platinum-purchase-program/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+InsideSocialGames+%28Inside+Social+Games%29

Details on a secret Zynga payment option emerged today via Gawker. Zynga’s “Platinum Purchase Program” is a private discount deal on virtual currency, according to an email reproduced on the site, limited to members willing to spend over $500 in a single transaction.

(via Instapaper)

This was a fascinating report on a "secret" program Zynga runs in support of overseas whales. 

I can't help but admire this - and I wonder: does publicizing this program legitimize spending to the free players?
Sep 9 / 2:58pm

Rocket Engine

Media_httprocketpackf_qekws

Rocket Engine is another cool-looking Javascript game development library with a lot of polish to it. Check out the video at the site's home page, where they show off their game editor that lets them build major portions of a game without a single line of code.

I'm getting on their notification list. Are you?

Sep 9 / 11:53am

Triple Windsor: I am a pivotal tracker project

This is a project for tracking myself. The things I should do, don't do, wish I did, etc.

"Bugs" are things that I don't like that I aim to change. They can be given by anyone at "failin.gs" email, or submitted in person. (nailbiting and the like)

"Chores" are things that I need to do that don't add business value directly. (unimportant meetings, cleaning the gutters)

"Features" are things that do add business value, ie. things that I enjoy, improve my skills, and benefit my relationships with others.

I found this fascinating blog article on treating oneself as a software project. Last summer I tried using a kanban board as a personal project management system, but I got bogged down in weird little details that kept making the board either ineffective or stale.

For example, I would put different kinds of things on there: "call Jeff about Frankenstein's Ford" would be on the board right along with "Clean driveway" and "Write blog post".

I had queue limits on the various states these items could exist in. So "Call Jeff" could sit around in "WIP" (work in progress) if I had called and left a message.

Which meant that either that card was slowing down throughput of other items (since I could only have 2 cards in that status at a time), or I had to invent some sort of waiting queue in order to let other things move forward (another thing to manage).

I have put the "personal kanban board" on hold, but might consider dusting it off again if I can think of a few experiments to run to make it work.

Anyway, please give Evan's article a read and let me know what you think about managing yourself as a software project!

Filed under  //  personal development   project management  
Sep 6 / 10:14pm

A Great Article from Kanban Chronicle

I just read a great article on an agile team's usage of a whiteboard to manage their one-piece flow via queues.  I have been doing a substantially similar process, only using TargetProcess instead due to the distributed nature of the team.

2010-08-27

The chief takeaways:

1) Enforce your queue limits.  In this case, the team had more than two things in Pre-Dev Work In Progress (WIP), so they had to briefly "stop the line" and pull the overage back into the queue.

2) Keep the units of work small so that they can flow quickly from the start of the line to the end.   One of the things that my team and I discovered is that certain development "orders" can be carved out of pre-dev WIP early, such as screen wireframes or page composites that can be implemented while other parts are waiting.  If anything has to change, it's better to wrap up a work order with a "change order" than to sit idle for long periods of time.

3) Treat maintenance/support tickets just like new development - in other words, apply queue limits and divide the work into smaller chunks that can flow through the system more efficiently.  You might want to continue to treat these items as a separate work line (as the team in this article does), or you might force all of this work to be prioritized together.  I tend to go for a universal backlog of new dev and maintenance/support.

This blog is one to keep an eye on if you're interested in Kanban-style agile teamwork.

 

Filed under  //  agile development practices   kanban   lean   work queues  
Sep 1 / 8:41pm

Hacking Akihabara (And Why You Shouldn't)

If you are developing a game that will run inside of a frame or iframe (such as a Facebook app), then you might want to focus the canvas so that keyboard input is captured by your game.  Otherwise your player needs to click around to put the focus on the app, and that's no good.

I first fixed this by hacking gbox.js to set the canvas' tabindex attribute to 1.

This hack was made inside initScreen:

this._screen = document.createElement("canvas");
if (this._border) this._screen.style.border = "1px solid black";
this._screen.setAttribute('height', h);
this._screen.setAttribute('width', w);
this._screen.setAttribute('tabindex', 1); // <-- this is the line I added.
this._screen.style.width = (w * this._zoom) + "px";
this._screen.style.height = (h * this._zoom) + "px";
this._screenh = h;
this._screenw = w;

But, I forgot that I hacked this code, and when I upgraded Akihabara from 1.2.1 to 1.3, the hack was blown out.

So instead of hacking a third party file again, I can do the same using jQuery in my game's code:

$('canvas').attr('tabindex', '1');

This is better because I don't have to worry about new releases of Akihabara overwriting my mod. :)

Maybe this tabindex can be set inside the engine in the future.

Works great in Firefox.  Also works in Chrome, but that browser decided to color the "focus ring" around the canvas a Halloween orange color.  So that will be my next fix when I come back to it.

So:

1) Don't hack code that you can't control!

2) Use jQuery to shim your code!

3) Akihabara RULES!

 

Akihabara can be found at http://www.kesiev.com/akihabara/

 

Sep 1 / 8:37pm

Akihabara Community • Index page

Akihabara Community - http://akihabara.avocaweb.net/index.php

If you are developing games with the Akihabara javascript library, you should set up camp at the official forums!