So I spent a bit of extra time this week messing with my Lua on Javascript stuff for game jams. Here’s the resulting game Turkey Tomahawk Turbo.

I checked out the following Lua on Javascript implementations: lua.vm.js, lua.js, and lua5.1.js. I also made a fork of lua.js called lua.js-phil.

Here’s the short summary breakdown:

– lua.vm.js: An asm.js (emscripten) port of Lua 5.2. It has slickest web presence, but WORST implementation. It’s crazy buggy and doesn’t work for anything beyond the cool tech demo. If you really like what they have so far, you’ll want to spend a week or so fixing their API so it actually works for non-trivial programs. I never got my game working fully with this due to sporadic runtime errors and other mess.

– lua.js: A script that converts your Lua script to Javascript. The official distribution works great, but it is missing some functions so you’ll may have to modify your program somewhat to work without those functions. (The string formatting and pattern matching is not implemented.)

– lua.js-phil: A fork of lua.js. I added string.format and improved performance by making the following assumptions: you will not use meta-methods (__index, __call) for anything but calling functions / methods. You will not use the math meta-methods (__add, …).

– lua5.1.js: An asm.js (emscripten) port of Lua 5.1. It has a very nice working API that is exactly like the C API, so if you are used to integrating Lua in C, you’ll find it pretty easy to integrate with your Javascript program. It is a build of Lua 5.1, so no missing functions or other quirks.

Here’s the performance data in FPS. For comparison, with Lua running on my Mac, I got 400 FPS.

So to conclude, lua5.1.js would be my preference, except asm.js code takes a horrible performance hit on Safari, and a non-trivial performance hit on IE. Once all browsers are optimized to work with asm.js code, that would be the best option for sure. Since I was able to modify my game (about 5 lines of code different) to work with those restrictions I mentioned above, I was able to get pretty good performance with my fork of lua.js. The original lua.js is quite good, short of the missing functions.

Lastly, there have been many claims of how “you’ll get near native performance using javascript, especially now that we have asm.js and emscripten” and whatnot. Well, I’m sure in theory that’s great and all. But no matter how I slice it here, I’m getting a 4x+ performance hit by running my games on the web. Still I’m impressed by what I’ve seen and I hope more work goes into getting asm.js support in browsers so we can get nearer to native performance!

-Phil

P.S. You can download the whole mess with build scripts and the various Lua things here.

I’m pleased to announce Turkey Tomahawk Turbo!

I made it for the Charity Game Jam this year!

So check it out Windows or Mac or Linux! And now on the Web!

Have fun!
-Phil

Earlier this year I realized I was a little bit overweight. Here’s a pic from 2002 when I was at the high end of overweight. I never want to look like this again:

So with that in mind, I always am working to fend off the weight gain. A year and some ago, I put myself on a bit of a diet / hiking regime. This worked pretty well until I got really busy with work again and I gained back 10 lbs in a few months. Seeing how I was about to dive into a big project and I was already overweight, I knew I had to do something.

I decided to outsource “thinking about fitness” to BeachBody. I realized one of the problems was, with my focus so directed on my work, I didn’t have any mental strength left to actually make myself get in shape. BeachBody has been doing the home workout video thing for ages, and I have a few friends who have used their products before, so that played a role in my deciding to get into it.

Another big thing was they had just come out with a new series called “Focus T25” which really appealed to me. I had checked out a few of their workouts before, and they often had workouts that varied between 15 minutes and over an hour, so you never knew how much time it was going to take every day. Not cool. T25 is ALWAYS 25 minutes.

BeachBody is really smart with how it gets you to get in shape. So let me break down a few of the things it does, gamification-wise.

– They encourage you to be in an group with a few other people. This helps add a bit of social pressure to the experience and makes you feel less alone. Because, you are alone when you do workouts in your living room. Encouragement is done via their website, and sales. You actually get an extra free DVD if you buy the workout through a “coach” (reseller.) The coach is supposed to get you into a group and encourage you. This worked pretty well. It happened all on Facebook, so that makes sense.

