Additional Mac Woes

So, I reinstalled OSX. It took hours, as the installer kept having some sort of error somewhere in theinstaller. I disabled everything except for the absolutely required items, and it finally worked!

And then I went to download the iPhone SDK!

And then I found out that I need Snow Leopard, and I only have the non-Snowy Leopard!

Yesterday, Best Buy was closed (and I’m not interested in paying $4 for shipping), so I have to go and buy a new cat today, because my cat is no longer good.

In the meantime, I started putting together the software I wanted on the mac. I put in pixen, openoffice, xcode, qt, haxe, and scratch.

And yesterday evening, I spent some time trying to reacquaint myself with Cocoa and Interface Builder. I managed to wire up some buttons and textboxes.  I was able to nurse the ailing and little used IBOutlet neurons back to health.

I ended the evening trying to work with an NSOpenGLView. I found a set of tutorials to follow.

The Click Me Challenge – Haxe Edition

Welcome to The Click Me Challenge – Haxe Edition.

If you are unfamiliar with this challenge, I point you to:

http://andrewwooldridge.com/blog/2009/11/12/the-click-me-challenge/

http://davidbarneswork.posterous.com/click-me-challenge-should-replace-hello-world

This is the Haxe/Flash edition of the Click Me Challenge, where I will take us step by step through the process from absolutely nothing to a version on par with the reference implementation.

Ramping up for some Haxe development

The problem with all of the various development “platforms” that I use is that once I return to one with which I don’t have a decent history, I have to go back to some of the basics and review them.

I have a really good history with JavaScript/HTML and C#/WinForms since I use them a lot. When I am working with C# in Silverlight or XNA, there are aspects of Silverlight or XNA that I am often looking up.

In doing Haxe development, the vaguely ecmascriptish language I get used to rather quickly. I still think that the Haxe for look is a bit bizarre but I’m not here to judge.

My target language/platform is Haxe/Flash. There are a number of foundational tasks that I need to be able to do, some of which I vaguely remember, and some that I completely have never done in the Haxe/Flash combination.

I have an environment (currently lying fallow) that will enable building with Haxe and SwfMill.  I have to review the syntax of SwfMill xml files.  I do not need SwfMill for much, only embedding sounds and images. I do not go above and beyond this. I like things simple.

In Haxe/Flash I mostly remember how to load in the images and the sounds. I’ll have to do a quick sandbox prototype to recall the exact syntax, but after that I’ll be good to go.

I’m starting to think, though, that for my own benefit as well as for others, it behooves me to document and publish these various sandbox prototype endeavors, so that I can be reminded later on how to do this, and perhaps others will benefit as well.

I also happened to find a couple of these types of sandbox prototypes at http://haxe.org/file/Professional-haXe-and-Neko-code.zip (direct download link).  Chapter 12 has the Flash stuff, and makes rather trivial examples of each item.

As I go along, I’m going to share the various sandbox prototypes.

$_SESSION Looks like a winner!

So, I’ve been looking into $_SESSION as the way of perpetuation data across web pages, now that I’ve got the site into PHP.  Very likely there will be session data flying around when moving between pages on PlayDeez.com.

Of course, there will be no content associated with having a session. Its the plumbing for future expansion, and I think a reasonable first target is the Silverlight Jetlag, since it is a smallish code base, and it is relatively easy to get my PHP session data into the object via a <PARAM>.

I’ve also been reading into getting a Silverlight application to call another webpage silently. After reading the documentation on it, I must say that it is a whole lot easier doing this from Flash or even simply JavaScript.

I also need to start investigating getting information from a FlashVars param into Haxe. I’m going with a lower flash version(7) because I want compatibility with the Wii browser and potentially other flash lite devices.

The first Haxe target is CTYR. I’m going to take the art assets from the Yahoo! Widget I made of this game.

HamQuest: Server Side

So I’m now getting to a point with HamQuest where I can start to look at the server side stuff. For the most part, the server side portions are merely those of statistics tracking. For example, the game will have a record of how many lovely hams have been picked up, how many skeletons have been killed, and how many potions quaffed.

But as is usual with this sort of idea, I want to check it out on a smaller scale game with fewer statistics. Something more along the lines of Click The Yellow Rhombus. I’m also not interested in using my old user system, nor in creating a new user system to use with these games, and so I’m probably going to go with Facebook, who will nicely deliver me a userid depending on who is logged in, and I don’t have to worry about that stuff.

