Jump to content

  • Log In with Google      Sign In   
  • Create Account

The Code Zone Bargain Basement Blog



New project part two

  Posted by , 24 February 2011 - - - - - - · 230 views

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.

Posted Image

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?https://blogger.googleusercontent.com/tracker/5927544581291786949-865814893269699073?l=thecodezone.blogspot.com

Source


On the book section

Posted by , 31 January 2011 - - - - - - · 441 views

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, http://www.gamedev.net/books



My new project

  Posted by , 24 January 2011 - - - - - - · 314 views

Okay, I hinted on it on <Insert Social Network Here> 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 &LT;Insert Social Network Here&GT; 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 &LT;Insert Social Network Here&GT; 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.https://blogger.googleusercontent.com/tracker/5927544581291786949-7590652973484458809?l=thecodezone.blogspot.com

Source


New gamedev!

  Posted by , 09 January 2011 - - - - - - · 261 views

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.https://blogger.googleusercontent.com/tracker/5927544581291786949-9052864485742326704?l=thecodezone.blogspot.com

Source


Chromium App Store thought-collection

  Posted by , 10 December 2010 - - - - - - · 211 views
import_rss
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.https://blogger.googleusercontent.com/tracker/5927544581291786949-4119809860422331925?l=thecodezone.blogspot.com

Source








PARTNERS