– They include a chart for you to check off daily if you’ve done your workout. This is nice, very “daily challenge oriented.”

– They include a diet plan, but basically they say “1600 cal per day” … I ended up just working out my own meal plan, because most of theirs was too complicated. But the inclusion of the meal plan definitely drives home the importance of keeping with some sort of diet if you want results.

– The characters they chose for the videos (Shaun T, and 4 others) seem to be good picks for bringing the pressure right into your living room. I have a projector set up, so when I do my workouts it’s pretty much like being in a gym with them.

– Every Saturday they have you record your weight. This was great, because it avoids the day-to-day roller coaster of weight fluctuation and gets you looking at the long-term progress. So you don’t get discouraged by any single-day set backs.

– The final challenge is getting through the 10 week program and submitting before and after pics and before and after stats. You get a T-shirt if you do this. Definitely achievement unlocked type stuff here.

So my results were this:

– It took me about 16 weeks to get through the program, I had lots of travel and things going on, so I wasn’t able to just power through it in 10 weeks.

– I dropped 14 lbs over the course of the program.

– I found the whole thing worked well, I just had to track my calorie intake, do my workouts, and I made sure to go outside and hike as often as possible. I probably averaged over 10 miles a week.

– I am no longer overweight.

I’ve been crazy busy the past 5 months but having outsourced the thinking part of getting in shape really worked for me. I’m currently working through the program again to shave off a few more pounds. Here’s the way I look at it. I watch probably 2.5 hours of movie/TV every night. So ~30 minutes a day for 5 days a week is like 2.5 hours. So doing this routine is equal time-wise to ONE night of mindless entertainment. Hardly a heavy price to pay for fitness.

While in some ways, I outsourced my fitness planning to BeachBody, I also learned the key lesson they teach: if you want to get in shape you have to do it yourself.

-Phil

Through a bit of Googling and whatnot, I got in touch with Joe Delgado who was able to provide a patch to fix ENet to work with Marmalade. These are modifications to unix.c. When I am making a Marmalade build of my games, I always have PLATFORM_MARMALADE defined. So you can replace that with whatever you do.

After the #ifdef __APPLE__ segment, add this to set up the correct defines, etc.

#ifdef PLATFORM_MARMALADE
#define SOMAXCONN 128
#undef HAS_POLL
#undef HAS_MSGHDR_FLAGS
#undef HAS_FCNTL
#include <sys/select.h>
#include <sys/uio.h>
#define HAS_SOCKLEN_T
#endif

In enet_socket_send, it turns out the Marmalade sendmsg is broken. So I replace:

    msgHdr.msg_iov = (struct iovec *) buffers;
    msgHdr.msg_iovlen = bufferCount;
    sentLength = sendmsg (socket, & msgHdr, MSG_NOSIGNAL);

With

#ifdef PLATFORM_MARMALADE
    // concatenates buffers together

    ENetBuffer * newBuffers;
    char* d;
    int i, totalSize;

    newBuffers = (ENetBuffer*)malloc(sizeof(ENetBuffer));
    totalSize = 0;
    for (i=0;i<bufferCount;i++) {
        totalSize += (buffers+i)->dataLength;
    }

    newBuffers->data = malloc(totalSize);
    newBuffers->dataLength = totalSize;
    d = (char*)newBuffers->data;
    for (i=0;i<bufferCount;i++) {
        memcpy(d, (buffers+i)->data, (buffers+i)->dataLength);
        d += (buffers+i)->dataLength;
    }

    msgHdr.msg_iov = (struct iovec *) newBuffers;
    msgHdr.msg_iovlen = totalSize;

    sentLength = sendmsg (socket, & msgHdr, MSG_NOSIGNAL);

    free(newBuffers->data);
    free(newBuffers);

#else

    msgHdr.msg_iov = (struct iovec *) buffers;
    msgHdr.msg_iovlen = bufferCount;
    sentLength = sendmsg (socket, & msgHdr, MSG_NOSIGNAL);

