Coke And Code - Java Games and Games Development - Geek

Hour Oriented Game Development

Tue, 03 Jun 2008 21:21:52 +0000

So, I had a few drinks yesterday evening, a rarity for me. Mostly to celebrate my wife getting offered a new job - woo woo. I'd been ranting at work about how mindless clicking games are so successful when other better games (putty of course ;)) go unappreciated. I had an inkling of an idea about bubbles and lines between them (I realised later this was probably derived from talking to Cas about what he was doing). Anyway, back to the drink, few glasses of wine later I'm spouting my normal nonsense on IRC and I start coding this idea up without really thinking about it. At the start I decided every hour I'd check progress, if it wasn't working out or it stopped being fun I'd just go back to my isometric project (see below).

Well, this hourly thing works for me. It was really fun pushing to see how much could be stuffed in within an hour. I guess this is how the Ludum Dare competitors feel. This is how it went:

Hour 1 - Making it work

Development started at about 11pm. I knew the game idea revolved around bubbles appearing on the screen. I'd talked to Cas about it earlier (see above) and one of things he'd mentioned in the past was how to get the bubbles to push each other aside. First, lets spawn some bubbles. Create a basic slick state based game, default state and a class representing the bubble. The bubbles can draw them selfs and can be updated, for a change I allowed the bubbles to return an indication whether they'd changed size or not. This made the game loop very easy - loop through all the bubbles updating them, if none of them changed size spawn another.

The next step was a bit more complicated. When a bubble grows it needs to push the others out of the way. I took my normal discrete collision based approach. Limit the bubble to a 1 pixel growth. After the growth check for collision. If anything collides with the bubble that has grown move it away from the grower and add it to the list of pushed bubbles. While there are still pushed bubbles pick the first one and repeat. This was the first brute force approach that came to mind and it seems to work fine.

So, the first hour was spent fiddling with setup and boilerplate classes, getting some rendering and basic logic in. Assessment after the first hour was that watching the growing and pushing red circles was enticing, especially in my now growingly inebriated state.

Hour 2 - Making it Pretty

Next I thought I'd make it look pretty. Thanks to the wonderful www.fasticon.com I had some nice looking fruits very quickly (though originally they were going to be gems). I lost 15 minutes or so hunting round for a bubble until asking on the #lwjgl channel and being told just to paint a gradient across a circle. Strangely it kinda worked, I like what's there now at least, maybe it's not quite bubble like but it works pretty well.

Having replaced the circle drawing with images I noted a huge speed increase (circle drawing was taking up a lot of polys). So, I sat for a few minutes watching the spawn of fruity bubbles. Oh, thats good I thought. Hmm, whats going on with that FPS - it's getting lower and lower? What had I done!?

Well it turns out I wasn't getting rid of the bubbles after they'd left the screen. So the pushing code was slowly pushing more and more bubbles. As a result I added some little bits of code to determine if a bubble was on the screen and whether the mouse was over it. I stuck on a background (which you can see in the next screenshot) and started thinking about showing other people.

Slick has some useful build scripts, so I grabbed one of them, updated it for the project - ran it and had a webstart ready to try. Webstart for anyone who doesn't know lets us Java type show each applications and games with minimal effort (including keeping it updated). Posted the link to it onto IRC and waited for a response. General approval - woo hoo - "why can't I click the bubbles to pop them?". Well thats not the game, you have to draw lines - "meh".

A discussion then broke out about what the game should be like. They're a nice bunch of people, with good ideas. The game idea I had was reshaped into something a lot easier to play and enjoy. Mindless clicking for the win!

Hour 3 - Making it Playable

The background is a kevglass original, the font some stock thing I've hanging around pushed through Hiero for a bit of shading and shadows.
The game idea ending up being a simple matching game. The game shows you a fruit, you need to click all the fruits of that type - the more you click, the more points you get. I decided to add a timer to limit game play and score was updated based on the size of the bubble - smaller bubble = higher score.

Searched for, found and added a few sound effects for bubbles popping etc. A simple pitch changed based on the size of the bubble seemed to give it a comfortable feel. With the constant spawning of bubbles this was already quite fun. The changes didn't take long but there were bugs galore. Just stupid silly bugs. I was getting tired by this point, it was pushing on to 2am. At 2am-ish I ran the build script and pushed out another version and decided to call it a day. There was still feedback coming in but work in the morning etc.

