• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    1212
  • comments
    1738
  • views
    1137316

About this blog

Imparting game development wisdom of dubious quality for over a decade!

Entries in this blog

johnhattan

More Windows 8 Fun

(hmm, for some reason the RSS importer from http://thecodezone.blogspot.com is borked, so I'm going the old fashioned way, with cut-n-paste)

Well at some point a couple of weeks ago the hard drive in my Main Development Box decided that booting to an OS was no longer necessary. And it chose to do so right in the middle of a deadline. So I hoofed it over to Frys to purchase a replacement drive and a copy of Windows 8. While the UI is controversial, I hadn't heard about any problems with Windows 7 apps, so I quickly installed Windows 8, my development tools, and my projects. And I was able to complete the project after a couple of very late nights.

Fast-forward a week and I finally have a chance to make Windows 8 operate the way I like. For me, Windows 8 reminds me of the last two MacOS updates in that there are some nice refinements hidden behind a treacly front-end that's designed for someone other than me. Windows 8 does have some very nice refinements that make it a better Windows 7, but that's all lost (literally) under the Metro UI.
But, much like MacOS, it's a simple to shun the stuff that annoys you and keep the stuff you like. And so here's my list of essential tools and tweaks that I found myself installing. And now that it's all installed, I'm hunky-dory with Windows again. Most of this stuff is free. If it's not, I mention it:

SharpKeys (http://sharpkeys.codeplex.com/) - A simple gizmo that sets registry entries to remap your keyboard. I remap the CAPS LOCK key to operate as a shift-key because the CAPS LOCK is a holdover from typewriters. And this thing just modifies the registry, so there's nothing to do once you're done remapping. Just remap and forget forever.

Free42 (http://thomasokken.com/free42/) - My brain thinks in RPN. The Windows calculator doesn't. The MacOS calculator does have RPN, so points to them.

MicroBin (http://www.e-sushi.net/microbin/) - Puts a tiny recycle bin in the tray so you don't have to hunt for it on the desktop whenever you wanna use the danged thing.

Win 7 Library Tool (http://www.pcworld.c...brary_tool.html) - The "Libraries" menu on the explorer sidebar is a terrific neglected feature. And for some reason Microsoft cripples it by applying some arbitrary rules as to what folders can live there. This gizmo gets around that so I can have related stuff all together. For example, I have a "cloud" library that points to my Dropbox, Google Drive, etc. so I don't have to hunt for those folders.

Cyberduck (http://cyberduck.ch/) - very nice little FTP client. There's an identical one on the Mac, and I give preference to apps that are identical on both platforms so I don't have to reconfigure my brain. Ditto for Free42.

Notepad++ (http://notepad-plus-plus.org/) - Is free. Is very fast. Is pretty-much the only text editor you need if you don't plan to mold your life around your text editor (i.e. VIM, EMACS)

ImageMagick (http://www.imagemagi...cript/index.php) - A pile of command-line tools to do stuff with image files. I use these quite a lot in my build scripts for resizing icons and such, so I install this right away.

PowerArchiver (http://www.powerarchiver.com/) - Not free, but it's the best one. While Windows' ZIP integration is pretty good, there are plenty of formats it still doesn't grok, like RAR. For those you need an archiver.

PromptPal (http://www.promptpal.com/) - Also not free, and there are plenty of free alternatives, but I have this registered so I keep it. Basically it's a command-prompt replacement that has some enhancements but most importantly keeps your command history persistent from launch to launch. So if you come up with a really hairy clever path-laden command line to do something, you don't lose it if you need it again. Why the default one doesn't do this, I'll never know.

Sizer (http://www.brianapps.net/sizer/) - Just discovered this a couple of months ago. It adds a sub-menu to your windows system menu (yep, there's still one there) that lets you resize a window to a particular size. This is just the thing if you need to capture screenshots of a particular size.

XNView (http://www.xnview.com/) - A perfect companion for Sizer, as it has plenty of options for screen-capture including "capture just the client area of a window", and it can snap to files without interaction, so you can just set your windows up and then play your game and snap away until you get enough screenshots.

VLC (http://www.videolan.org/vlc/index.html) - Yeah Windows 8. Good thinking. If I wanna play an MP3 file, I want it to take up the whole danged screen. Or maybe I just wanna play it in a little window and shove it out of the way.

Adobe Reader (http://get.adobe.com/reader/) - See VLC. Windows 8 comes with a PDF reader now, but it only runs full-screen. This reader (or any other, really) fixes that.

Classic Shell (http://classicshell.sourceforge.net/) - A dozen "get back your start menu" gizmos have appeared over the past weeks. This is the best one, mainly because it's been in existence long before Windows 8. It's very stable and is instantly familiar.

CPU Meter, Network Meter, and Drives Meter (http://addgadgets.com/) - Yeah Windows 8 killed Desktop Gadgets, but there are plenty of hacks to bring 'em back, including instructions on that page. I can't function well without these little guys sitting in the corner telling me the state of the Main Development Box.

CCleaner (http://www.piriform.com/ccleaner) - There are billions of "clean out useless files and crap" software out there. This one is excellent and is free.

Google Chrome (https://www.google.c...chrome/browser/) - IE10 is actually pretty good, but my brain's too used to Chrome to turn back now. Also all my bookmarks and saved passwords and such instantly sync up the moment I install it, and that's cool.

Chrome Remote Desktop (https://chrome.googl...kmpfmihenigjmpp) - The most dirt-simple and best performing remote desktop system I've ever used. Only drawback is that it currently only exists on desktop Chrome. Hopefully it's moving to mobile soon.

Disable Aero Shake (http://www.howtogeek...e-in-windows-7/) - Not an app per-se, but something I like to do. I like all the Aero stuff like snap and preview, but Aero Shake just seemed to be something that jumps up when I didn't wanna use it. So here are the registry values that shut it off.

Box, Dropbox, SugarSync, Google Drive, SkyDrive - Hey, I like clouds. Might as well use 'em to hold stuff for me. Dropbox is still the most mature, but the others are getting better.
johnhattan

Great freebie deal

Oh but I have a good freebie that's coming up in a couple of days. I was going to post this as a gamedev.net front-page news item, but it appears that our news-feed is entirely scraped from other sources now (which is just fine with me), so I'm posting this as a blog item. Feel free to upvote it on that front page tab so everybody sees it.

Packt Publishing, one of the new "biggies" in technical publishing is announcing that they're publishing their 1000th book. And, in honor of that milestone, they're giving a "pleasant surprise gift" (their words not mine) to everyone who has an account on the site before 9/30.

(and I have permission to tell you that the gift is a free ebook of your choice)

So go to www.packtpub.com before 9/30 and sign up for a free account if you don't already have one. Their little ebook online store is top-notch and DRM-free, and they have PDF and EPUB versions of all their books, so you can view 'em on practically every computer or e-reader out there.

Also they have some free books on the site already, so you can check 'em out.
johnhattan
This is a long-needed change to the Mac versions of my games. In the past, my Mac games worked on both the old PowerPC-based Macs as well as the newer Intel ones. Well, now the PowerPC Macs have graduated from "old" to "ancient", and Apple has been gently nudging developers into working only with newer releases.

And that extends to the new Mac OS X "Lion", which drops backward-compatibility with PowerPC-based technologies entirely. So I have to look forward instead of backward, and I have now uploaded new Lion-compatible games. If your Mac has complained in the past about compatibility with my games, simply re-download your games and they should work without complaint.

As for PowerPC-based games, I will still keep them around but I will deal with them on a case-by-case basis. If you, for example, have an old PowerPC-based Mac and you need to re-download and/or re-install your game, you should contact support@thecodezone.com directly and I will get you your games.
5927544581291786949-8826801636482508713?l=thecodezone.blogspot.com

Source
johnhattan
Tech support tip for independent game developers selling game downloads

Gmail is a GREAT tech support tool.

I've been selling downloadable games on my website since 2007. And in those years I've had plenty (and by plenty I mean hundreds) of emails to support@thecodezone.com from people who need help. 99% of the emails fall into two categories:

1. (<7 days from purchasing) I am having trouble downloading/unlocking/installing
2. (>7 days from purchasing) I bought a game quite some time ago and I switched computer/email/gender/whatever and I lost my original download instructions.

When I first built my little order/download system, I made sure to stuff every transaction I made into a MySQL table. I kept transaction numbers and emails and products purchased and all that stuff. And that way if anybody from category (2) above had a problem, I could look up their order.

And I have NEVER used that table.

It's still out there, full of everything I'd need to look up an order. But I don't use it because I have Gmail. When someone buys a game, the last step on my side is a little piece of PHP generates and sends and email to the them with instructions on how to download and install the game. And, just to be safe, I also sent that email to sales@thecodezone.com where it is quietly filtered and stuffed it into a Gmail folder.

And that's pretty-much my tech support. If anyone emails me saying "My name is Fredrick Fribble and I bought Bulldozer around two years ago", I can find their order by searching my gmail. Re-sending their download instructions is as easy as re-forwarding that old email back to them. There have been a couple of occasions where I had to go back and forth a couple of times because they ordered under a different name or changed email addresses or something, but I have always been able to find their order and send it back to 'em. Usually in a couple of minutes.

So I guess the suggestion here is not to overengineer things. I realize this wouldn't scale if your orders got into the huge numbers. But my orders do number in the thousands, and this little system is showing no signs of breaking down.
5927544581291786949-8271138388481563586?l=thecodezone.blogspot.com

Source
johnhattan

Books to review

Okay, I just got a dozen requests for reviews from O'Reilly and Packt, so I thought I'd post the whole set here. If there's something you'd like to see reviewed, by all means tell me in a comment and I'll make sure it happens:

O'Reilly
ActionScript Developer's Guide to PureMVC
Google Script: Enterprise Application Essentials
Introducing Starling
Mapping with Drupal
Node for Front-End Developers
Programming Google App Engine
The Little Book on CoffeeScript

Packt
XNA 4.0 Game Development by Example: Beginner's Guide -- Visual Basic Edition
Android 3.0 Animations: Beginner's Guide
Android NDK Beginner's Guide
Unreal Development Kit Game Programming with UnrealScript: Beginner's Guide
Cocos2d for iPhone 1 Game Development Cookbook
johnhattan

My belated review

First off, apologies to Kobold Quarterly for this. I promised a review of their book a while back. And I actually wrote the review. But we're having a bit of a problem with Gamedev's CMS right now, so I'm going to do an end-run around it and post it to the blog.

Problem is, the Amazon-scraper we use to grab book covers and links and info about books is having a fit about The Kobold Guide To Board Game Design because there's no dead-tree version listed on Amazon. Envisioning this as a one-act play, I think the process is going something like this.

Gamedev: Amazon, do you have a listing for The Kobold Guide To Board Game Design?

Amazon: Why yes, it appears that I do!

Gamedev: Outstanding. Please send me a bitmap of the cover art.

Amazon: Oh, that would be no bother at all. Here you go!

Gamedev: Much obliged. Would you mind sending me the Amazon price and the number you have on the shelves right now?

Amazon: I would be delighted to. The price is $9.99 and we have zero copies on the shelves.

Gamedev: Zero copies eh? Oh that's just ducky. I shall mark it as out of print until such time as you get some inventory.

Amazon: Suit yourself!

FIN

I don't know exactly what field is giving our book-scraper fits. But there's something about e-books that's convincing the scraper to mark it as out of stock whenever it checks Amazon. As I'll post the review and feature it, but then a couple of hours later it'll get delisted from our little book section.

And I'm not faulting our programmer, as he's got much bigger fish to fry right now than fixing a bug in our book-scraper. He's tied up making Gamedev a far awesomer and more organized thing than it's been in quite some time, so I'm staying outta the way.

So for the time being I'm going to post the review here. At least the Kobold guys can link to it and/or quote-mine it. Once the scraper bug is tackled, I'll make sure it's properly listed on the site proper.

Cheers and thanks for everyone's patience!

[hr]

51%252BiuEFzxtL.jpg



I'll say this from the onset. The Kobold Guide To Board Game Design is the best book on game design that I have encountered in quite some time. I discovered this book outside of the normal PR-channels where my to-be-reviewed books normally appear. I happened across the title while reading one of the dozen or so nerd blogs that I frequent. It looked interesting, so I plunked down ten bucks for the PDF at koboldquarterly.com and took a look.

The book is a collection of twenty essays written by some of the most popular non-computer game developers around today. While board game developers do not achieve the inexplicable rock-star status that some computer game developers get, their chops are every bit as sharp, if not sharper. Some of the authors are responsible for a five great games. Some have a dozen. And at least one has probably fifty games to his credit. What board game designers lack in notoriety, they make up for in prolificacy.

What, for me at least, moved this book from good to great was the chapter on writing precise rules. Virtually all computer game development books concentrate so hard on the steps from concept to "code complete" that they ignore the other half of the process, which is how to get the danged game done and boxed and to a point where someone other than the test-team can play it. Coherent instructions or tutorials seem to be of no concern to developers because that will be handled by a technical writer in another office somewheres. Game development is a pile of a hundred little tasks, and if you assume that those tasks will be best handled by "someone else", then your game won't be done to your satisfaction.

And what does this have to do with computer games? Well, stout yeoman, computer games and board games are virtually the same. If you grab the latest deep fantasy quest game on Xbox ("sky-something-or-other"), I guarantee that big chunks of it could be played with pencil-n-paper or a hex map with miniatures or dice or even just your hands.

Heck, those DS "Pokemon" games are, at their hearts heart, rock-scissors-paper.

My only complaint about this book is with the packaging. On the Koboldquarterly.com site, I could buy a paper or DRM-free PDF of the book. On Amazon (linked above), I could get a Kindle-DRM'ed epub. Unfortunately, neither solution is optimal for my cheapo e-reader. Unless fidelity of the screen to printed page is important, I would prefer an epub to a pdf. And this book is about 95% text with just a couple of illustrative graphics, so epub is best.

But that's just me venting a minor pet peeve. If you fancy yourself a game designer, you need broader horizons than simply having played every game available on Xbox. You need to know how to develop a working mechanism. And a board game is the mechanism of a game stripped down to its essentials, with the 3D animation and particle effects and, yes, even the computer itself stripped away. This is game design as design itself.

Source
johnhattan

How to fail, PART TWO!

[font=Verdana][size=2]Following this post of a couple of years ago, here's the second in my series[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]How To Write A Losing Pitch For Your Indie Game Project[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]I just found this taking up a little space in Google Docs. It's the original "pitch" I made for Monkey Blockade a couple of years ago.[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]To be honest, I don't even remember who I was pitching this to. As I recall, some mobile game website/portal/publisher put out a call for people to send in two-minute elevator pitches for original mobile games that could be developed quickly. And since I'm nothing if unable to slap together a game fast, I sent in an idea.[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]Needless to say, they weren't interested. Given that I can't even figure out who wanted me to pitch the idea to 'em, I'm assuming they didn't even have the courtesy of emailing me to turn me down flat.[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]Anyway, a couple of years later I was digging through some old stuff and found the screenshots. I still thought it was a good idea, so I spent a few weeks actually implementing it. I added some stuff (snacks that distract monkeys and changing the red circles to clanking robots), and didn't implement some stuff (the comic strip back-story), but I thought it turned out rather well.[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]If you wanna see the final product, go to my mobile page at m.thecodezone.com and check out the screenshots in any of the app stores.[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]---[/font]
[font=Verdana][size=2]
[/font]
[font=Verdana][size=2]Name: Monkey Blockade[/font]
[font=Verdana][size=2]Game Type: Quick Puzzle[/font]
[font=Verdana][size=2]Description: Trap the monkeys that are trying to escape by placing blocks in their way. Monkeys are tricky, though, and they find ways to get around the blocks.[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]Introduction screen:[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]Following is a mockup intro screen. Note that the screen might be implemented as a "pop up", similar to the jumping-up windows in the Code Zone Flash games. Fewer screens makes for a simpler experience. I'm also toying with the idea of eliminating as much text as possible, with the idea that less text makes for a better experience for international users. The following text might be replaced with a "slide show", not unlike a comic strip, illustrating the backstory and the gameplay.[/font]
[size=2] _-7HJH775U80WQEY1IWCZEiim7jP6GpbXIJHSspNVxNCzKnjPk88aA6E4RFV8MCUdWFhtvAF8sG0us_7qy7KbVWLwzBLhDJTMPZsoaRJerVefgHU3F0
[size=2]
[font=Verdana][size=2]Following accepting the start-playing screen, you see the gameplay screen.[/font]
[size=2] 4jYtB2ALpXb4fkBkFV7G3vg3N7KIGmY70cvEChmc2oCwYTYGxY6Ury5TLAfc4RTlMIMwP37hl1-z2xd6_s2A6UT-g1R7UGg9TGzRjyp0HAvtW4y5pHs
[size=2]
[font=Verdana][size=2]You initially start with ten monkeys, one on the board (in a random spot, but near the middle), and nine under the "remaining" text. As monkeys escape or are captured, they move to the "escaped" or "captured" sections at the top of the screen.[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]To place a block, tap the screen. The block will not actually set itself until you let up with your finger, so you can make sure it's over the hex you want to use before you place it.[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]The "Blocks" and "Time" will accumulate throughout the game. They will likely be replaced with icons (a block and a clock).[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]Once all of the monkeys are either captured or escape, you get the game summary screen. Again, this may be a popup if that's easier to do, in keeping with the "one screen" motif.[/font]
[size=2] TIAX5VRpzj0LIzYqAc9emB457VqJ1PBNOCjOmThk2Gq7iDc2lhRnKqrfCo2sWZh-VBMLfiQJ6KM_FAguzvG56i7ySjh66iTbVSOTGOEQLJlqaDjW_r4
[font=Verdana][size=2]Your score is a combination of captures (big points) minus a small penalty for number of blocks used and a time bonus. At this point, the user will get the opportunity to enter his score in a global table that will work a bit like the Mochi highscore table (daily, weekly, and monthly high scores).[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]Possible enhancements.[/font]
[font=Verdana][size=2][/font]
[font=Verdana][size=2]Since this game is a natural for making a daily puzzle, there's a possibility that I'll couple this with a daily puzzle version on thecodezone's site. If the user chooses to play the game as a daily puzzle (from the main menu), he can enter his thecodezone ID and password, and he'll be presented with the same puzzle as the Flash version and can submit his score to the site just as if he played the Flash version.[/font]5927544581291786949-8114740672449768082?l=thecodezone.blogspot.com

Source
johnhattan
Yeah, I noticed my last post to the blog was a quick postmortem of Marble Bump, which was a game that I intended to take from concept to app stores submit in two weeks.

Well, I decided to one-up myself, and I wanted to find something I could write and submit in ONE WEEK, mainly to get stuff in app-stores for the pending Kindle Fire and Nook Color 2 launches. So I went with one of my simplest games, Countdown Dice. It's just a cute little "push your luck" game where you roll dice to launch rockets. It's very simple and takes about two minutes to play, but it is oddly addictive once you grok the mechanism.

And not only did I get it finished and submitted in a week, I actually got it listed in an app store already!

IMG_00000015.jpg

(Countdown Dice in the Playbook store)


Yeah, it's just the Playbook store, and it's a bit of a degenerate case because the Playbook store typically approves in a shorter time than the rest (save for Android Market which has no approval process at all). Still, I'm happy. To quote the slave-driving colonel in "Bridge on The River Kwai", be happy in your work.


And once again I must plug my G+ feed, which is where I now post the bulk of my development-related info. It's at https://plus.google.com/106460508525236363626/posts


Soanyway, here are some pics of the process.


Untitled-3.png


Here's the first cut at a title screen. It's not much different from it as it shipped. I added a little Matrixesque animation to the title text, and I adjusted the text and colors a bit, but this is it. The buttons are lifted directly from Dice-A-Rama

Development Tip: If something works, steal it and use it elsewhere. Quit reinventing the wheel.

Untitled-1.png


Here are the graphics. The little vector rockets are lifted directly from the old 2007 AS2 game. I figure that game's been played several million times with no complaints about usability, so I wouldn't make many changes there. I did change "Turns Remaining = 5" to "Turn 1 of 5", as it seemed a little more obvious. Gets around that "do we throw the guy off the bridge at 1-2-3-GO or 1-2-3" problem.


I didn't reuse any code from the original. The logic was simple enough that I didn' bother.


Development Tip: Don't worry about making nontrivial objects reusable. While you might find yourself reusing a Pair or Dice class, you probably will just rewrite the CountdownDiceScorer class anyway, so don't kill yourself making it reusable. You've always got the code right there for copy-n-paste if there's a particularly hairy algorithm in there anyway.


Heck, I didn't even reuse the friggin' Dice class from Dice-A-Rama. It has several non-standard dice (with colored pips and face cards) that this game wouldn't need, so I just copy-n-pasted out a few lines of standard dice code.


icon_114x114.png


The icon. Took me about ten minutes. I used IconWorkshop (motto: The only icon editor you will ever need. Trust me) to make the purple roundy background, and then I pasted it into Flash to add the vector rocket and dice. And then I saved it out as a 512x512 pixel PNG and used a batch file and ImageMagick to make all the other icon sizes that the other app stores needed.


Development Tip: IconWorkshop is great. It's especially great with its free "iOS icon library" add-on that lets you drag together a classy iPhone-style icon in seconds.


ImageMagick is also great and is free. If you use a batch file or makefile or ant-file to build your app, use ImageMagick to size things in batch mode. Oh, and ImageMagick can also make .ico files with all of the sub-bitmaps embedded in it, but it's not trivial and requires an absurdly long command-line. I recommend making a batch file once you get it working so you don't have to retype it again.


featured_1920x1186.png


The "Featured Item" image. The Playbook, Android, and Amazon app stores want a "featured" image along with your icon and screenshots. It's usually just a publicity photo kind of thing like this, and it's about twice as wide as high. And they want all kinds of sizes, from enormous (1920x1186 on Playbook) to small (290x140 on Android Market).


Again, I use Flash for this. Since it's vector-based, you can export out to arbitrarily large sizes and the edges stay nice. I generally save out to a 2048x1536 image with plenty of whitespace (purplespace in this case) near the edges. Then I can just shrink and crop to whatever the app store wants to see.


Yeah, I could probably use Illustrator or Inkscape or some other vector tool. I don't know how to use those and I'm too lazy to figure it out. If you wanna do it for free, use Inkscape.


Development Tip: To take a screenshot on an iphone, it's RoundButton+PowerButton. To take a screenshot on a Nook Color, it's NButton + VolumeDownButton. To take a screenshot on a Playbook, press both volume buttons at the same time, although I just take Playbook screenshots from the emulator using Alt+PrtScn.



So that's just a quick overview of a couple of tricks I use to get stuff into app stores fast.



5927544581291786949-8743537002488954178?l=thecodezone.blogspot.com

Source
johnhattan
First off, if you don't have me circled on G+, I'm at gplus.to/johnhattan. I've been liveblogging the process there. If you don't have a G+ invite, my invite link is here. I only have 145 of my original 150 invites left, so get in now :)

I had an idea for another simple particle-collision game, and this time I decided to see how quickly I could get the game from concept to app stores. And it happened in two weeks, one week of which was waiting for approvals.

Originally I planned for it to be an atomic-particle-colliding motif, not unlike Meltdown. After some back and forth with the community, I went with the name "Particlusion" (particle+fusion). I wasn't completely in love with the name, but it worked and wasn't in use anywhere else. And I quickly mocked up a menu screen.


shot.png

The original eye-searing Tron-ish main menu




I even made a cool animation for the main screen when I had a couple minutes of downtime.

Untitled-1.gif



Then I started on the mechanic. The mechanic was quite simple (slide objects into other objects. If one object is left, you win), and you could even build some fairly challenging random levels by following some simple rules. This is unlike something like Bulldozer (aka Sokoban), where it's nigh impossible to randomly generate a decently challenging level. There's less "depth" than Sokoban (which is a mean feat, as Sokoban's depth is itself limited), but it was intended from the onset to be something quick and cheap.


Fast-forward a couple of days, and I was looking for some inspiration for my little colliding particles. I was thinking of some little nondescript spheres like in Meltdown when I came across some old marble clipart. I pasted a couple in, and it just fit. In fact, they fit so well that I decided to change the motif to marbles. A little name-check and "Marble Bump" was born. I originally planned to have the marbles on grass with a sidewalk texture here and there, but the contrast was much better just with the cement texture, so I left it everywhere.

Untitled-1.pngThe rebranded main screen, four days in. Close to how the release looks



The little wrench button in the corner brought you to a very simple level editor that let you place marbles. As you placed marbles, it built a string containing the level and the solution. I eventually added a little clipboard button so you could hop back to the main menu and test a level after copying its level string to the clipboard. From there I spent a few hours drawing and testing levels until I had the 24 "canned" levels that roughly run from trivial (two marbles) to nigh-impossible (19 marbles, I think).


The level editor was just for me, so that wrench-button hides for the release version. It added all of 2K to the game, so I didn't bother cutting it out.


I also got my random level-generator working, which is what you get from the row of buttons along the bottom. I figure if I could randomly generate challenging levels, I didn't need so many "canned" ones. So there are only 24 levels, but you're not stuck once you've beaten 'em all.


After taking the weekend off to carpool the kid to summer camp, I decided my marbles needed some more personality. So I tried the most obvious thing and added little cartoon eyes to 'em. They're actually pretty simple. They have two states (normal and wide-eyed terror), and both pupils are actually a single MovieClip that I tween in whatever direction the marble's moving. If a marble is about to be hit, I switch the eyes to the wide-eyed terror state, and I tween the pupils very small (and that's why the pupils get close together when a marble is about to die. It's actually just one meta-pupil). I added three mouth positions, and I now had marbles that expressed the gamut of emotions from "I'm gonna hit you" to "oh no, I'm gonna be hit" to "Yay, I killed all my friends so I'm happy!"


And I added a random tint to the pupils, so marbles can have green, blue, or brown eyes. That's the sum-total of Marble expressions. As I learned from crafts and cartooning a long time ago, eye shape, eye placement, and pupil placement can impart a lot of personality without a lot of work.


And I put together a little video. It's very close to final form.




Same day as I posted the video, I declared the game finished. I actually had a minor button-graying bug that I have since fixed. But posting updates to app stores is a simple process, just requiring you to upload the updated game and some simple release notes. It's the initial approval that takes the time, so get on that ASAP.


As for app stores, I posted to the iOS store first because it has typically had the longest lead-time (5-7 working days in my experience). Then the Playbook store, which takes 1-2 days to approve. And finally the Android store, which has no approval process, and your game becomes available whenever Google's indexing-bot finds it. Typically an hour.
And code-signing for iOS and Playbook are a friggin' nightmare that requires enormous amounts of trial-and-error. And even if you get it working, you will NEVER understand it. I'd detail the process, but it makes me cry whenever I do.

Just as a lark, I signed up for the Amazon and Nook developer programs and got approved for both (because I'm a force in this industry goldurnit). Modifying the Android app for Amazon was pretty simple, just requiring you to point to a different location to download the AIR runtime. The Amazon approval time was about the same as iOS. Maybe a little longer. I didn't watch it too closely.


I still haven't submitted the game to the Nook store, mainly because I've rooted my Nook with CyanogenMod (which is really awesome and makes your Nook into a full tablet), but I'll need to revert back to stock firmware to test.


Submitting to app stores is a bunch of monkey-work. They all need a textual description of your game, which I just wrote once and cut-n-pasted.
Marble Bump is an original new puzzle game. It is quite simple, but it is pretty tough to master. At first it appears simple. Just bump marbles together to shatter them, and once you are down to a single marble, you win. And the initial levels are fairly easy, but the game gets tough quickly, and the highest levels are guaranteed to bend your brain.
The game comes with 24 levels of increasing difficulty. But you're not done when you have mastered all of the included levels. Marble Bump also comes with an infinite number of randomly-generated levels, so you can tease your brain whenever you want. Have fun

Screenshots are a pain because every store wants certain sizes, so you can't just whip up a pile of generic screenshots and upload them everywhere. Playbook is easiest because your bitmaps can be any aspect as long as no dimension is bigger than 640 pixels. Android has four sizes that they'll accept, corresponding to the most popular phones and tablets. iOS wants 'em in iPhone and iPad size, and you need to upload both. I have an iPod Touch for testing, so snapping iOS screenshots was easy (power+roundbutton snaps screens to your film-roll). I don't have an iPad, and AIR apps don't work in Apple's "not really an emulator" emulator, so I had to fake those.


You also need icons, both for development and app stores. Icon sizes are all over the place, and I recommend you grab a copy of ImageMagick right away. It's got a command-line utility called "convert" that'll convert a bitmap's size and/or format, and it does a terrific job of retaining detail and transparency. The biggest icon that everybody wants is 512x512, so I just drew a giant icon PNG and then made a batch file that would downsize that mega-icon to the half-dozen other sizes I need (480x480, 128x128, 114x114, 72x72, 57x57, 48x48, 29x29, 36x36, 32x32, 16x16). Every store wants all images in PNG, so get used to using PNG as your file format of choice. I prefer Adobe Fireworks for all my bitmaps and screenshots and such, as it's designed around PNG and works with it nicely.


The only other picture you need is a "featured" image for Android and Playbook. This is just sort of an advertising picture. You can see one as my big main title picture here. Android and Playbook want 'em in various sizes, but generally around 16x9 aspect. My best advice is to make a giant bitmap at least 1200 wide with a healthy amount of whitespace around the edge that you can crop and resize without much stretching. As you can see in my Android Market shot, there's plenty of yellow on either side of the marbles, as this particular one has around a 2/1 aspect ratio.

The only other weirdness is Apple's two-step process for submitting. Every app store but Apple's lets you upload your game during the "describe your game and upload your screenshots" process. Just choose your APK or BAR file and press "upload". Except iOS. After you get all your descriptions and screenshots uploaded and Apple says you're ready to go, you then have to run a free utility that comes with xCode that uploads your IPA file to Apple. It's not particularly obnoxious, but it'll catch you by surprise the first time.




If you want to check out how Marble Bump looks in the four app stores, head over to my newly-updated mobile site at m.thecodezone.com and click on the four app-store buttons under the game.


And I'll make the same deal here as I made on FaceTwitterBookPlus. If you review my game, I'll reimburse you for the buck you paid for the game via Paypal :)5927544581291786949-8116090511556462183?l=thecodezone.blogspot.com

Source
johnhattan

AS3 Controls

Still doing my mobile games here. One problem I ran into is with controls. My games aren't very control-heavy, but there are times that I do need to impart a little textual or columnar information to the user (i.e. help and high scores). And I'd really rather not roll my own. And this problem is compounded by Adobe's apparent abandonment of the control model for mobile Flash.

Mind you, the standard AS3 Flash/Flex controls render fine in mobile apps. Problem is, a lot of the controls are not at all finger-friendly. Some controls, like PushButtons, work fine. After all, clicking a button with a mouse and tapping a button with your finger is the same operation as long as you make the button large enough to accommodate a finger. Some operations though, like scrolling a text-field with a scrollbar, are frustrating. Adobe addressed this on Flex by releasing several finger-friendly controls. But unlike the previous releases of AS3 controls, they didn't keep parity with Flash. If you're using Flash with mobile, and you want controls, you're pretty-much on your own.

I have played around with a couple of the mobile-friendly Flash control sets out there, but none of 'em really set me on fire. Some looked good but looked more like Android than iOS. Some were built around an odd model that made it difficult for me to just say something easy like myTextField = new TextField().

And I understand that it'll take time. The AS3 controls that come with Flash are pretty danged robust and well documented, and you won't be able to duplicate all that functionality in the short term. But I did find this, which I think is pretty interesting. Rather than write new controls, the author just wrote subclasses for the touch-unfriendly controls and added touch-friendly events. So, for example, you can now have a TouchDataGrid object that's just the old standard DataGrid control, only the mouse events are overloaded so you can drag in it with your finger to scroll it around.

And that's great for me, because I don't wanna have to mess with controls. I'd much rather create a DataGrid and populate it with high score data than manage all the drawing myself. When I use standard controls, it's usually for stuff that I just want to implement and then ignore so I can work on the game. For example, Help.

Untitled-1.png


Wow, a scrolling text field and an OK button. Don't wanna spend much time on that!

One thing you'll notice is the little scroll-elevator thing on the right side. On iOS and Android, that little scroll indicator only appears when things are actually scrolling. And I don't really like that. Dice-A-Rama actually got down-rated on iTunes because one reviewer stated that there are just a couple sentences of help without a detailed rundown of scoring. And that's not true. There's quite a lot of help and detailed scoring for each game, but you get the impression that there's just one screen because there's no indication that you're looking at a scrolling field and there's more to see. And I do realize that it's an OS sin to go against the One True Mobile Look, but I think it's an equal OS sin to hide from the user that there's more information to be seen. So I'll either leave the scroll indicator on or I'll add some "drag the danged screen to read more help" text.5927544581291786949-1165397969220548693?l=thecodezone.blogspot.com

Source
johnhattan
In honor of Gamedev's 12th birthday, I'm gonna release the design document for my latest game, Dice-A-Rama. Basically it's a game I tried to write in ten days to address the lack of a Yatzy ("Yahtzee" is trademarked) game on the Playbook. Actually it ended up taking about 20 days because I was still building a lot of cross-platform stuff. On the good side, it's now available on the Playbook App Store here and on the iPhone App Store here.

110616093207.png



The big ZYNGA logos are because it's a pad of free sticky-notes I got at a game conference a couple of years ago. Stickies and pencils are the only design tools you need.

And yeah, this is kind of a joke. But it does give you a bit of a feel for design. If you're a one-man shop and you have a simple design and you're confident in your ability to implement it, then don't spend much time on design. I wrote my first computer game almost 30 years ago, so design documents come second to getting an idea working while it's still fresh in your mind.

My bug-fixing process is the same. I am never more than two feet from a pad of stickies, and when I find ANYTHING, I quickly write it down. You'll be surprised how many ideas are lost between the time you switch from the game running on the screen back to your text editor.

BTW, "Kismet" is also trademarked, so I went with "Destino". "Kismet" is the Turkish word for "Fate", so I went with the Italian word for "Fate". Get it?

And I ended up dumping the three-column mode. Made the game too long and it also made the cells too small for dinky iPhone and Android screens.
johnhattan
Well I haven't had any substantial updates to the site since November. And that's both good and bad. It's good in that there haven't been any site emergencies in six months. We're nice and stable.

But it's not good in that there haven't been any other site updates of note.

But I haven't been sitting on my mini-empire of puzzles. Blackberry Playbook Bulldozer, Duck Tiles, and Pop Pies Portable (based on Pop Pies 3) are shipping. Brain Bones and an all-new game called Dice-A-Rama are also getting ready for release on Playbook, Android, and iOS.

As for this site, I've just added yet-again-still-another social networking widget, I have now added Google +1 buttons on all of thecodezone.com's pages! Excitement!

The way it works is simple. If you have a particular game you like (ConFusebox, for example), click the little Google "+1" button at the bottom. That way the page gets a little boost on Google's search results. This will hopefully drive a few more people to the site, giving me another dollar or two of ad revenue and financing more puzzles.

Big thanks for your support!5927544581291786949-6176849538216127994?l=thecodezone.blogspot.com

Source
johnhattan
First off, I'm not posting this with the hopes of inviting malice. I'm posting this to inform you that anything you thought regarding code security in AIR for Android apps is probably illusory, and that you (and hopefully also Adobe) need to take some extra steps if you don't want your assets stolen.

That being said, here's how to take apart an AIR for Android app you've downloaded from the Android Market.
  1. Get the free Astro file manager from the Android Market.
  2. Run Astro.
  3. From the app menu, choose "tools" and then "Application Manager/Backup".
  4. Choose any app you've installed on your Android device. You can choose any app you want, but AIR apps are particularly egregious in their lack of security.
  5. The application will be copied from internal storage and will be copied to your backup folder (most likely on your SD card) as an APK file.
  6. While still in Astro, navigate over to that backed up APK file and click on it. Choose "send to", and send it to your desktop machine via email or Dropbox.
  7. Now that the APK is on your desktop computer, rename the APK extension to ZIP and open it with your favorite ZIP-reading program.
  8. In the "assets" folder within the ZIP, you should find a file with the extension SWF. Yes, this is the same SWF that was created with Flash/Flex. The AIR Android packager doesn't do anything to the file at all. It just copies it into the right spot in the APK ZIP-file so the AIR runtime can run it.
  9. Copy that SWF out of the ZIP file, and you're done.
At this point, you can do whatever you want with it. You can download the Adobe AIR SDK and Android SDK, re-package the SWF into a new APK, and upload it to the Android Market under your own name. You can decompile the SWF with a tool like Sothink SWF Decompiler (which worked great on all the examples I tried), then change up the game enough to pretend it's an entirely different game. You can put the SWF on your website. Or you can just browse through all the author's source code and copy out his code/graphics/sound assets into your game!

Note that there are tools like secureSWF (which I reviewed here) that are very effective at munging ActionScript bytecode into something that can't be meaningfully decompiled, but that would only prevent people from decompiling and/or reading and/or recompiling your source code into a new SWF. There's still nothing preventing me from making a new APK out of your game's SWF.
also note that exactly ZERO of the AIR for Android apps I tried actually had obfuscated their bytecode with a third-party tool . A couple of you guys have atrocious naming conventions :)
Fact is, if you are going with Adobe and Android's recommended sequence to make an AIR for Android APK file with the aim of putting your app on the market, you are essentially open-sourcing your app. Unless you go with some further security (and I don't even know what further security you could implement beyond obfuscating bytecode), you are leaving your app wide open for IP theft.

And I'm not doing this with the aim of convincing every 13 year-old creep with a decompiler to start stealing apps and republishing 'em under his own name. It's more like discovering that every door-keypad at the Pentagon opened with the combination 1-2-3-4-5. Would publishing such information be inviting terrorism or would it be informing the Pentagon that their security is worthless and needs updating ASAP?

Also I'm posting this because I'm angry. And I'm angry because I brought this up during a Q&A at an Adobe conference when AIR was announced as "Apollo" in 2007. The Q&A went something like this:
Me: If your compiling step is just zipping up all of the web-app's assets with an XML manifest file and some icons, what's to prevent me from unzipping that file, making changes, and re-deploying it.

AIR guy: We're planning some security stuff.
Turns out the "security stuff" was apparently their app signing process. And the ONLY thing that prevents me from doing is me making changes within the AIR file itself. I can't open an AIR (or APK) file and make changes to the file itself, as the certificate file would no longer match file checksums for the AIR/APK file. I'm still free to open, decompile, read, write, update, steal, and rebuild the app under my own name.

They've had four years to fix this.

Finally, a note about the iPhone. While an iPhone IPA file is also a renamed ZIP and IPA files are also easy to retrieve, the contents of AIR for iOS files beyond icon PNG files and a manifest XML weren't in a readily decompile-able format. Looks like the Adobe AOT compiler really works.5927544581291786949-3240684431859205391?l=thecodezone.blogspot.com

Source
johnhattan

Good book deal

Good deal today. O'Reilly has several good titles today. The good deal part is that they're giving all proceeds (minus author royalties, I'm sure that's a contractual thing) to Japanese disaster relief.

http://oreilly.com/store/dd-jpn.html

Couple of good looking titles there. Although I don't know how good a book on Audacity can be. Audacity is REALLY easy to use. Anyway, browse and get a book for a good cause.5927544581291786949-6222312749055616603?l=thecodezone.blogspot.com

Source
johnhattan

New project part two

Well, the angriestprogrammer.com project has spawned a successor. And the successor came from its sheer overengineering. Even though my little database/XML/PHP driven comic compositor could've been simpler than it was, I gave it a few extra capabilities. Namely the capability to overlay several bitmaps in a frame, although angriestprogrammer.com only shows one bitmap so it was never needed.

And I got to thinking, what if I was able to define bitmaps with descriptive names and have them appear only if they're called into existence in a frame, i.e. if they're speaking? And what if I gave the speech little comic "bubbles" so I could use backgrounds other than just white? If I did those things, I could build a more sophisticated (but only slightly more so) "red meat" style comic (google for it) out of a simple XML description.

And then I got the idea of knock-knock jokes. After all, there are millions of those out there, and there really isn't a good site for 'em. Most knock-knock sites appear to be holdovers from Geocities that have plenty of knock-knock jokes, but they're not really presented in an appealing style. So I invented my new site, knockville.com, a kids' website that will become (I hope) the definitive home for knock-knock jokes on the web, presented in an appealing style.

That is, if you find public domain clipart appealing. And I do. There's just an odd innocence to it. Case in point.

70defc198c.png

I think a Facebook commenter summed the whole project up with something like "you've figured out how to be a cartoonist without having to draw OR write. Congratulations."

So my goal is to spend an hour or so a week scanning in a couple of new characters and/or backgrounds and entering a dozen jokes, in the hopes that eventually I'll have about 100 characters and a couple-dozen backgrounds. And I'll keep entering knock-knock jokes until I run out. And after that, I'll just let the site repeat jokes forever.

And I don't think repeats will be a problem once I have a big enough mass of material. I remember listening to an interview a few years ago with the creators of the Teletubbies. And the interviewer asked 'em why they stopped making new episodes after four years even though they were successful. And the answer, I thought, was quite astute. It was that they had enough episodes that any kid who just discovered the Teletubbies would now outgrow the series before running out of episodes. They could now re-run episodes forever without worrying about them getting stale, because kids are EXPECTED to outgrow them. I fully expect kids to visit my site, press the "Random" button a dozen times until they get a few new jokes to tell their friends at school, then get on with their lives.

And why knock-knock jokes? Because when my daughter was four years old, I was roped into helping the kids with a party at school. And one of the kids was bummed because she wanted to sit by my daughter but couldn't, so I declared that I was going to sit by her. And then I told her a knock-knock joke. And as soon as I did, a dozen other kids started chiming in with their own jokes (most of which were completely random and awful but I digress). I saw that there's just something pure and easy-to-remember about knock-knock jokes, and I always kept with me that if I could present knock-knock jokes in a silly format that kids could read and remember for school the next day, they'd probably show up to read 'em.

So I made the site. And I made it in a way that would be easy to maintain. All that's really left to do is to add a page where kids can submit their own jokes. And if I use their jokes I'll give 'em credit.

So I'm hoping that this modest little project will work out. Thoughts?5927544581291786949-865814893269699073?l=thecodezone.blogspot.com

Source
johnhattan

On the book section

I'll be the first to say that Gamedev's old book section was a steaming pile. Most of the books were out of print. Many significant titles were missing. The search only worked sometimes. It was just a problem, and much of that problem came from the fact that it was almost never updated. The only person who added new books was me, and the only books I ever added were books that were on my desk and needed reviews.

Well, the new system goes a great distance to fix that.

First off, adding books is no longer a big mess. I can basically add an ISBN and gamedev will fill in most of the rest of the book (including the picture). Reviewing and featuring a book on the front page is no longer an overcomplicated multi-step process. Also, the system can automatically de-list books that are too old or have gone out of print.

Mind you, the purge process isn't perfect. Mainly because the concept of a "print run" in book parlance is going away. There are so many one-off publishers now that books can basically stay in print forever, as the "inventory" just consists of a PDF file sitting on their server somewhere, and a book only comes into existence after you press the "buy this book" button. So there'll still be a process of manually purging out books that have worn out their usefulness (like the five books on Flash MX 2004 that are still listed) as well as a process of "immortalizing" books that are OOP but are still significant and/or useful. But the list will be much more useful than it has been in the past.

So my plan for the books is the following:

1. I will review one book per week. It'll be a shorter review than in the past and it'll be based on whatever books are sent to me.
2. That book will be listed, reviewed, and posted as the featured review on the site. The current one is already up now.
3. Any other programming books that I receive via press-release will be listed and categorized but not reviewed or featured.

We'll see how this works in the future, but even without new listings and/or purges, it looks much better. The five "latest books" are actually recent titles. The top-selling books list actually reflect reality. The categories need to be re-done, but that'll happen with time.

So again, Gamedev is getting better. Stuff you've blown off as stale crap is getting less so. It'll take some time to get a good mass of new books as well as purging stuff nobody cares about. But it'll improve.

So if you haven't been around in a while, https://www.gamedev.net/books
johnhattan

My new project

Okay, I hinted on it on a couple of times. And I've been rolling the technical specifics around in my head for a couple of months. So I took about ten days full-time to implement the back-end. And now it's done.

It's my own webcomic, The Angriest Programmer In The World

First off, the thinking behind it.

I found recently, while working, that I was building some juicy one-liners in my head. Mostly geeky. Usually angry. And while Twitter is usually the venue for such brain-droppings, I found that they often didn't fit. I needed something more like the Laugh-In blackout gags, with a couple of characters interacting.

And I liked the minimalist style of Dinosaur Comics and the even more minimal Angriest Rice Cooker In The World (RIP), both of which are influenced by David Lynch's Angriest Dog In The World. I thought that Rice Cooker was a bit limited in that it was one character only, thus making it work better as a Twitter avatar than a standalone comic strip (ala Twitter feeds like Atheist Hulk*). Angriest Dog appears to have more than one character, but they're never shown so you can't really identify with them. So I decided to make a comic with 1.5 characters (one isn't entirely sentient) as well as a computer and a narrator with which the main character could interact. And I went with four frames because three frames is occasionally too short if you have two characters.

Basically the whole thing is based on single static frames like Angriest * In the World, only with a couple of persistent interacting characters like Dinosaur Comics and some deeply geeky jokes like in XKCD.

So yes, this ain't art. This is a derivative cynical ploy to grab some geek eyeballs.

And that's nothing new. I remember reading once that the guy who makes Garfield used to be in advertising and he chose a cartoon about a cat because there was already a top-tier and a second-tier newspaper comic dog (Snoopy and Marmaduke) and a second-tier newspaper comic cat (Heathcliff) so he went with a cat hoping to fill the top-tier comic cat void. I'm not trying to become a top-tier anything. I'm just making a character who will vent his id to the world while making pop culture references at a more deeply geeky level than stuff intended to appeal to normals like "Big Bang Theory".

In other words, if you don't get the jokes, then it ain't for you. Belvin probably won't throw in a joke about how much he hates Mondays every week so you won't be scared away by the joke about brace-indenting that you didn't get.

And someday I'll likely put something together that will let people send in their own corporate and/or programmer stupidity (ala Dilbert) so Belvin Klapoknik can have new things to yell about.


As for the future, this is a soft launch. I want a dozen or two comics on the site so people will have a reason to stay for more than ten seconds. I'll see if this keeps going and gets enough eyeballs to justify its existence. If so, then yay. If I run out of ideas (like the Lazy Programmer videos) or nobody cares (like Cryptotwit and Hangtwit), then it'll wither.

What I'd like from you right now isn't publicity. While I'd like for a zillion people to press the "share this comic on <Insert Social Network Here> buttons under the comic, and I'd like a zillion people to subscribe to the daily comic feed in Google Reader, I also know that there's not currently enough stuff there to compel people to stay. And I don't want you to share a comic unless you actually think it's funny. If you share a joke out of obligation, then your <Insert Social Network Here> friends probably will find it as unamusing as you did, and that won't help.

So instead I'd just like a little feedback. I've been playing with it in BrowserLab, and it looks reasonable in most browsers. There's still a little tinkering (HTML, like Java, is "write once, port everywhere"), but I'd like to hear what you like and hate.

And, yes, I know Comic Sans is evil. Problem is, damn near every comic font I've found either doesn't look good at a small size or has a very limited character set. I have a comic this week with umlauts, and I didn't want to draw them manually**.


*why my own Twitter feed is the second hit for "Atheist Hulk" is entirely beyond me. I just noticed it, and I suspect someone's stuffing the Google box there.

**and by that, I mean "I don't have a way to draw them manually that isn't horrendously complicated, as these comics, if you haven't figured out yet, are auto-generated from a custom XML-based comic rendering language and never see a paint program.5927544581291786949-7590652973484458809?l=thecodezone.blogspot.com

Source
johnhattan

New gamedev!

Hey, it's my first blog post on the new gamedev.net!

For the record, we were fully aware that gamedev was suffering from severe bitrot for years. While I'm sure you'll see more info from developers more closely associated with the project, the main difference is that we're now using a commercial third-party content management system rather than rolling everything ourselves. Gamedev's been around for a long time, existing well before the advent of high quality CMS, but after a lot of jostling back and forth, we finally decided that there were systems out there that would accommodate our needs and traffic requirements (which aren't insignificant).

And I'm also posting this to point out one fancy new feature that I've been asking for for years. We can now scrape blogs from other sites! Fact is, we have several users with popular blogs on their own servers or on third-party systems (blogger, wordpress, etc). But since you had to enter developer journal/diary/blog entries right on gamedev's servers, you couldn't list your blog on gamedev without manually duplicating your blog entries.

And, far as I know, the only person who's obsessive enough to do that was me :)

So if you have your blog out on another site (like thecodezone.blogspot.com), you can now keep your blog there and gamedev will mirror it.

Hopefully this will be a big step towards making gamedev better one-stop-shopping for developers documenting their process.5927544581291786949-9052864485742326704?l=thecodezone.blogspot.com

Source
johnhattan
Warning: this is a bigass unordered pile of random technical thoughts.



I'm just trying to collect my thoughts as to how I'd sell Bulldozer on the Chrome App Store so people could pay a buck, slap it on their ChromeOS netbooks, and start playing. ChromeOS has two different kinds of apps, "packaged" apps, which are zipfiles containing a complete copy of everything your webapp needs to run, and it can contain html, js, swf, and pdf. In structure, it's not all that different from AIR. It's just a complete little bundle of stuff to do a web app.

The other non-packaged method is basically just a shortcut to a web-app running on your server. For example, I could build an html page that grabs a bulldozer swf from my site and displays it full screen. Problem there is that that's gonna cost time and bandwidth. I'd much rather have the user copy my game to his machine and then have it run instantly rather than download it every time. Also, I like the user to be able to play without an internet connection. After all, he paid for it and I don't wanna tell the user when he can and can't play a game.



Looking at the documentation, the commerce API is only available to the non-packaged games, so Bulldozer for ChromeOS is gonna be required to run from my servers.

Looks like the process is gonna be something like this:

1. User buys Bulldozer from Chrome web store.2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing.

While this works, it's pretty hard on bandwidth for users and me. The full-retail Bulldozer SWF is about 10 meg (90% of which is stereo music). Normally that's not a problem for my users because I bundle it up as an EXE tht they install to their machine, so it's a one-time hit. If that's gonna happen every danged time they click the icon, it's a problem. Especially if Google wants this thing to work with pay-by-the-byte phone cards.

Mind you, I could do two things to ease up on the bandwidth.

1. I could make things smaller. I could get Bulldozer down to less than 2 meg by compressing the music more and going with smaller and fewer eye-candy animations. Given that this will likely sell for considerably less than the $9.99 I charge for the full game on my site, that'd be understandable.

2. I could cache things up. Apparently ChromeOS has some custom directives in the app-manifest that tell Chrome "this file is part of an app, so don't just dump it from the cache when you get bored", so I could mark bulldozer-full.swf suchly. The problem is then that the user now has a full Bulldozer in his cache and could copy it out, so this swf would need to do a little checking to make sure it was launched legitimately. Since the consequence of having a paid app seems to be that it is necessarily non-packaged, I don't think this'll be a problem.



So I think the sequence would ultimately look like this (as a shortcut):

1. User buys Bulldozer from the Chrome app store.2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing. Note that the SWF might already be cached up, so this step might be skipped.4. When Bulldozer.swf runs, it receives some tokens or it passes some code back and forth to my server to ensure that it's actually been served from the site and isn't just someone double-clicking on the SWF.



Although looking at the documentation, packaged apps DO have access to the payment API, but they say that it's "difficult to do securely". So I could do a packaged app thusly.

1. User downloads Bulldozer, receiving a CRX, which basically contains a static HTML file and a SWF.2. When user launches the "app", it displays the HTML, which has the SWF embedded. My SWF could be passed the user's info, and then I could communicate directly with Google's authentication server to determine if it's being run legitimately.

When Google says "difficult to do securely", I presume they're talking about how someone could take apart the app (since it's all zipped up on a user's machine) and defeat the token passing. And this is true, although SWF can be made considerably more difficult to decompile than obfuscated Javascript. And in either case (packaged or non-packaged), the user will necessarily have my SWF on his machine, and if he's good enough to decompile, defeat my token-passing, and recompile, it won't make much difference which scheme he's using.





So thus-far it looks like the rules I'm gonna have to follow are:

1. Paid games will necessarily have to communicate with Google to make sure they're paid for. The only way paid-for apps can run without an internet connection is if they're running on the honor system where the user pays for the app, gets the CRX, and hopefully doesn't put it on bittorrent.

2. You can package or not package. If you're not packaged, you should either (a) be small or (B) tell Chrome to keep your assets in the cache. And if your assets are static and are rarely updated (as mine are), you might as well be packaged.

3. The only way to securely determine if you've been paid for is to have your server talk to Google's server and then serve content dynamically, although this is impractical if your assets are large and relatively static.

4. You determine if your app's been paid for via OAuth. You can do that on your own server or directly from your client app. If you do it from your client app (i.e. on the user's machine), then you open your fly if you're easy to decompile.



Finally I must note that Flash apps on ChromeOS are running in the sandbox and won't be able to communicate with a site unless it has a crossdomain.xml file that allows that. I don't know if Google's store-authentication server has that. If it doesn't, I'll necessarily have to relay authentication through my own server. Ultimately I'd rather my SWF communicate with Google directly rather than relay through thecodezone.com. I like to follow the "what if I'm hit by a bus tomorrow" rule which roughly translates as "what if thecodezone.com disappears forever tomorrow". People who have my current games can still play 'em as long as they have the installer and unlock code, as I don't do server authentication. If "is my game paid for" requests always pass through thecodezone.com, then it's required that my authentication code exist on my site forever.

Oh well, another thing to think of.5927544581291786949-4119809860422331925?l=thecodezone.blogspot.com

Source
johnhattan
Warning: this is a bigass unordered pile of random technical thoughts.


I'm just trying to collect my thoughts as to how I'd sell Bulldozer on the Chrome App Store so people could pay a buck, slap it on their ChromeOS netbooks, and start playing. ChromeOS has two different kinds of apps, "packaged" apps, which are zipfiles containing a complete copy of everything your webapp needs to run, and it can contain html, js, swf, and pdf. In structure, it's not all that different from AIR. It's just a complete little bundle of stuff to do a web app.

The other non-packaged method is basically just a shortcut to a web-app running on your server. For example, I could build an html page that grabs a bulldozer swf from my site and displays it full screen. Problem there is that that's gonna cost time and bandwidth. I'd much rather have the user copy my game to his machine and then have it run instantly rather than download it every time. Also, I like the user to be able to play without an internet connection. After all, he paid for it and I don't wanna tell the user when he can and can't play a game.


Looking at the documentation, the commerce API is only available to the non-packaged games, so Bulldozer for ChromeOS is gonna be required to run from my servers.

Looks like the process is gonna be something like this:

1. User buys Bulldozer from Chrome web store.
2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)
3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing.

While this works, it's pretty hard on bandwidth for users and me. The full-retail Bulldozer SWF is about 10 meg (90% of which is stereo music). Normally that's not a problem for my users because I bundle it up as an EXE tht they install to their machine, so it's a one-time hit. If that's gonna happen every danged time they click the icon, it's a problem. Especially if Google wants this thing to work with pay-by-the-byte phone cards.

Mind you, I could do two things to ease up on the bandwidth.

1. I could make things smaller. I could get Bulldozer down to less than 2 meg by compressing the music more and going with smaller and fewer eye-candy animations. Given that this will likely sell for considerably less than the $9.99 I charge for the full game on my site, that'd be understandable.

2. I could cache things up. Apparently ChromeOS has some custom directives in the app-manifest that tell Chrome "this file is part of an app, so don't just dump it from the cache when you get bored", so I could mark bulldozer-full.swf suchly. The problem is then that the user now has a full Bulldozer in his cache and could copy it out, so this swf would need to do a little checking to make sure it was launched legitimately. Since the consequence of having a paid app seems to be that it is necessarily non-packaged, I don't think this'll be a problem.


So I think the sequence would ultimately look like this (as a shortcut):

1. User buys Bulldozer from the Chrome app store.
2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)
3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing. Note that the SWF might already be cached up, so this step might be skipped.
4. When Bulldozer.swf runs, it receives some tokens or it passes some code back and forth to my server to ensure that it's actually been served from the site and isn't just someone double-clicking on the SWF.


Although looking at the documentation, packaged apps DO have access to the payment API, but they say that it's "difficult to do securely". So I could do a packaged app thusly.

1. User downloads Bulldozer, receiving a CRX, which basically contains a static HTML file and a SWF.
2. When user launches the "app", it displays the HTML, which has the SWF embedded. My SWF could be passed the user's info, and then I could communicate directly with Google's authentication server to determine if it's being run legitimately.

When Google says "difficult to do securely", I presume they're talking about how someone could take apart the app (since it's all zipped up on a user's machine) and defeat the token passing. And this is true, although SWF can be made considerably more difficult to decompile than obfuscated javascript. And in either case (packaged or non-packaged), the user will necessarily have my SWF on his machine, and if he's good enough to decompile, defeat my token-passing, and recompile, it won't make much difference which scheme he's using.



So thus-far it looks like the rules I'm gonna have to follow are:

1. Paid games will necessarily have to communicate with Google to make sure they're paid for. The only way paid-for apps can run without an internet connection is if they're running on the honor system where the user pays for the app, gets the CRX, and hopefully doesn't put it on bittorrent.

2. You can package or not package. If you're not packaged, you should either (a) be small or (b) tell Chrome to keep your assets in the cache. And if your assets are static and are rarely updated (as mine are), you might as well be packaged.

3. The only way to securely determine if you've been paid for is to have your server talk to Google's server and then serve content dynamically, although this is impractical if your assets are large and relatively static.

4. You determine if your app's been paid for via OAuth. You can do that on your own server or directly from your client app. If you do it from your client app (i.e. on the user's machine), then you open your fly if you're easy to decompile.


Finally I must note that Flash apps on ChromeOS are running in the sandbox and won't be able to communicate with a site unless it has a crossdomain.xml file that allows that. I don't know if Google's store-authentication server has that. If it doesn't, I'll necessarily have to relay authentication through my own server. Ultimately I'd rather my SWF communicate with Google directly rather than relay through thecodezone.com. I like to follow the "what if I'm hit by a bus tomorrow" rule which roughly translates as "what if thecodezone.com disappears forever tomorrow". People who have my current games can still play 'em as long as they have the installer and unlock code, as I don't do server authentication. If "is my game paid for" requests always pass through thecodezone.com, then it's required that my authentication code exist on my site forever.

Oh well, another thing to think of.
johnhattan
It's just a minor update, but the games have required so few updates that it's newsworthy when it happens. I posted an update to the Windows versions of Bulldozer and Duck Tiles that takes care of a problem saving your settings if your Windows username contains non-Latin characters.

If you've experienced a problem saving your settings in Bulldozer or Duck Tiles, you might want to check out the updates. Thanks!5927544581291786949-5476706780922180515?l=thecodezone.blogspot.com

Source
johnhattan
Wow, it's the first time in 12 years that I went an entire calendar month without blogging. I've actually been finding myself with less to say as the years go on. I'm reading more, writing less, and almost never listening because there's very little worth listening to. My TV viewing is now pretty-much restricted to Breaking Bad (which is gonna be a problem because I'm almost caught up and new episodes ain't coming out for six months) and reruns of iCarly.


[/angryoldfart]

I actually do have a couple of mentions money-wise. It's now the end of the year, which means that you should read my blog entry from last year about getting your credit reports. Suffice it to say that there is one way that is actually free and a dozen ways that pretend to be free but will end up charging you a lot of money. So don't be stupid.


Next is a little discovery that Shelly and I found, and it's really only useful if you have kids. Paypal has a "student account" that you can get at https://student.paypal.com. Basically it's a sub-account of your own paypal account. It has its own login and password and it works very similarly to a standard paypal account, except that rather than link to an external bank account, it links to your own paypal account and it exists as a "child" of your account.

It's also got a few handy features:

1. You can set your "main" paypal account to make regular automatic payments into it, ala allowance.

2. You can get a debit card for it.

3. It's got parental controls, so you can decide if your kid can send and/or accept money without your permission.

4. You ultimately have control over the balance, so you can yank your kid's money right back outta the account if they're abusing the privilege.

And that's worked brilliantly for Maggie as far as teaching her to be responsible with money. We have it set so it'll deposit a few bucks for her allowance every Friday. She can (and does) go to paypal.com, log in, and check her balance whenever she wants. If she wants to buy something online, then she can talk to me and we'll buy it together (responsible parent that I am). And if she wants to buy something locally, then she can buy it with the debit card (which I keep in my wallet, thankyouverymuch).

And it's really doing the job of teaching her about money. For example, last week she found some "Silly Bands" (funny shaped rubber bands) at Wal Mart that she wanted, but she decided that it wasn't worth it because she was saving up for some better stuff and just spending her allowance on frivolous junk sets you back from getting something really cool.

It's also a good pride thing. A couple of months ago, she finally got enough cash to buy a Nintendo handheld. She'd been keeping an eye on prices, so she knew where they were cheapest and who had pink ones available. And you can bet she told everybody in the freakin' store that she'd been saving up and she was buying this expensive toy WITH HER OWN MONEY!

And it also helped on a recent trip to Disney. Rather than have her pestering me to buy T-shirts and toys when we got to Disney, I paypal-ed her a few extra dollars "vacation cash" and told her she could buy anything she wanted. And she did spend some time looking for exactly what she wanted.

And what did she end up getting?

Yep, a mouse-ear hat with her name embroidered on it.