#endif

And that seems to get ENet working 100% with Marmalade. I applied this patch to ENet 1.3.6 … The original patch was written for ENet 1.3.3, and I suspect it would work for the latest version of ENet. I built this with Marmalade 6.3.2. I’ve passed on a request to the Marmalade team to fix sendmsg so that the larger chunk of the code would no longer be necessary.

-Phil

One of Nan and my favorite TV mini-series is Return to Treasure Island (starring Brian Blessed). If you don’t have it, you can buy it here. (Region 2 DVDs only.)

We watched it again this past week, and this time we made a drinking game to go along with. We used peanut M&Ms and went through about 2 pounds of ’em! Here are the rules in full, have fun! Download/Print PDF.

Return to Treasure Island (Brian Blessed) Drinking Game

If you’re teetotalers like us, or under age, use M&M’s instead. It has the same effect if you play for long enough.

Take a shot when …

• Someone gets knocked unconscious
• Someone mentions “slipping their cable”
• Someone mentions “diamonds, rubies, and sapphires”
• The map changes hands
• The map is hidden
• Long John fights someone with his crutch
• Long John bribes, flatters, or threatens someone
• Jim is captured
• Jim tries to flirt
• Jim appears shirtless
• Ben Gun taps his nose or whoops
• Van Der Brecken mentions “a plan”
• Van Der Brecken kicks
• Van Der Brecken expresses his dislike or distrust of Long John
• Rev. Morgan mentions “the Lord”
• Trelawney says “What?”
• Keelhaul cackles

So, if you’ve been following this blog for a while (like a year) you might recall last year’s “October Challenge” game called “Stealth Target” that I attempted to release as a paid beta game, which I then issued refunds for and then made a few vague efforts to revive and .. well ..

I mean, it looks, sort of okay. Those dynamic lights are neat stuff, man I learned a ton about OpenGL and tricks doing this game. The trouble is, since it is a 3D rendered game, when you stick it next to shots of (links to any recent Unity game on touchArcade left as an exercise to the reader) it looks awful. “Why is this dev even bothering?” Coupled with the fact that the interface was a bit kludgy using a mouse and at least twice as bad using touch, it just wasn’t a great fit for, well, anything sadly. To finish the project it would take me at least 3-4 more months of serious work and I don’t expect that I would be happy with the final result, so I had to kill it.

.. But I had written some keen code. And I still liked the game concept. So I thought about it a bit more. I had made another game a ton of years ago called Escape from Anathema Mines. It was a similar “dodge the guards” type of game with an overhead visual aesthetic that actually worked pretty well.

I thought it over and decided that with some of the GL experience I had acquired while working on Stealth Target, and by going in the direction of the overhead view that worked so well in that game, I could re-mix the two games together and create something new and exciting and simple enough that I could get it done. After just a few days of work I’ve already got a OpenGL / HD playable of Escape from Anathema Mines.

I’m going to extend the game with some of the bomb concepts from Stealth Target and maybe top it off with some other wacky features. This game is much easier to work on for the primary reason: it isn’t in 3D. Not being in 3D just makes rendering and working on it so much easier. One thing that also helped getting this up and running quickly was being able to reuse a ton of the code / algorithms that I had already written for Stealth Target.

I also been learning about the Object Component model over the past year and I’m using this game as my first attempt at it. I went to a talk at 360iDev (check it out) and got a very nice overview of the model. But the BIGGEST point he made that worked for me was when he said, “It doesn’t really matter how you do this, as long as it works for you. You won’t make a perfect model, so just make one that gets the job done and don’t feel bad about it.” Which was really liberating for me, I’ve always felt it was supposed to be some perfectly coded model, and being allowed by someone to just “get the job done” really helped. I was able to use the things I learned in his talk to help my code without having to do weird stuff that wouldn’t work with my style of coding. I have everything in a single structure named Entity. Really simple, but the thing I also do is have a bunch of bools like “has_light” “has_position” and then more members like “position_x, position_y, light_a” and so on. That way everything is always there (very C) but it’s component oriented (I can test if a component is there and take action on it if it is.)

