Phil Hassey - game dev blog
Phil Hassey as Rambo
".. I've been there,
I know what it's like,
and I'll do it again if I have to."

Archive for the 'galcon' Category

Android Day 2: The NDK

Wednesday, July 21st, 2010

The goal today is to get the Galcon codebase to compile using the NDK.  This will create a single .so file which will be accessed via JNI.

Step 1 – Downloading the NDK:

Download the NDK for native C/C++ code.  I plan on doing as little Java as possible, so I’m going to find out how well this stuff works.

http://developer.android.com/sdk/ndk/index.html

Step 2 – Building a NDK sample:

Trying to build an NDK sample.  I went into ndk/samples/<whatever> and ran ../../ndk-build (as per instructions in previous link).  This worked fine.

But when running in Eclipse, I had some trouble with some examples, but not with some of the other ones.  I’m not sure what that is about, but for now I’m going to forge on and not worry about it.

Step 3 – Preparing my project for the NDK:

I’ve created an android folder in my Galcon project for storing all this ports info.  I’ve created

android/jni/ # a folder

android/jni/Android.mk # a makefile containing

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := igalcon2
SRCDIR := ../../src
LOCAL_CFLAGS := -DANDROID_NDK \
-DDISABLE_IMPORTGL \
-DHAS_SOCKETLEN_T \
-DBUILD_IGALCON2 \
-DBUILD_ANDROID \
-DGC_BUILD_ANDROID
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/../../src \
$(LOCAL_PATH)/../../src/igalcon1 \
$(LOCAL_PATH)/../../src/igalcon1/enet
LOCAL_SRC_FILES := \
importgl.c \
$(SRCDIR)/main.cpp $(SRCDIR)/data.cpp $(SRCDIR)/driver-sdl.cpp $(SRCDIR)/timer.c \
$(SRCDIR)/game2.cpp $(SRCDIR)/level.cpp $(SRCDIR)/mygl.cpp \
$(SRCDIR)/menu.cpp $(SRCDIR)/theme.cpp $(SRCDIR)/myview.cpp $(SRCDIR)/pause.cpp \
$(SRCDIR)/settings.cpp $(SRCDIR)/multi.cpp $(SRCDIR)/help.cpp \
$(SRCDIR)/igalcon1/server.c \
$(SRCDIR)/igalcon1/game.c \
$(SRCDIR)/igalcon1/level.c \
$(SRCDIR)/igalcon1/states.c \
$(SRCDIR)/igalcon1/engine.c \
$(SRCDIR)/igalcon1/menu.c \
$(SRCDIR)/igalcon1/missions.c \
$(SRCDIR)/igalcon1/net.c \
$(SRCDIR)/igalcon1/multi.c \
$(SRCDIR)/igalcon1/client.c \
$(SRCDIR)/igalcon1/web.c \
$(SRCDIR)/igalcon1/timer.c \
$(SRCDIR)/igalcon1/md5.c \
$(SRCDIR)/igalcon1/viewgl.c \
$(SRCDIR)/igalcon1/enet/*.c
LOCAL_LDLIBS := -lGLESv1_CM -ldl -llog
include $(BUILD_SHARED_LIBRARY)

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := igalcon2

LOCAL_CFLAGS := #VARIOUS C FLAGS for define hacks

LOCAL_C_INCLUDES :=  #VARIOUS INCLUDE FOLDERS, RELATIVE TO android/jni/, so ../../src

LOCAL_SRC_FILES := #The c files, ../../src/whatever.c

LOCAL_LDLIBS := -lGLESv1_CM -ldl -llog

include $(BUILD_SHARED_LIBRARY)

android/default.properties # a file needed to build properly

this file must contain:

“target=android-4” for GLES

It instructs ndk-build which platform we’re using.  Without it, the NDK can’t find the GLES headers.

Then I was able to run ndk-build while in the android folder and it started building my project.

Step 4 – OpenGL Includes:

I had to manage some various quirks in the C code and whatnot as I went.

The includes for GLES:

#include <GLES/gl.h>

#include <GLES/glext.h>

Step 5 – Installing a port of STL for the NDK:

Then I found that STL is not supported in the NDK.  So I grabbed stlport from www.stlport.org .. Not needing iostream, etc myself, I just moved the stlport folder over so I could include templates from it.  This gave endianess and compiler unrecognized type errors.  Found this android specific STL port (should be patched into newer versions of stlport eventually.)

http://www.anddev.org/viewtopic.php?p=29939

I had to add this to my CPPFLAGS: -D_STLP_USE_SIMPLE_NODE_ALLOC to avoid having it complain “stlport/stl/_alloc.h:210: undefined reference to `std::__node_alloc::_M_allocate(unsigned int&)”

From here it looks like a long way till I have a port working though.  I need to get graphics rendering, touch input, keyboard input, music handling, and other little things that just make the game work.  If anyone can give me tips on this tonight, feel free 🙂  I’m not excited about using JNI for all this.  I’ve heard there are SDL ports, which I’m going to be considering.  I also hear I’ve got to download all the game assets separately from the game itself, which seems painful.  Time will tell on if this port will work out.

Android Day 1: SDK, Eclipse IDE, and device activation

Tuesday, July 20th, 2010

Hey .. So I’m going to TRY and port Galcon to the Android.  There’s no promises yet, but we’re going to do what we can here.  If the port isn’t working in about a week, I’ll be giving up.

Step 1 – Download the SDK:

Download the SDK – http://developer.android.com/sdk/index.html

Using the package manager, I got all the versions of the SDK that are NDK and OpenGLES compatible.  I think we’re talking 1.6+.

Step 2 – Download Eclipse IDE:

Download Eclipse IDE – http://www.eclipse.org/downloads/

I grabbed the Eclipse Classic package since that seemed to be the best guess for doing Java / C / C++ code.  I would have opted not to bother downloading Eclipse, but all the tutorials seem to mention it, and I’ve got to start somewhere.  From what I can tell it’s what everyone uses for development.

Step 3 – Install the Android ADT plugin into Eclipse:

Install the Android ADT plugin into Eclipse:

You do this by first going into Eclipse > Preferences > Install/Update > Available Software Sites > and adding the Android one as specified in Step 1.

Then go to Eclipse > Help (???) > Install new software > Select the android source > check developer tools > next > … finish >

Step 4 – Completing the “Hello World” tutorial:

Complete the hello world tutorial.

http://developer.android.com/resources/tutorials/hello-world.html

I found that booting up the Android VM took ages, so be patient.  Eventually your “Hello World” app will start.  It took at least 2-3 minutes here.

Step 5 – Activating the Droid:

Now that I’ve got an app running in the VM, I want to get it running on my Droid and Nexus One.  Let’s figure out what to do now …

http://www.vogella.de/articles/Android/article.html#deployondevice – has some instructions.

Turn on “USB Debugging” on your device in the settings. Select in the settings Applications > Development, then enable USB debugging. You also need to install the driver for your mobile phone. For details please see Developing on a Device . Please note that the Android version you are developing for must be the installed version on your phone.

(in Eclipse, you can get to this option by clicking the black down arrow next to the big green Run arrow) To select your phone, select the “Run Configurations”, select “Manual” selection and select your device. (The selection of your device doesn’t actually happen until you press Run.)

And, we have lift-off!  I’ve got my first Android app running on my Droid phone!  I must say, activating this device was a delight compared to the Palm experience.  This took a few minutes to google the instructions, but the process itself took me about 30 seconds.  (Palm took all day.)  Unfortunately, I suspect this will be countered by the increased difficulty of actually doing the port.

Step 6 – Activating the Nexus One:

Unboxed the Nexus One and repeated Step 5.  No problems.  Man is development activation of these devices easy.

Tomorrow I’ll be working on getting the NDK up and running and see how far I can get with understanding the mysterious relationship between C and Java.

2 years of iPhone Galcon!

Tuesday, July 20th, 2010

Hey,

To celebrate two crazy years of iPhone Galcon, I’m putting the game on sale for $1! If you don’t have it already, or have friends who haven’t gotten it .. well .. get it now!

Here’s a recap of where we’ve been over the last two years:

Early in development – June 2008

Original menus – June 2008, background was changed by launch

Galcon’s launch screenshot – July 2008

Soon after Galcon got multiplayer! Here’s a shot of me testing it under linux!

In March 2009, I won the IGF Innovation in Mobile Game Design award at GDC’09!
n536805207_1584367_961091

I decided to polish up the look of Galcon a few notches, and launched a graphical overhaul in July ’09. Apparently I didn’t tell anyone because I can’t find any blog posts about it, but here are some screens:

Then in September ’09 I launched Galcon Labs, which included 4 new game modes for Galcon!

I’m not entirely sure what the coming year will hold for Galcon, but I bet it’ll be swell!
-Phil

Porting to Palm / WebOS

Wednesday, July 14th, 2010

I’ve just completed and submitted my port of Galcon to the Palm. The entire process took 2.5 days. Here’s my play-by-play of the porting process. A huge thanks goes out to Mike Kasprzak for hand-holding me through the process and co-writing this post.  If you’re doing a Palm port, be sure to read the whole blog post over before you begin so you get the big picture.  Also, not everything is exactly in the right order, so that’ll give you the birds-eye view.

Day 1: Preparing the device for Development

11:00

– Unbox the Palm Pre Plus.

– Figure out how to plug in the USB.  This is a bit tricky, you gotta really yank on that plastic tab on the side to get it off.

11:30

– Use WebOS Doctor to flash the device with latest OS

http://ws.palm.com/webosdoctor/sorry.htm

12:00

– Activate phone.  If your phone isn’t activated, you use a program that can bypass activation

http://developer.palm.com/index.php?option=com_content&view=article&id=2051&Itemid=30

12:15

– Connected to local WiFi on activated device

12:30

– Final preparation of the device for development.

http://developer.palm.com/index.php?option=com_content&view=article&id=1973&Itemid=336

“Card view” is the view where you can see a view of all the open apps minimized. Apps are called Cards.

12:45

– ssh onto the device, password is blank

$ ssh -oPort=10022 root@localhost
root@localhost’s password:
root@palm-webos-device:/var/home/root#

1:00

– Install the Palm SDK and PDK, read whole document so you know where the cross-compiling binaries are located. It varies depending on windows / mac.

http://developer.palm.com/index.php?option=com_content&view=article&id=1970&Itemid=335

1:30

– Install a SSH key.  This way I don’t have to keep pressing return on the password entry during SSH sessions.

$ pdk-ssh-init localhost:10022

1:45

– Verify installation by using a Palm demo app.  This is an important step!  This step shows you where the example code and scripts are and you’ll be referring to those when you build your own build/deploy/packaging scripts for your own app.  And if it works, you know your Palm is ready to go!

http://developer.palm.com/index.php?option=com_content&view=article&id=1974&Itemid=336

– Errors about not finding various .so files can be ignored

– [This should be irrelevant as Palm gets their SDK’s and firmware all synced across the networks] The PDL_Init error is actually the device talking back to you.  I had to go into the src folder and comment out PDL_Init to get it to run. This error is due to the 1.4.1.1 firmware on my Palm Pre Plus .. 1.4.5 is required for apps.  Had to do some hacks to get around this, won’t bother explaining, as this shouldn’t matter in a few days.]

3:00

– Rebuild simple sample app with PDL_Init included, works fine

3:30

– Got a copy of Mike’s app and tried it out.  Works nicely.

Day 2: Porting the App

– 10:30

Hacking up the /opt/PalmPDK/share/samplecode/simple/mac example building, packaging and deployment scripts.  Mostly just getting them to work with my code.  Was pretty straightforward if you know shell stuff.  I’m doing my work on the Mac, so I have a bash shell at hand all the time.

– 11:30

Got it compiling with a few tweaks. using rsync over ssh to deploy my game 🙂  I’m a big fan of rsync.  Here’s my “deploy” script:

rsync -v -urt –exclude ‘*~’ –exclude tmp –exclude .svn -e “ssh -oPort=10022” ./out/ root@localhost:/media/internal/galcon

– 12:00

I had trouble loading images to textures.  But this was mostly due to my own dumbness.  Ended up being really straightforward.  Used SDL_image to load, converted it to 32 bit, then loaded it in.

– 1:30

.mp3’s won’t play with SDL_Mixer, so you must use oggs instead, check out this hack that I use to covert my “.mp3” extensions to “.ogg”:

sprintf(f,”%s/%s”,DRIVER_DATADIR,fname);
int l = strlen(f);f[l-3]=’o’;f[l-2]=’g’;f[l-1]=’g’;

– 1:45

SDL keyboard events not passing numbers when I use the Palm number presser key.

This is a palm bug, I should file a bug report. If the user holds down the NUMBER key, and then pressed a letter, they get the proper number.

-5:30

Handled SDL_ACTIVEEVENT to switch game into pause mode when being minimized.
if ((e.active.state&SDL_APPACTIVE)!=0 && e.active.gain == 0) { /* pause game */ }