Hour 4 - Rethinking the Game Play

Hour 4 was, as often is the case, my lunch break at work. I decided to go the local canteen to save some time so I could read the feedback, chat a bit and design a logo. I wanted to call the game something suitably generic and corny - Super Bubble Pop Fruit Drop Deluxe Edition. 20 minutes of my lunch disappeared just designing the logo you see to the right. I'm not an artist as you can tell :)

Having processed the feedback and got the logo sorted I spent 10 minutes writing down a plan of attack for this evenings coding session. The last item on the list was writing this blog post. Why? Well, because I think I'll find it interesting in a few months looking back.

The list also included the game play changes that needed to be made and the idea of porting the whole thing into Java 2D. That still might happen - there's a couple of hours left in the budget :) I'm pretty determined not to let development time go over 8 hours at the moment, looks like it should be enough.

Hour 5 (and a little more) - Making it a complete game

This evening's first hour started around 8. The game play needed to be changed. Talking on IRC had led me to the following changes:

There would be no timer, thats just a lame cop out
Lifes would be added, you lose of life if you click the wrong fruit
A score multiplier would be applied which ticks up as you click, and ticks down as you don't

Adding these features was about 20 minutes of effort. All the code was really already there, it just needed moving about. However, it was now that I decided I need a title page, some instructions and a few more graphics (well one, for the lifes indicator) to make it feel more like a game.

The graphics were easy, just visit fasticon.com again. The title page also didn't take long, slap the logo from lunch on the page and added a in code flag for the starting page. Made the logo wobble a bit because it seemed cute. Hurts your eyes if you watch it too long though :). The instructions however zapped up loads of time.

First, I ummed and ahhed about whether to just define the instructions text as a string in code or in a separate file. Why? I don't know, I really don't. Next I wanted it displayed as a marquee, but drawing the whole string each time would have been super slow - so how to do it? Each part of the message is a separate object which only draws if it's on the screen. A quick inner class, a bit of buffered loading and a simply bit of maths for clipping the text off the screen. Annoyingly, this actually took me longer to get right than anything else so far.

Finally for this hour I spent an age searching around for sound effects for when the fruit changes in game. All I wanted was a beep beep beep timeout sound, no luck. Eventually found one hanging around in one of my local game resource directories right under my nose. Sounds pretty good in game now.

Hour 6 - Tuning and Polish

So far this 6th hour has been tuning and adding polish touches suggested by testers and myself. Tuning parameters like how long between extra lifes showing up, how long fruits are current for and how quickly the multiplier drops back is really interesting simply because of the massive effect it has on the way the game plays.

And of course, half of this hour (a little more now) has been spent writing this blog which I hope has something readable in it. There are several things people say hurt productivity:

Making library code that you share with others - Slick has worked out ok for me! Lots of bugs reports have made it more reliable library for me as well
Chatting on IRC - IRC is a wonderful source of instant feedback for me. While I know what I like in a game, it's obvious that's not mass appeal and without the IRC channel I'd have little hope of sorting out problems early on.
Writing blogs - I've been looking forward to writing this blog since the first bubbles started showing up. It's been one of the goals and a great motivator.

I'm not sure any of the above is really a pattern, but I think I'd say that you're as productive as you are. The things that are perceived to make you more or less probably have a very low percentage impact on your real output.

What now?

Well the game will be available to play after a couple of hours more development time (maybe not tonight). It look like it's some extended features and a bit of polish before it's done. Two more hours should give me time to add a couple of ways of getting bonus scores at least.

This blog is of course self indulgent nonsense, but it's just one of them things about being a geeky chap I suppose - you just need to tell others about the code you're pushing out. It's fun for me, it really is, but it's more fun if I get to show and talk to other people about it.

Game Specification

Wed, 14 May 2008 11:35:39 +0000

When working in a team of developers, or even when hoping to succeed with a single developer project it's important to have an overall common shared concept of what the final game is going to be like. Of course, this being games development, this is open to change during the creative process, but the specification of the game describes what the game is, how it's going to work, whats going to make it fun and what's going to keep people coming back. This is especially true when working with distributed group of contributors.