Here’s the level editor, which is actually is very similar to the one for Stealth Target, only .. since the game is actually an overhead game, it was a ton easier to get working.

So, yeah. I’m enjoying doing this project. It’s actually my “hobby project” which means I’m only allowing myself to work on it during off-hours. I will probably attempt to monetize it somehow, but my main goal with this project is to satisfy my need to get these game ideas out the door and see how they come out. I’ve got my main work hours dedicated to some of the other commercial projects I’m working on this year.

Which I should talk about more soon. A lot more.

-Phil

Hey,

I’m the dev / admin behind the Ludum Dare 48 hour game developer competition. This past weekend our competition grew from 350 contestants to 600 contestants thanks to @notch. Not only that but his live video blog of the event and twittering drove a TON of people over to the site just to spectate the event. This led to a ton of press coverage on. In short, 48 hour game development BECAME a spectator sport. Which is totally not something I had anticipated – here’s a completely inaccurate motivational poster I created a few years ago:

Anyway, that wasn’t the case, and this is what happened. (Short version: $8 shared hosting server burned to the ground and we got kicked off and had to find greener pastures, and then do a ton of optimizing.) I want to give a shout out to Mike Kasprzak for keeping the masses at bay and helping to endlessly test the site and hold my hand while I worked through all the mess. Here’s the lessons learned:

1. Profile site database use.

You can find out what queries are killing your site by using the WPDB Profiling plugin. This was a HUGE deal for us. We were able to see exactly what queries were destroying us. Without any debate this is the #1 tip I have, because if you don’t know what the problem is you can’t fix it!

2. Remove inessential plugins.

Not all WordPress plugins are developed with massing scaling in mind. We found by disabling all the plugins except for the essential plugins we were able to go much faster. Not only that but even efficient plugins add a CPU drain to the site just by having their PHP files loaded.

3. Clear out the sidebar.

Sidebar stuff can also be a huge drain. We just plain removed the sidebar for the competition. We’ll probably re-enable some of it eventually, but be careful, even some of the WordPress issued functions have some monster queries in them.

4. Optimize slow 3rd party plugins.

One plugin we wanted to keep using I like this is really cool, but it uses a table that is not indexed and it adds an extra query per-post on the front page of your site. I indexed the columns in the custom table it had as well as removed the unnecessary per-post query it was issuing. Now we can use that cool plugin without any notable slowdown. Here’s my bug report / patch.

5. Add in custom caching to 3rd party plugins.

Our custom competition plugin was really un-optimzed. I had written it to just work, and it worked great under low load. I used a number of techniques to reduce the load:

– I added in my own mini profiler so I could track how often certain functions were being called and how long they were taking. This helped me track down the issues to an even finer detail than I was able to with the WPDB Profiling plugin.

– I was using the get_userdata($uid) function from WordPress as many as 600 times on a page, so I cached that data with the records in my database so I would almost never have to call it, that was probably the biggest issue and was causing 600 database queries on those pages.

– I added paging to the various views so that instead of seeing all 600 entries at once, you only see 24 at a time, this really reduced load in terms of queries and images being loaded off the site in one request.

– I also added some page caching for the few pages that calculate results, this is largely a CPU save because generating those pages is pretty intensive

6. Be smart with 3rd party caching solutions.

Pre-made caching solutions for WordPress can’t save you if your site is largely driven by custom plugins and signed-in users using web apps (like our compo system), in fact those caching plugins actually can slow down the site quite a bit. They are designed more for static content blogs (which is more typical for blogs) and probably work great for those, but for us they didn’t work so hot.

… Conclusion.

I’m now quite happy with how the site is performing. We’ve reduced the load on our new VPS from 70 or so (meaning that we had about 30x as many processes wanting to use the CPU as the server could handle) down to about 0.5 which means we’ve got room to handle spikes again. I hope 🙂

