At work I have to provide a progress report. It details what I've achieved and what I'm going to do. Seems to help keep me moving (I dread the idea of filing a progress report that says this week I've mostly achieved nothing) so I thought I'd try it here.

All past game attempts are currently on the cutting room floor. I need to make some cash so I'm gonna try my hand at money making games for a bit. Current plan includes and is probably ordered in priority:

• Finish reviewing 4K games for the contest. These need to be done by next week and I'm only about a third of the way through.
• Do the Slick bug run. I know I know, there are lots of bugs outstanding and I will be getting to them ASAP.
• Start porting some of my mobile creations to Flash with a view to selling them on. Hopefully this will be reasonably easy using Flex and FlashDevelop
• Facebook games, I have a few ideas here and I think I'd like to give them a go. It seems like a place you can make an impact pretty quickly if you get it right and looking around some other indies I can see some extensions to existing ideas that might fit the facebook platform pretty well.
• Finally the circle art game. I have this art farty idea about a game with circles. Thats about all I have but there will be lots of circles. Possibly in different colours. I'm sure it's going to be great :)

Just read on the google blog that a new release of the NDK (release 3) has been made available. The NDK really hasn't been getting the press it deserves but this latest release should be of great interest to games developers.

The new NDK release includes native access to the OpenGL stack for applications targeting Android 2.0 or greater. While you might be forgiven for stepping pass this, because we've had access to OpenGL via Java APIs all along this really is an important step.

One of the problems we've seen with OpenGL and Java in the past is how noisy the API is (lots of calls) and how slow the native interface is. This native layer finally gives Android developers the chance to write high level scene graph APIs to expose to the Java API and then write tight C OpenGL code underneath. This hopefully gives us all the ability to build games that really utilise the hardware on these new android platforms.

A couple more variants..

If you use just rectangles, it doesn't work out well


Mixing ellipses, rectangles and polygons gives the best results yet at only 500k generations.

Shannon commented on the last post, why don't we use circles instead of polygons on the generation stuff. What a fantastic idea? I swapped Ellipses for Cirlces (to leave more room for mutation) and update the tool, results:

How cool is that? Now I'm starting to wonder what about mixing the shapes and allowing shapes to mutate between each other? What other shapes are there to reduce data, rectangles next?

What a fantastic comment and idea!

I've been out of the loop again! Apparantly this very cool stuff by Roger Alsing was posted on Slashdot last year. Well I didn't see it, if I had I would have jumped to trying to implement the same thing - it's just so cool. I'm not sure there are any practical uses for it (maybe some texture compression stuff for games?) but it's just such a cool idea.

So, given that I saw it posted on JGO a few days ago, I ran at it and tried to implement the process. A few painful bugs later and I had a command line tool. Since I had the day off I spent some time tidying the whole lot into a GUI based application.

Whats happening here then? First we generate a set of polygons. Next we mutate the polygons (move them about, add some, remove some, change colours). Compare the first set and the new set of polygons to the original image. Choose the one that is closest and mutate again. Repeat. Alot.

Update: Couple more examples using 150 polygons

You can get some pretty cool results with a bit of time. The image above was captured over 2 hours. My version of the GUI tool looks like this:

The tool is available as an executable jar (i.e. you'll need java installed). The source code is also available here in an Eclipse project.

There will of course be bugs and improvements to be done. I might find some time but even if not, a very enjoyable distraction!

My patch for XMLVM described previously has been commited to the head by the wonderous XMLVM team. The patch allows you to develop OpenGL application in Java that can be compiled into iPhone ObjC and then onto the real device.

Thats right, OpenGL development in a nice language like Java with a target of iPhone. Performance is pretty damn great too - especially when you manage the garbage carefully with the XMLVM annotations.

Thanks XMLVM team, great stuff!

Now, I don't claim to be an expert on this topic at all, however I have tried all of the methods below with varying success and regularity. As you can tell, I'm still here typing, so I haven't made it "big" with any of these methods. I've been writing games for the love of it for years, I like everything about it. However, for me it's important to have my games played and appreciated - how better to gauge that then to try selling them? What's more, when it's just hobby, the extra cash for beer money is just like icing on time wasters cake!

1) Shareware