In CTYR, there are only a few values to track: Hits, Misses, Score, Number of Games Played. I would track these on a daily basis per player, and keep only the last thirty days of information. I can then show reports depending on the last 24 hours, the last 7 days, and the last 30 days, and have rankings for each category.

But beyond rankings, which are good for a game, but people will lose interest after a short time, there needs to be some sort of incentive system, and the incentives need to be rule bending.

So, if I go with an experience point system, one game of CTYR earns the player 1 XP.  After a certain threshhold, he reaches a new level, and gets a number of cheater points he can use to buy advantages, like 10 free hits in his final score of CTYR, or eliminating 10 misses, or whatever, but some sort of advantage that he can purchase with his cheater points.

The XP based system is all cool and stuff, but there needs to be another way to earn cheat points. Each day must have a high scorer, and whoever gets that high score gets a cheat point.

So, two ways to incentivize: play a lot, and earn new experience levels, or do really well compared to others, and bypass the grind.

Which always leads to the third manner of getting cheat points, which is paying for them. I don’t have any current plans, but that’s how these systems ultimately work, and I’m not forgetting that.

In order to make this work, I will need a Facebook enabled, MochiAds enabled, Server side talking version of CTYR in Flash written in Haxe and interfacing with PHP and MySQL, with this simply being a straw man test for its eventual incorporation in HamQuest.

Does this mean that HamQuest will need to be written in Haxe? Maybe.

Smoothe Scrolling JetLag

http://www.playdeez.com/deleteme/jetlag2009.html

Written in Haxe, for any who might be interested in that information.

Need to click the game before playing, so that keyboard focus gets handled properly.

Space bar to start or restart the game.

Arrows to change direction.

Yes, the tail movement isn’t right.  I’m working on it.

Also, now that the game is smoothe scrolling, your normal jetlag reflexes won’t work, as hit tests are very sensitive.

Good luck.

A Foray Into Haxe

When I look back on the various things I’ve written over time, I can see that a person might get the idea that I’m like Jeremy the Crow from the Secret of NIMH.  (I’ll give you bonus points if you get that reference without having to research it.)

Today, I started evaluating Haxe for use as a development environment for games.

First, a word about Haxe.  It will make applications for multiple “platforms” (I know that some folks object to the word platform in this sense.  I also don’t care what some folks object to.), which include JavaScript, Flash, Neko, and PHP.  I had to look Neko up, decided I didn’t care about it today, and looked at Javascript and Flash.

I discovered that while Haxe can be used to target these several types of output, the idea that you will write code a single time and simply switch what you are compiling it for is a laughable pipe dream.  It uses different APIs based on your output, so if you make something that targets flash, you won’t be able to compile it for javascript, and so on.

Not to say that you couldn’t write the core of the game without either API, and then writen the rendering code specific to the platform, but that’s the same no matter what multi-platform language you are using.

For flash output, Haxe takes care of the code part. The image resource portion (which is paramount in the game of HamQuest) has to be stored in a separate resource swf that the haxe compiler can bring in and use.  Fortunately, swfmill exists and is pretty simple to use for a quick little resource swf.

I built the quick “Hello World” app. Worked.

I built the quick “Draw a Rectangle” app.  Worked.

I built a quick “Show an image loaded from a resource swf”. Worked.

The only thing I have left to do is ensure that I can get keyboard input, but based on what I have seen as examples elsewhere on the web, it looks like I can do it just fine, but I’m not going to assume anything prior to getting really started.

As far as the Haxe language itself: its yet another CBL (curly brace language), and reminds me of every other CBL I’ve used.  Seriously, the various features of the language reminded me of features in other languages, joined together into this mongrel language.  I can easily see the influence of Java, JavaScript, ActionScript, C#, C++, and C.

Additionally, there are a couple of weird wrinkles Haxe has of its own (or at least, I haven’t seen these exact language features anywhere else).

First, the “for” loop isn’t the normal structure of “for(index=0;index<10;++index)”, and instead looks like “for(index in 0…9)”, and additionally has iterator objects that can be used in place of the 0…9 construct.  Basically, this is similar to the JavaScript “for(var i in obj)” construct, and basically means all “for” statements are really “foreach” statements, which I can deal with.

Second, the enums are kind of weird, but in a way that is potentially very powerful.  Time will tell if and when I make use of their flexibility.

Thirdly, in addition to being able to make instant objects “var obj={“x”:10,”y”:20};” as in JavaScript, there is an extension to this that allows a shorthand kind of inheritance.

So my initial impression is: Haxe is a mongrel CBL (which isn’t a bad thing) with a “funny” for, and a few quirky features I’m likely not to use, at least not initially.