– 6:00

Added a few PDL_ calls.  I’m really liking the set of lightweight functions they give you.  They cover most all the stuff you need for game integration in just a few calls.

http://developer.palm.com/index.php?option=com_content&view=article&id=1990&Itemid=340

#include “PDL.h”

PDL_Init(0); // in init function
PDL_GetCallingPath(char *buffer, int bufferLen); // to find out where our app is being launched from so i can find my data files
PDL_GetDataFilePath(char *dataFileName, char *buffer, int bufferLen); // find out where my app can write save games and settings.. the buffer is a fullpath to where we can save a file to
PDL_LaunchBrowser(const char* Url); // go to interwebs
PDL_Quit(); // wrap it up

Here are a few tips from Mike that I found really helpful:

About the Palm itself:

  • There’s a touch strip beneath the LCD screen. Gesture up or down from the middle of the strip to bring up the menu.
  • To “Card” (minimize) a running application, gesture upward or tap on the gesture strip
  • To close an application, throw the card away (up)
  • To delete an application, hold down the keyboard button with a square on it, then tap the icon of the app you want to remove.
  • When you plug a device in, Just Charge is the ideal mode. USB mode is useful for copying files via drag+drop, but you can’t run things while in USB mode

Linkable Libraries

  • -lSDL
  • -lGLES_CM (for OpenGL ES 1.1)
  • -lGLESv2 (for OpenGL ES 2.0)
  • -lSDL_mixer
  • -lpdl (Palm specific calls)