Before the Java folks start jumping around, I'm not talking about software design/specification here. For small games it's often not worth worrying about software design documentation since the majority of it is just following known patterns that most capable developers don't really have to think about. For larger ones software specifications are still only largely interesting to the developers. The game specification sets the mood/feel of the game which should feed into every aspect (art, sound, development, etc.)

Anyway, this came up due to yet another conincidence. Yesterday someone was asking about how to write them, and today I was hopefully joining a team thats developing a game which needs a specification. So, while I'm not terribly proud of them here's the examples I have of some game specification:

Two reasonably complete ones from a while ago :-

Retailopia

Battle Scape Armada

And one that I posted recently thats still in progress :-

Into the Expanse

They might not be great but at least they might stir some mental juices.

Puttonandonandon

Tue, 22 Apr 2008 11:51:47 +0000

The putty prototype is continuing. Prototype #3 (see previous entry) is being refined to use a couple of new features and have a goal.

I've just been testing out #1 again (the one with physics and morphable shapes). It's the only one that really floats my boat so I think I may go back and try and solidify the engine so the response on morphing is crisp. Still can't quite see the game but I definitely preferred the full control - at least thats how I feel today :)

In other news, never do anything but assignment in a constructor. It's bad, and wrong and evil - especially when you then try to convert that system to make use of a IoC Container.

Some days arn't so good...

Thu, 10 Apr 2008 21:05:12 +0000

She's still ill, or at least sad. There doesn't seem to be anything we can do to cheer her up and the throat is still keeping her up. I haven't slept properly for a week now. She's generally better, but still not eating.

The last two days have been long work days, around 11 hours a day. Finally work is coming back up, I'm starting to get somewhere - but the lack of sleep is starting to make it hard to focus. Understand that I spend a lot of the night coding anyway, so it's not that unusual for me to get 4 hours sleep and be fine. Right now, it's just not even reaching that stage. Still, at least I've made some progress this week.

Now, home stuff is really suffering. I've done no game stuff since the weekend, apart from update the spec for the *big* game. Now I check the Slick forums, and while people seem to be using it theres a definite trend away - I guess thats to be expected given how long it's been going.

What I need is a little game to write now, tonight, to get me awake and alive again, but the lack of sleep just isn't letting me think of anything. Time to hack..

Library Naming

Mon, 07 Apr 2008 21:25:08 +0000

Libraries are funny things, coding is ok, I can sorta get that bit working but the rest of the stuff around pimping a library I just can't get right.

First, apparantly it needs to have a website. I was just going to pop in on the forums and see if anyone bothered to try it. Now it has a website.

Second, name. What happens if you let Kev try and name a library - well you get something like "Phys2D" - you see it's physics and it's in 2D, so it's uh, Phys2D! Enough said, I'm not good at these things. Woogley was kinda enough to name Slick for me, I believe my original name was YASL (yet another sprite library). I was going to call this network code "commet". COMMunications, nETworking. Ok, very lame. It's now got a a happening name.

Finally logo. I like logos, they're cool and surprisingly motivating. The slick one is pretty lame, I did that. It's functional. The phys2d almost makes up for the terrible name, it's a great logo. The guy that did it just roughed up a bunch in a few minutes - I liked the rough one so much it's stuck. This time a new Slick user popped up with a new logo (and he actually came up with the new name). Cheers!

So here it is, Noodles. And yes, I know I can't design websites either.

EDIT: Oh, for those that have read past posts, this one doesn't need pimping anywhere. It's just not ready for *real* users :)

Another thought...

Sun, 06 Apr 2008 21:10:08 +0000

What a pita this network stuff is, time to find something else to do.

The space trading game is going to be great. Did you play PSI 5 Trading Company? Do you know Java and feel like working as part of a team. Let me know!

Platformer Demo

Thu, 03 Apr 2008 11:39:41 +0000

Felt like a hack last night. Hacking is good for motivation, though sometimes not good for focus ;). Theres a few things I'm running in parallel at the moment:

1) Slick - updates and fixes.
2) Networking Library - this is taking a long time. Hopefully be worth it
3) New Applet Game Idea - this is outside of Slick, it's good old Java2D - but it's a winning idea, so heh.

