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.

The Mess that is Pre-Orders

WARNING: lots of words. Probably not a lot of pictures, it's horrendously hot and I have no patience to idly browse Google today. All hail the British Summertime.

Cross-posted from an old forum haunt of mine, but this is one of those incredibly rare cases I'm actually happy with how the post came out. Incredibly. Rare.

It basically boils down to this:

Pre-orders have become popular for one simple reason. Supply and demand.

The general majority of the gaming populace wants what it can get, as fast as it can. Heck that's a thing for humanity in general - Amazon Prime, advanced shipping services, paying for convenience. That's what you're doing here - paying for some modicum of convenience. Publishers, in their infinite wisdom and desire to pile more money on their piles of money (in general, not all of them are typically doing well in that regard - yes, they pay themselves thousands of dollars weekly, but more on that later on), have found a way to monetise this.

However, in monetising this, there also is the catch of receiving money for a product that hasn't been reviewed yet (in most cases) and (in all cases) hasn't been released yet. Paying for beta access, etc, or whatever early-bird access the developers provide, is a relatively new thing that actually does help the case for pre-orders in terms of a real, valuable product you can then access. A positive impact of Kickstarter on the industry, really, avoiding the complete off-topic that is paying for beta-testing. It's all supply and demand. Regardless of the ethics people like arguing about, if you want beta access, it's entirely up to you to invest in that.

So we have bad launches. We have demos that aren't indicative of final gameplay. These have been happening for years. As you get more games, more high-profile games, more coverage of video games in general . . . these cases crop up more. They're more visible. I can't even begin to comment on if they're actually occurring more often, because I don't have any statistics that support this. But they're definitely more visible - which is good, because this puts more pressure on the publisher model to stop simply relying on the mass gaming populace that normally buys into things like pre-orders.

Case in point - Arkham Knight. In an unprecedented move, Warner Bros not only owned up to the mess around the PC launch, but also pulled it from sales so they couldn't get any more money from a broken sale. Steam Refunds are chugging through nicely, and they've made Rocksteady work directly on fixing the PC version to minimise the delay on a solid, working product.

Should it have been that bad in the first place? Absolutely not. But this whole publicly-admitting mistakes and actually following through about it is a rare thing, and in my opinion needs to be valued that bit more. Smack them when they're bad, praise them when they're good. Teach them we're not a mindless pit of money, but also teach them we don't rage indiscriminately. There's a balance there.

But back to pre-orders. Games are expensive to make. Pre-orders gauge interest in a product and allow an early start on recouping investment costs, to show the investors "look by this trend of pre-orders we can expect X sales", which determines whether they think the game will actually do well or not. If a game's going to do bad, it provides an early-bird warning on how to modify their planned strategy to account for this. Likewise if the game will sell well. Sadly, there is always potential for abuse in either situation - bad games get chopped up more to force as much revenue as possible, or good games get chopped up because people know that the gamers will pay for it. Of course, the reverse happens as well.

But that's the important thing. That's the result of investors as an income model, and the direct result of upper management on the development and support of the product itself. Not the developers. That's just business - and sensible business, mind - it's not good for us as consumers or even for the developers themselves. But that's immaterial, because, business. That particular organ machine of doom and gloom trundles on inexhorably. The execs in a publishing firm won't lose money. They'll rarely lose their jobs. Whatever happens, they're safe, they don't care, and short of some kind of capitalist / anti-capitalist revolution, that is how business works. We can't do anything about that, at least in the short term.

All we can do is decide when to pre-order, and while there are arguments to be made for it, you're obviously paying for a non-product (at that time). My personal advice is just make that decision yourself. Don't listen to people that say you need that game, because you don't. It's a fecking video game! But likewise, don't listen to the people that say never pre-order, or shame you into doing so. There are arguments to be made for it, it's just that there's incredibly limited and depending on personal circumstance.

But they are there. This isn't a black and white thing. It's personal choice - remember that.