The original way for indie types to make money. You give away a free version (or the full version if you're daring) and nag the end user about paying the money for the full/unlimited version making sure to point out the wonderful features they're going to get. In short, it's proven, it works. Letting people really play the game beforehand gives them confidence in the purchase. However, give away too much and they might just decide they've played enough and don't need the full version. I used this method with Tiltilation and it wasn't too bad, making a couple of thousand pounds sterling for 6 months work. It was also my first commercial endeavour and almost killed me. Shareware works well for full scale desktop games but the game needs to be a certain size before you can split it into the free bit and full version and leave both parts providing enough to play.

2) Adware at Home

Adware comes in a few forms. First you can stick adverts on the website around your web based games, most common for this is Google Adsense. Next if you're using the right technology you can embed adverts right into your game. If you're using Flash you have a multitude of options for this, most popular being MochiAds. In other technologies you can always opt for Google In-Game. Both methods essentially rely on the context adverts being smart enough to entice your players to click the adverts. This may of course annoy your players some, so it's best used carefully.

Now the "at Home" bit - one way of using these things is to keep your game (and idealy a bunch of your other games) on your website and try and drive traffic there, much like I do here at Coke And Code by writing blog articles like this (oooh, meta). The upside here is that you've got the exclusive on your games. The downside is you've got to drive that traffic yourself and that's not as easy as you might think. Here at C&C I make enough money from Google Ads to pay for my hosting (read about 25 quid a month) which can't be bad really. I get the odd special deal, but the traffic really isn't enough to making any real money. However, there are other options...

3) Adware at Portals

So you're happy to advertise in your game and/or around it, but you can't get the traffic. Well you might consider submitting the game to a portal and having their huge collection of games drag the traffic in. If you're working in Flash there are a massive number of portals to choose from including my faves Newgrounds and Kongregate. Both offer deals on advertising revenue including extra bonus percentage for integrating with their APIs (highscore, achievements, etc). If you're using other technologies you're going to find yourself limited, although the rather wonderful Game Jolt has just opened up their revenue scheme. For once, they take pretty much any technology and the games selection is starting to look really good!

Putting your game on a portal has a downside of course, it can easily get swamped under the mass of other people doing the exact same thing as you. Your game has to be good enough (and more important, re-playable enough) to actually drag people back to it. That said, my rather limited collection of flash games has been dragging in 15-20 pounds a month for the last few months on portals, so I guess that isn't not too bad. If you had a really popular game on there you could be getting some reasonable cash out of it, but it'd be unlikely to be sustained given the number of new ones every day.

4) Sell or Brand It!

You've written a kick ass implementation but average idea game. Putting it on the portals might get you some money long term but wouldn't it be nice to get a quick lump sum payout. There are a few portals around that will buy games in any technologies but they are few and far between. I've sold a Java applet to a portal (I can't mention here but) only for $250. That's nice for what was a week's work, but it did take an awful lot of finding. However, if you're working in Flash then you have a wonderful option left open to you - Flash Game License. This site lets you upload games for viewing by sponsors and publishers. If your game is quality looking and feeling, but the idea is average (or its a remake) then this is a great option. The downside is that at times you see games getting stolen and published elsewhere, but that's pretty rare these days.

There are a few deals you can do on lump sum game payments. You can sell an exclusive deal - this means the game only goes on one portal but tends to be a decent deal. You can sell a branding deal, where the game goes anywhere you want but carries the branding of a portal. You can just sell the game outright (with or without source), this is a rare occasion but sounds like you can write your own ticket (never happened for me). Each of these deals also may or may not let you keep your own advertising in place. In the best case you might end up with a branded game in which you can keep your own advertising and are actively encouraged to distribute. This is like having option 3 with a bonus :)