SDL Tips

The following call is required BEFORE setting your graphics mode, yet after initializing SDL

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);

The number represents the OpenGL ES version. 1 for 1.1, 2 for 2.0.

webOS actually supports blending what you do against hardware decoded video. Unfortunately, this feature is on by default. The alpha value in the frame buffer decides weather video will bleed through or not (even if no video is displayed). To disable writing Alpha to the framebuffer, use this call.

    glClearColor(0,0,0,1);
    glClear(GL_COLOR_BUFFER_BIT);
    glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_FALSE);

Day 2.5: Packaging the App

Time to figure out how to package this into a sellable .. package!  I used Mike’s app and found that we really don’t need all the skeleton stuff palm-generate can generate for you.

http://developer.palm.com/index.php?option=com_content&view=article&id=1976&Itemid=375

You need an appinfo.json file in your distribution folder. It should contain something like this:
{
“id”: “com.galcon.app.igalcon”,
“version”: “1.9.8”,
“vendor”: “GALCON.COM”,
“type”: “pdk”,
“main”: “galcon”,
“title”: “Galcon”,
“icon”: “icon.png”,
“requiredMemory”: 48
}

I ssh’d in and used top to figure out my required memory.

And also a framework_config.json containing:
{
“logLevel”: 99,
“debuggingEnabled”: true,
“timingEnabled”: false,
“logEvents”: false,
“escapeHTMLInTemplates” : true
}