As part of 1) I'm trying to produce a few demos to show how different game types might be started. I'm not planning to write full games but simple tech demos that hopefully give people somewhere to start. As normal I'm trying to make the code useful and readable over making it particually clever.

So, back to this hack, I'd been meaning to take a look at Platformers. Chman had asked how to use Phys2D to make a platformer (though quite a few others had asked before). I realised I hadn't tried it, so all I could do was point him at SlickSet (I know Jon has achieved some cool platformer related stuff).

Anyway, so last night I hacked at some platformer code using phys2d. This is what came out:

You can try it via Webstart and the source available. The code and implementation is expected to develop a bit over the next few days to provide a decent sample, right now it's still buggy - doesn't have good performance - just about trying stuff out.

So why is this hard? It comes down to what I guess is pretty obvious. Generic platformers (think Mario, Sonic, Zool) don't use physics engines, infact they're not even following the rules. When you try and use a physics engine you have to fudge stuff to make it feel more like a traditional platformer while leaving enough of the physics engine intact to allow the rest of the world to make use of the engine (that is of course what we want, a mashup between real physics and platformer dynamics).

Hat's off to Jon, this isn't some tiny task that you can just do. It takes a lot of fiddling. Getting the physics engine to act like a platformer is pretty simple, getting it to allow you to interact with other objects while maintaining the platformer nature - thats a git.

Still, last night I did start from nothing and got the tile combination stuff working, a simple renderer, a tiny engine (named Penguin) and a silly little demo that shows up a lot of the issues. Initial indications are that it's totally possible to mix the two worlds and end up with something uniquely fun.

Hopefully one of the enterprsing folks will take it futher.

Now.. which demo next?

Cluster Maps

Mon, 10 Dec 2007 08:49:10 +0000

See that little map at the bottom right of the page, that's cool to me that is :)

It shows where the visitors to this site have come from, it does it without me having to do any more than cut and paste some HTML from the cluster maps site into mine. It's also free. Isn't that just wonderful?

I added it a couple of weeks ago and I'm astounded by the range of people that are visiting, presumably the majority are bots and crawlers but it's still pretty interesting. It's also been nice to get some external view of the number of people visiting. I tried google analytics for a while but it just seemed to stall on me.

Free Stuff + The Internet = Cool :)

Tor!

Mon, 10 Dec 2007 08:46:45 +0000

Probably way out of the loop here, but I just stumbled upon the Tor Project. Seems like a pretty cool system for protecting your identity and location while playing around on the net.

Does worry me that it'd be abused but then I suppose that's not the tool's fault, just the users.

Neat stuff.

'No Fun and No Code make Kev Something Something'

Thu, 29 Nov 2007 08:29:25 +0000

'Go Crazy?' - 'Don't mind if I do!!!'

Life is a bit on the lame side at the moment. At least 2 of the three members of my household have been ill for the past month an a half. Work wise I've been sat on the same low priority but critical work for the last 3 months - not really going anywhere fast. No code involved at work and no energy to code at home.

Haven't been out in a while, no pub, no trips, not much fun. Don't have time to play games even though I've had Wii Paper Mario sat on the shelf for the past month. Christmas is coming and I can't begin to get excited. This time last year we were preparing to come home which could have been the worst mistake we've made. Coming back was great from a family perspective but pretty much everything else has been a bit of a read through.

What's more the idiocy of the world at large is begining to annoy me again. Road users - why oh why - just because something is legal doesn't mean it's sensible. Just because something is temporary doesn't mean it's automatically ok. No, there arn't double yellow lines - but parking there will still block the road. Bike users - weaving in and out of traffic is legal, but if it's cold, wet and early it's still dangerous as hell. And as to the woman that parked on the roundabout so she could "just pop in" to McDonalds to get her breakfast - I mean seriously, what sort of brain dead moran are you?

Recieved a phone at work yesterday. This might not seem like a big deal worth blogging about but consider that I've been working for a telecommunications company for 3 years and this is the first time I've had a phone on my deak. It's pretty big news. Now, if it only actually worked it'd almost be a positive aspect of my day.