The deals vary alot from around $50 up to a few with $10,000+. Obviously game quality and appeal controls how much you're going to get offered. On Flash Game License it's a bidding process where publishers may try to out do each other. Moreover, in some cases you can sell the game to multiple publishers! I've made deals from $500 up to $1500 here, with games not taking more than a few weeks to put together. The problem is keeping going. It's a very dry process designing games to be explicitly appealing in this context - but it's probably a good cash in if you can stick it.

5) Go Mobile!

In the last couple of years the iPhone market place has become hot property. Now, with Android market launched and host of mobile providers itching to release their own versions, there may be money in them there handsets. There are a few great success stories about iPhone applications but not many given the number games released. The process for getting games up on iPhone is labourious but the market is very rich. In contrast the Android market is wonderfully simple to get games up on, but the market is still trying to find it's customers.

Getting your games out there and charging is pretty easy on both accounts. The APIs for developer are also pretty simple. Mobile games seem to work in a similar way to shareware. You push out a free lite version, then charge for the full game. So, why not port your game to a mobile?

I've got a few games out on both iPhone and Android at the moment. Nothing massive, but neat games, with polished looks. Android is selling, well not a lot, I can't imagine I've sold more than 3 in a day of anything so far. This isn't going to make me rich. On iPhone I don't current have "lite" versions and even then they're out selling Android 5 to 1. It's an interesting market. Probably one I need to spend more time on.

6) Trust in the good nature of people

If you really can't bear selling out in any way, but you'd like to make some cash then you consider the infamous "Donate" button. I've tried this on one game (that is no longer available), you're essentially saying "be nice, I wrote the game, drop me some cash". It could work, really it could, but I've yet to see it. The game would have to be something that people felt part of, that they came back and played over and over, that they were committed to - and even then you'd need your players to have enough disposable income to not mind shelling out some cash on something they could have for free. Tricky business!

Conclusion

While it's important to choose the right method for you, it's also to have a great game and put the hours in - which is probably where I keep failing :) There is no get rich quick and there is no easy win. If you work really hard, and choose the right business model and get lucky... you might make enough money for a pub lunch. If you get to be the one in million who makes it's really big, congratulations!, but for most of us it's best to accept that while you can make money on games it's unlikely to become your primary income. Write games for the love it and appreciate the beer money when it's there.

Some days my geeketry amazes me. I got an IM from Canada telling me that one of my favorite board games of all times is being rereleased in a special aniversary edition.

Space Hulk is Back!

I've preorded of course and looking forward to getting my mits on it in September. When asked who I'd play it with with a collegue I was amazed. My response? "I won't open it, I'll just look at it" :)

I've been playing about with this XMLVM for a couple of weeks now. I just love the idea of using Java to produce iPhone stuff. More than that it adds nicely the suite of stuff I want to write that lets me have one code base and drive different platforms. One code base, one set of maintenance, one set of debugging and one set of bugs, should equal more time free to polish the heck out of games.

Anyway.. being that I've done quite of bit of OpenGL before I know that it's the best way to write polished feeling games. On the iPhone it appears to also be the only way to get reasonable performance bar drawing 50 or so small images to the screen. If you want to start upping that and blending, rotating etc you need OpenGL ES. What's more if you want to go to 3D games on Android/iPhone (though I probably don't) you gonna want GLES access. So, enough of a ramble about why, what has been achieved.

First the Java version of the iPhone compatibility library from XMLVM needed to have GL functionality exposed. This was pretty simple, a static class that exposes each of the methods and constants required right now. Next a new view type that can perform the setup required for GLES on the iPhone. I could have exposed the setup methods too but they're awfully murky and should be basically the same between all applications. So now, I have methods to code against. Port some iPhone GLES code (NeHe lesson 4) and ready to roll right?

public class NeHeLesson4View extends GLView {
	...
	
	public NeHeLesson4View(CGRect rect) {
		super(rect);
	
		viewWidth = rect.size.width;
		viewHeight = rect.size.height;
		
                setOpaque(true);
                setClearsContextBeforeDrawing(false);
	}