And lastly, I gotta include icon.png . Palm specifies this:

“Application icons should be 1 in. square, 64 x 64 pixels, encoded as a PNG with 24 bit/pixel RGB and 8 bits alpha. The icon’s image should be about 56 x 56 pixels within the PNG bounds.”

And lastly create this file:
package.properties containing:
filemode.755=your_app_binary

Then just copy all those files, and the app files into a folder named the same as your app id (com.galcon.app.igalcon for example) then run palm-package against that folder and you’re done!  Here’s a checklist from Palm that helped me through a few things:

http://developer.palm.com/blog/2010/07/a-quick-pdk-submission-checklist/

Then you just send that app package off to Palm! Have fun!

-Phil

Galcon iPad Sale and cool tournament with art prize!

Wednesday, June 16th, 2010

Hey,

I’m going to make a piece of custom artwork as a prize for a Galcon tournament! It’ll look something like this, but not exactly, because I already gave this one away to someone else:
phil-artwork

That image was actually colored pencil + markers + water color on paper. Then I scanned it in, inverted it, and added a bit of glow. The winner will be getting a new piece of artwork – I’ll send them the original in the mail as well as display a slightly enhanced version on the website for everyone to envy 🙂

Anyway check it all out here.

-Phil

Galcon Fusion for the iPad