Meg is still coughing alot, she can't shake this bleady cold any more than anyone of us. However, she is still giggling and trying to walk and falling on her butt alot. Some how she's really into drawing now - she's just over 1, so it seems a bit bizarre - but she loves her crayons that she now takes everywhere with her in a little red handbag. There has to be a game concept in there somewhere.

Talking of which, I've decided to write 4 games in parrallel, the logic being that even if I give up one or two I should still get futher with some. So, the run down seems to be two that have been around for a while, Scorched Turf and Mootox and two new ones currently called Samson and Dumb Bots. Should I ever make it back to the computer at home I'll be pushing on with the golf game first since it's core engine is shared between all 4.

Finally, I've blogged again. Almost feels like normal if a bit random and tangenty. Anyone know of anything gamedev related in the Cardiff area let me know, I need to get motivated again!

10 Bits of Feedback for Google's Android SDK - Slick and First Impressions

Sun, 18 Nov 2007 14:39:59 +0000

Google recently released a new SDK to develop on a new mobile platform called Android. It appears to be essentially a new "standard" backed by some huge players and produced by the ever-so-MS-like Google. So, now that the antibiotics have kicked in I've been fiddling with the SDK and the emulator. To not pass comment before you've tried it, I've ported a large chunk of the renderer for Slick onto it, enough so that I can render SVG using the Slick renderer into the handset emulator:

So, it works. Thats a good start... good things:

Eclipse integration - thumbs up. It's simple and quick to get going when you're a normal Eclipse user.
OpenGL ES is part of the platform - double thumbs up. Open and well known APIs for rendering. Yes Android provides yet another custom graphics context but portability wise, I'd rather stick with something nice and common.
Most of the Java SDK is there. No more of this mobile = no API stuff. So far I haven't had to recode anything due to missing classes or features (though I have had to recode, see later)
The provided Emulator is pretty and seems to be running a real implementation underneath. Thats a step over past emulators for mobiles that were just best effort wrappers. Hopefully this will cut down on the "but it worked on the emulator" syndrome
Money - $10 million has been put out there to try and stimulate developers. Thats a good step, even if all the best programmers code for free ;). It's what we'd call over here Putting your money where your mouth is

Ok, too positive for Kev I think. Time for the bad points:

The Emulator - ok I know I said this was good above but actually using the thing and integrating with IDE is appalling. Sometimes the package gets to the emulator, some times it doesn't. When it gets there sometimes it's activated, some times it just fails. This isn't due to changes, this can be the same distro every time. Get used to typing "adb kill-server" alot.
The JDK implementation - well, they broke a few things by not matching the API. Most notably for me the DOM implementation, just something as simple as returning null instead of the empty string for unset attributes can break anything that used the contracted as stated... lots of recoding here
The Eclipse plugin doesn't grok project dependencies - this is absolute killer for work flow. You can't keep projects separate but joined, constantly having to build a JAR of the dependencies sucks for rapid development. The packaging process also can't handle there being more than one version of a class in the classpath - that'd going to get really interesting when integrating with version-ed libraries.
Resource handling under Android blows heartily. In Java it's extremely common to use the class path to reference resources that your code makes use of, be they SQL scripts or game sprites. In fact, large chunks of the JDK are dependent on this very feature. In the land of Android all the classes are baked down into this .DEX file - which is used on the platform. This doesn't account for non-class files placed in the class path so you need some other method. Ideally it would have been something simple, like the resources got packed into a zip file along side the DEX which could be accessed in the normal manner - but oh no, lets go back to the dark ages. It's like working with flipping Flash or MSDEV. Every resources gets an ID - like it didn't have one before - these resources have to be a specific directory. The proper way to access these resources is using a constants class which is created by reading the directory by the IDE. Ick Ick Ick Ick! I'll probably just code round this one, but it's really a misunderstanding of java practice
Performance advice - is given along with the SDK. It essentially says employ all the J2ME hacks you always have. Is this really a step forward or just an extension of the existing API? While and API extension would be welcome, it'd be a lot nicer to see those nasty little hacks disappearing

All in all, it's looking pretty good, especially for a first release. I'm sure at least some of the negatives above are listed on FAQ and readmes some where - but heh, who reads them? The did do one thing very right, very stylish logo:

