Game Specification

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

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

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

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

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

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

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!

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'

'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

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:

  1. Eclipse integration - thumbs up. It's simple and quick to get going when you're a normal Eclipse user.
  2. 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.
  3. 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)
  4. 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
  5. 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:

  1. 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.
  2. 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
  3. 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.
  4. 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
  5. 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

XML feed