Saturday, April 3rd, 2010

galcon-ipad-rainbowSo Galcon Fusion is available for the iPad.

Here’s a bit of tech stuff for ya! The port itself took about 3 days. If you check out the screenshots, you can see I letterboxed the desktop version of Galcon Fusion, and used that extra area to put the iPad specific controls (the pause button, the chat activation button, and the ships % “mouse wheel”)

I don’t have an iPad yet, but I think it’s going to work pretty well. The multi-touch interface design was all done ages ago for the iPhone, so I just used that code for this. It should work great!

The biggest challenge in porting was dealing with OpenGL stack limits on the iPad which appear to be 16 levels. My GUI used quite a few Push/Pop’s to achieve various theme effects and whatnot, but that was blowing the stack. It took me a bit, but I was able to find a number of places where I was able to remove those uses of the stack and things seemed to work fine. (There are some edge cases where my changes wouldn’t be safe, but none of my code uses those, so no harm!)

Anyway, I’m really looking forward to getting an iPad and seeing how the iPad users stack up against the mouse users. This will really pit two different interfaces against each other, which should be really neat. Both interfaces have their own advantages!

As always, python proved useful in this project as I had to update all my graphical assets for the game to work with the iPad. Since my asset pipeline was written in python and pygame, it only took a couple minutes to add in the code I needed to fix a few issues. And thankfully these fixes will go forward and improve my desktop version as well, so all and all, a good deal.

-Phil

P.S. In other news, I’ve been playing with django lately for my non-games business. It’s slick!

Update: Since I was unable to test Galcon Fusion on a REAL iPad it has bugs 🙁 Apparently the multi-player game crashes and the framerate is low. I’ll be getting my iPad on Monday and fixing those issues ASAP! There’s probably some kind of “testing on real hardware is smart” kind of lesson in this somewhere …

The Galcon Fusion beta testers rocked

Thursday, February 11th, 2010

Galcon Fusion has arrived.“Yay, it’s finally here! Check out Galcon Fusion today! We’ve got a free demo and it works on Windows, Mac OS X, Linux, and Steam! It features some crazy nice hi-res graphics and soundtrack. And epic multi-player battles like you’ve never seen ‘em before! Have fun!” <– marketing blurb 😉

Okay, for some dev thoughts. Man, it was a long week! Adding the “demo” feature to the build was a ton of work. And then doing all that other ‘stuff’ that sort of comes up. I think the one serious lesson I’ve learned in this whole process is that beta-testers are awesome.

Really awesome. I had about 50 people who I passed out 10 builds of the game to over the past 3 months. Some of these people put in several dozen hours of play time. All this was a huge help for me, as this was my first desktop ‘3D’ game, so I had a lot of learning to do in terms of graphics capabilities. As in, I was able to get the game to run on my computer which is a pretty nice MacBook Pro .. but not everyone else’s.