Hopefully, assuming these tablets work, I'll get some more time to work with the beast and we'll see how it goes.

Wow I got dugg, why don't you Digg It

I CAN HAS MAC?

Sat, 03 Nov 2007 21:42:56 +0000

I have an early christmas present, I am now a member of the OSX generation and the proud owner of a old skool Mac Mini. It's going to be used as a server for some other bits of hardware and for testing my games against (yay, Mac compatibility here I come!).

So far, so good. It's not the quickest machine in the world, it's only an old G4, but everything seems to respond pretty well and the install was pretty painless (apart from irritations with the wireless keyboard and mouse not syncing).

Its going to take some getting used to though, most of the apps and configuration is where I'd expect but the whole framework for applications - the single menu bar, the visibility of running tasks is generally confused me at the moment.

On the bright side I've tested a couple of games against it and both play fine (albeit with a known bug showing up in one of them).

I'll report back as and when I find something good or bad about the box. So far, it's fine but no better or worse than any other system - well, with a little extra visual candy :)

Blogging from MacMini, test 1 complete!

Mighty Morphin Power Diagrams

Wed, 24 Oct 2007 22:11:49 +0000

Was talking to Dan yesterday about possible ways of getting that "Another World" look without doing any real physics - morphing shapes seems to be the order the day. So, a few hours these evening and I have morphing shapes. An hour or so afterwards, I have morphing from one SVG diagram to another (assuming IDs and point indexs stay the same - morphing!).

So, with my limited artist skill I take this:

And build a few SVG, morph then in Slick and get:

Game Match Maker

Tue, 18 Sep 2007 11:59:33 +0000

If you've ever played a session based multiplayer game (CounterStrike, QuakeWorld etc), then you've probably used a game match maker. In essence it's a way of registering a session being provided by a client so that other clients can find it and connect. Normally you're presented with a list of regsitered games which you can click on, starting the game in that session.

This basic register/connect functionality is generally extended with a "lobby" chat that allows the potential players to talk and discuss which session to join etc.

These basic features make networking gaming much more approachable for a new user, removing the need to pass IP addresses around etc. However, it comes at a cost for the developer.

Imageine you're in the situation, I am currently. My game is intended to be played peer2peer - i.e. no central server (though one of the players becomes the server). This is great, I can make the game available and I have to provide no resources (i.e. no central server, or central server process) to support players. Now I need to make the game easy to setup, I need a matchmaker. Damn, now I need:

A central, reliable server
An account that lets me run my match maker server process
Server code to support chat and match maker functionality

The third requirement there seems trivial until you realise the expectations spoilt users have from chat. If the common chat features (PMs, /me, etc) arn't present you'll soon hear about it.

All three points make it costly and potentially risky to provide this sort of service. So, is there a way round it, well there's "a" solution that might help:

The game client talks to a light client side API that makes the services behind look like a normal Java based match maker service. The API lets you do simple things like "register" and "list" games from the match maker. It also abstract away the chat into the very basics.

Behind this API you setup two components - both of which are off the shelf and cheap as the proverbial potato product.

Why write a chat server when IRC already exists? You can either use a custom channel on a public or set up a private IRCd. Using a public channel has it's downfall with other IRC users having the potential to intefere with your lobby, but this could be secured out with private channels. Private IRCd is more work and more cost, but at least you're not having to write and maintain the chat server.

The second component provides the match maker itself. A set of PHP scripts provide a web interface into the match maker database. The client API uses HTTP to access the PHP, which can of course be hosted on any cheap space you can your hands on. Since the scripts will only register games against the source IP of the http request it's also pretty secure - neat? The only downside here is that games don't by default timeout, the first person to connect to game that has shutdown detects the fault, and the game is removed from registration. This could be automated with something as complicated as a cron job (see drupal ;))

Anyway, I think it's a neat and cheap solution. Now if I can only get Endolf to make the match maker code available as a package we won't have to write it again and again :)

Time for a change...

Tue, 18 Sep 2007 11:46:33 +0000

Considering a change of look for Coke and Code. Maybe just a new theme for drupal, but I think I'd like something more subtle.. with shades of greys and pale pinks. I think. When am I going to find time?

Maybe after writing the new tutorials heh?