Sunday 26 July 2015

Building Game Tech II

So I did this a while back. Actually, not as far back as I thought I'd done it. I came to Blogger thinking of this piece under the (mistaken) impression that the first article was one of my dinosaur articles, somewhat back in the dim depths of time and from the perspective of a far more youthful, exuberant Sean.

Alas, while it was made by a more youthful and far more exuberant Sean (real life trudges inevitably onwards and waits for no man, woman, child or dead horse), it was not made at the start of Time itself. So there's not so much more I've actually learned exactly in the past year, six months or whatever. This piece is more of a splurge, a dumping of thoughts, on Java as a whole and what progress I've made in bending it to my will. As well as making a GUI not look like complete arse because apparently that's a design directive over at Oracle. Make ugly shit.

Java ain't bad at all, you know I think that. But goddamnit if Swing isn't the most ass-backwards GUI library known to mankind. I mean sure, it works. But an STI works in that it's transmitted by sex. So something working isn't really always equated with something working well.




After writing that analogy that I was childishly-impressed by, Real Life™ intervened (again) and I put this piece on hold for a week or so. Now I'm back at it, and I've been back at a variety of my Java projects. Which helps, because I've come across (again, re-come across?) areas of Swing that not only want to make me claw out my eyeballs, but also inflict this rather gory attack on completely random people outside the relative safety of my house. It's that annoying. And well-known! So I won't dwell on the particulars too much, as people familiar with GUI-building in Java know my pain. Everyone else will either not care or find some small amount of amusement at my frustrations, which also works.

Building game tech! In Java! The point of this ramble, at least. Disclaimer ahead:

Warning: this post contains a lot of specialist language and stuff. Familiarity with programming is recommended.


In my old post, I gave some recommended dos and don'ts. Very simple stuff, no-nonsense there. That said, while libraries are good and writing your own code (for established concepts) often gets messy, fast, I'd like to amend my advice a bit:

  • Don't automatically build things from scratch. Know where to spend your time, and how to build re-usable code.
  • Libraries are not bad things. However, you are perfectly capable of putting together a library of your own that features functions and classes you like re-using..
  • Don't be afraid to experiment.

Also, libraries you build yourself can be project-specific. I have a set of extended Swing classes for use in an RPG I'm building, because I know the style I prefer for the UI and it's working out well visually. They're not infinitely-flexible, though. You get into the habit of writing too many constructors for classes when in fact you don't need that many, you're just writing constructors for some minute possibility of needing them in the future. Don't do that. Good code maintenance is key, but you can write adaptable classes without writing fifteen different constructors for the wide range of UI features you might possibly implement at some point.

Newer, more condensed code I built from my RPG UI work

Important note. This only applies to you writing code for your own use. Working in teams brings a whole new dynamic at to the table that I don't feel qualified to write much about at the moment - my games experience is mostly solo. My job is team-based, and my old games modifications were team-based. So maybe, at some point I might.

Of course there's the likelihood you might go back and rip it all out at some point, but after more than a few years of programming this happens on a semi-yearly basis regardless. Aim for as good as you can at the time. You'll always be learning new things and better ways to optimise old code. That's the thing about our discipline, really. Truly beautiful comes around once every blue moon and is sometimes done on purpose. There really are wizards out there, Harry, and they write magical code. But don't pretend to be them. They got there by hard work, just like every competent craftsman and woman does. There are no shortcuts.

Admittedly most of what I've talked about here is UI tech more than game tech, but I feel I should give you guys and gals another "rule" to follow:

  • UI is incredibly important, don't half-ass it or assume the "vanilla look will get you by".

The "vanilla" look for Java is horrible. I don't have any screenshots and I'm not really in the mood to specifically drum up any. I mean, "horrible" is subjective in that it's what I think, but I'd like to think most artsy types out there would agree with me. It's something of an abomination. This isn't important for tools, or anything like that. I'm talking specifically about building "pretty" things that you actually want people to look at for any length of time. Even the default Windows look is bad enough. I've mentioned a custom ComboBoxRenderer before, and that's because the default ComboBox is small, thin and has no padding whatsoever. I have to create a custom class to get them to look bigger and have some padding between the edges and the text inside. There are no round buttons (note: Java 8 may have changed things in that regard, but I don't know because I haven't fully made the jump there yet). Here, have a look at my old character creation screen, compared with a very quick WIP of the newer one (before it evolved into the more final product, see below):

Custom rounded JButtons, a well-defined set of LayoutManagers and a custom ComboBoxRenderer

I got relatively annoyed with it (in the meantime, you see, I've done a lot of web design / frontend implementation and honestly I've learned quite a lot) so I tossed it in the bin and literally rewrote it from scratch. Custom JComponents across the board. Custom JPanels with better Color / background painting support. Custom JButtons. The same custom ComboBoxRenderer I've been using for ages (seriously Oracle it is not hard to add Insets to a renderer). A special custom JPanel with animation support (that you can't see animated on the screenshot below, but it's the elemental icon in the top-right). I created an entire pixel-based font to use specifically in the game, which impressed the better half more than anything else I've made to date. She's not technical, which goes to show you what an impact detail can have on the end user. Behold!

A character creation screenshot from Phantasmagoria Miniature, my 2D Java RPG

A lot of this is common sense, to achieve a specific look you have to write more than what is provided with the language by default. But please, interface design is more important than perhaps you'd think it to be. Learn it! Practise it! It's a massive pain in the rear end in Java, probably more than comparable languages (C#, at least), but I think you'll agree it pays off at least a little bit.

Don't rely on what Java provides for you with Swing. Please, think of the kittens.


No comments :

Post a Comment