Old Flash Version, for Comparison

I also put up my old flash version of CTYR. The high score stuff no longer works, naturally, but you can see the game itself, which is surprisingly almost identical to the new Java version.

Which of course brings up a good question: why in the world am I rewriting CTYR?  Does the world need another version? Are there new features?

As you will have surmised, CTYR is my sandbox game.

As a result of CTYR’s new version, I now have a nice little Java library of stuff I need in various games.

I even figured out how to put it in a separate project in Eclipse. Yay for me!

Next step, after figuring out how to get CTYR’s java version into an Applet, is another swell game: JetLag!


$_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.


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.