The beta tester feedback was huge, I was able to get the game running on old PPC macs, various linux netbooks, and who knows what else .. as long as it had a somewhat reasonable 3D card. I changed the memory requirement for graphics from about 200 MB down to < 64MB. Without any noticeable reduction in graphics quality even in HD video modes. In fact, that reduction changed the loading time on my computer from 5-8 seconds down to about 1 second 🙂 Anyway, I think I'm going to take a nap. It's been a long week, and I really appreciate everyone who helped me get this game put together. Give it a whirl, and thank the beta testers!

Galcon Fusion announced – Finally!

Friday, January 29th, 2010

Hey,

So, I’m finally announcing Galcon Fusion to the world.  Fusion is a port of iPhone Galcon + Galcon Labs to the desktop.  This time with hi-def graphics and a full interactive soundtrack.  It’s going to be coming to Steam and direct on my website on Feb. 11.  Users who supported me when I was first starting (as in, you bought desktop Galcon), your license is compatible with Galcon Fusion.  Thanks!

fusion-pink-green

There are a few technical things that were challenging, dealing with endiannes for my network code, supporting fullscreen vs widescreen resolutions, and supporting a wide range of resolutions (from 800×600 all the way up to 1920×1080.)  To make it short, here are a few conclusions: best to support endiannes from the start, fullscreen vs widescreen is a pain, and baking lots of image data into your binary is a pain because it requires a ton of recompilation.  Oh, and installing VC++2008 is waaaay easier than installing mingw32, but keeping code working on both takes more effort.

I think my biggest conclusion comes along with this announcement, is that doing “secret dev” work isn’t really that sensible.  If you look at that last paragraph, there are a ton of issues I could have documented in my blog that I didn’t because I was all being secretive.  And hey, since I was so mum on this, nobody has heard about it until today.  I guess there might be some benefits to this (??) but I can’t think of what they are.  I think blogging about my progress is a good way for me to be able to see what I’m doing and not get lost in the haze myself.  My recent article on VC++2008 is a great example of something I’m going to get quite a bit of value out of just for my own reference.

One big different thing I’m doing with this project is my wife Nan is doing the PR for it.  She’s contacting all the reviewers, the general press, the newsletters, the announcement blog, twitter, and everything.  I’m trying to take a more dev-only role in the announcement.  This is nice, because I’m not very good on PR.  I try .. but I really don’t do it as well as I want to, largely because on a launch of a product I’ve always got about 50 technical things I’m trying to do along with the PR!

-Phil

Galcon pricing experiment

Monday, November 23rd, 2009

Two weeks ago, the price of Galcon @ $3, Labs @ $2, and Lite @ $0.  This past week, I changed them to Galcon @ $5, Labs @ $3, and Lite at $1.  I wanted to see how this would impact revenue.

And the big surprise is …

It didn’t!  Much.  Best I can calculate, revenue was down 10%.  The most dramatic change was Lite, which went from $0 revenue to a few bucks a day, and from a few hundred downloads to almost none.  So this week I’m changing the prices back to Galcon @ $3, Labs at $1, and Lite at $0.  What have we learned?  It seems that people who want a free game want a free game, and people who are willing to buy would rather spend less.  Since I’m not going to run this sale for a month I can’t say for sure what the long term effects will be, but I’d guess word-of-mouth would be reduced as the pool of Lite players shrunk.  Who knows 😉

Cheers!
-Phil

Galcon Labs on the App Store!

Friday, October 2nd, 2009

Hey,

So Galcon Labs is now available on the App Store! Check it out 🙂

Anyway, I just got back from 360iDev where I gave a talk about Galcon Multiplayer.  The two main points made in the talk were about managing community, and test driven development.  With so many devs talking about App rejections and other problems, I wanted to make sure the app was approved first time through the system.  And it was, in an excellent 7 day turn-around 🙂  So a real big thanks to all the folks out there who pressed me into reading the Kent Beck book on the subject!

-Phil