	private void initViewGL() {
	        ...
		
		GL.glMatrixMode(GL.GL_PROJECTION); 
		size = zNear * (float) Math.tan(
                        (TO_RADIANS * fieldOfView) / 2.0); 
		GL.glLoadIdentity();
		GL.glFrustumf(-size, size, 
                   -size / (viewWidth / viewHeight),
                    size / (viewWidth / viewHeight), 
                    zNear, zFar); 
		
		GL.glViewport(0, 0, (int) viewWidth, 
                             (int) viewHeight); 
		GL.glMatrixMode(GL.GL_MODELVIEW); 
		GL.glLoadIdentity(); 
		GL.glClearColor(0.0f, 0.0f, 0.0f, 1.0f); 
	}
	
	@Override
	public void renderView() {
		if (!viewSetup) {
			viewSetup = true;
			initViewGL();
		}
		
		GL.glClear(GL.GL_COLOR_BUFFER_BIT);

		GL.glLoadIdentity(); 
		// Triangle
		GL.glTranslatef(-2.0f,1.0f,-6.0f);
		GL.glRotatef(rtri,0.0f,1.0f,0.0f);	
		GL.glEnableClientState(GL.GL_VERTEX_ARRAY);
		GL.glEnableClientState(GL.GL_COLOR_ARRAY);
		GL.glColorPointer (4, GL.GL_FLOAT, 0, 
                                   triVertexColors);
		GL.glVertexPointer(3, GL.GL_FLOAT, 0, 
                                   triVertices); 
		GL.glDrawArrays(GL.GL_TRIANGLE_STRIP, 0, 3);
		GL.glDisableClientState (GL.GL_COLOR_ARRAY);
		
		// Square
		GL.glLoadIdentity();
		GL.glColor4f(0.0f, 0.0f, 1.0f, 1.0f);
		GL.glTranslatef(2.0f,1.0f,-6.0f);
		GL.glRotatef(rquad,1.0f,0.0f,0.0f);
		GL.glVertexPointer(3, GL.GL_FLOAT, 0, 
                                   quadVertices);
		GL.glDrawArrays(GL.GL_TRIANGLE_FAN, 0, 4); 
		GL.glDisableClientState(GL.GL_VERTEX_ARRAY);
		
		rtri += 1.5f;
		rquad -= 2.5f;
	}
}

Well, no, the simulator didn't yet support GL on the desktop. Integrating JOGL into the emulator took a little bit of hacking about, turns out JOGL 2 doesn't support anything less than OpenGL 2.0 - bit daft in my opinion. Hold On! Why is Kev using JOGL, he loves LWJGL. I do, but this seemed like an opportunity to refresh my JOGL knowledge and it was as painful as ever :) JOGL integrated, a bit of debugging later and the OpenGL compatibility layer is running in the Simulator:

Great, I can confirm the GL code is correct. Awesome. Next to get it working on the iPhone. First the objc version of the compatibility library needs extending again - adding implementation of java.nio.FloatBuffer etc and some more Core Graphics classes. Next over into OSX, cross compile, compile the objc and try the sucker. Hmmm.. not working, at all!

Turn's out I've made some dumb assumptions in the objc code for the GLView. Some few hours later I have it running in the emulator - just need to get it tested on a real phone now:

So again, XMLVM has allowed me to build stuff for the iPhone in Java. It's proven to be not too tricky to update to add functionality as and when you need it. I've submitted a patch to add this stuff (including the example) into project. Hopefully we can work through the integration and get it out there for everyone.

So far I can only encourage people to grab XMLVM and get playing!

Spent a few evenings working on some extra features for the abstraction that I need for the football game. The additions of course have to work across all three platforms so it took some time. However, there is now:

• Sound FX - basic load sound and play back. (AudioClip/SoundPool/AVAudioPlayer)
• Persistant Storage for game settings, save games, etc - (Cookies/Preferences/NSUserDefaults)
• Suspend/Resume functionaltiy for phone based games (No Applet Support/Bundle/NSUserDefaults+NSData)

It all seems to work but I ended up spending a good evening and half chasing round bugs on the IPhone's lifecycle and data storage.

Still... back to the game now!