-Phil

Hey,

So, I’m joining forces with a few other indie game developers to post some short youtube videos talking about being an indie game developer. It’s called “indie indie conversation“. Be warned, though I keep it pretty SFW, not everyone else does.

Cheers!
-Phil

So, hey, we recently (3 months ago) moved to “the goat ranch” and I finally got around to decorating my office. Since moving in, I’ve released one game and I’ve got three (or so) in the works. So a lot of stuff is going to be happening here this year!

Everything in that picture has got some sort of anecdote behind it, so if you’re curious about anything, just ask 🙂

-Phil

So, I just sent out my “hey everyone, come get a refund” email to all the people who purchased the Stealth Target beta. There are a number of pretty high-profile indie games that have built an entire business upon being a paid beta. Minecraft, Wolfire’s Overgrowth, Data Realm’s Cortex Command are a few that come to mind.

Here’s some analysis on the subject, and why it didn’t work for Stealth Target .. and at the same time, the factors I think that would be important to having a successful paid-beta project.

• Commitment to a larger vision. In the case of Stealth Target, I had a larger vision, but I eventually realized it was too grand for me to realize.  I’m more of a small-scale game kind of guy at this point.  Perhaps later in my game development career I’ll be doing larger projects, but right now, a “Galcon-sized” game is about as large as I can manage.  I think paid-beta games need to be larger to justify the whole “user-buy in to help fund an epic game” concept.
• Commitment to regular updates. I’m only one dev, and when I take a month to work on Galcon updates, and then take another month to take a break, suddenly the beta users haven’t heard a peep from me about the game in 3 months.  Pretty weak “paid beta”.  If I had a team and I had someone always working on the beta so it kept living despite my other obligations / plans, it might have gone better.
• Building a development team. Yeah, I just touched on that, but it really does make sense.  I could have a team, but my lifestyle doesn’t allow for it at the moment.  My hours are too random and my work schedule too unpredictable.  To have a team you have to have some consistency in your life, otherwise (I’m pretty sure) your team-members will get pretty tired of you.  I think having a team would help deliver the quantity and quality of content and updates to make a paid beta make sense.
• You can’t change your mind and be crazy. I still plan on finishing Stealth Target, however, I’m no longer planning on doing a desktop release of the game.  The paid beta was for a desktop version of the game.  So changing to a iOS-only plan really isn’t possible.  The only way to cleanly resolve this was to terminate the entire beta and issue refunds.  Really, for a paid-beta to make sense, the users have to have something they can depend on, and changing platforms mid-stream is just asking too much.

Anyway, to wrap it all up, here’s the email I sent out to folks who already bought the game today:

Hi,

Turns out the business model of doing a pre-beta-sale really doesn’t make sense for me.  I’m more of a “do what I feel like” kind of guy, and committing to making some sort of super-great-game in some kind of pre-beta-sale promise just isn’t something I can really do.  I think in the case of “Stealth Target” I bit off way more than I can chew.

I’m hoping to finish Stealth Target this year, but I’m probably only going to release it to mobile platforms, so I don’t even think I’m going to be launching a desktop version.

Either way .. I’m offering refunds to anyone who wants one!  Just reply to this email and say so.

Thanks for coping with a crazy indie-dev 🙂  Your support is greatly appreciated and I hope I can churn out some cool games that you’ll enjoy in 2011!

Cheers!
-Phil

P.S. Also, thanks for all the feedback you have given me so far on Stealth Target.  I’ve been taking notes on just about everything! You’ve been a huge help!

And, who knows what the future will hold for Stealth Target.  If the mobile version comes out feeling really good, I might try and release it for the desktop.  But the important thing for me is to know that I’m not obligated to produce a “desktop-sized” title when I’m really making a “mobile-sized” game.  I’ve got a lot of things I want to do this year, and I want to do them in the order that I want them to.  A paid-beta project would have “cramped my style” so to speak, and I don’t want to subject my users to a shoddy paid-beta experience.

Thanks!
-Phil