Honeycomb

So, this is a draft blog post I started back in October, but never really got around to finishing. Coupla reasons why, the first one being that eternally-damned beast known as motivation (well, a lack of it). The second is that I've just been, well, busy. Half of it has been me doing a lot of behind-the-scenes work, and half of it is just a rough month. Honeycomb! went into beta back around then, with some tweaks since. There haven't been many public updates (especially for such a small project) but I've been doing a lot of work behind the scenes.

I mean, all of this evolved out of me procedurally-generating hexagons and using maths (badly) to randomly-generate paths (badly, as it turns out). I was learning to build an actual graphics pipeline in Java, by overriding a single Swing class (JPanel; the general recommended use-case for painting graphics in Java). Before this, a lot of my work was interface / GUI-driven. It rapidly turned into something much more than that.

As with all of my projects, it had a purpose though. 2D graphics in Java. That was the aim, I achieved it, another tick box on the eternal To-Do List of Doom™ (patent pending). Very simple stuff, compared to most of the developers out there. As usual, I uncovered a bunch of faults with my implementation (fixed-step renderer is the biggest, but not the only one). In no particular order:

1. Fixed-step renderer. Basically, the main thread the game panel was running on I put to sleep every cycle for 1/60th of a second. This will give me somewhere just under 60FPS, dependent on the overall time cost of sixty cycles. Very simple, stops a simple 2D Java game from thrashing the CPU too much. Fraught with issues. What if 60FPS isn't ideal? What if the time cost exceeds, well, 0? This is why the game is a bit slower (though apparently people haven't noticed) on older CPU setups. Easy enough for me to notice even without a profiler as I switch between my 1.8GHz i5 laptop edition CPU at work, and my 3.4GHz i5 desktop edition CPU at home.

(for those so inclined, the work CPU is an i5-3337U and my home CPU is an i5-3570K. Benchmarks for the Benchmark God, etc)

2. I had no idea what I was doing. Okay, so this is probably a bit hyperbolic, but yeah. This started out as a technical test, it was never intended to be a game. When I got to things like score-tracking, and passing stuff around the core classes? It got a bit messy (though thankfully the initial structure was solid and I didn't have to rewrite too much for the extra logic). There are funny little bits here and there, like how the hexagons render on top of each other (in horizontal then vertical order) so you get weird overlapping when you Ctrl-drag a bunch of hexagons at once. I've got a quick fix for that (draw the hexagonal borders after the main hex shape; two separate loops as supposed to one) but in general, in future, this could be solved at a conceptual level.


3. Benchmarking. I'm not familiar with it. Certainly, I'm adept at writing decent Swing code that doesn't have a hissy fit whenever you open a file dialog, and I'm good at cold start vs. start when it comes to launching Java applications from the platform (a small splash screen goes a long way). But this is something a lot lower down than the whole Swing stack, and it requires a whole lot of System.currentTimeMillis() to manage effectively. I probably need to subclass that in future and keep a constant track of various different time states. As it was, when I had to implement pause functionality I nearly stabbed my screen trying to work out interactions with the main game thread, the overall GUI implementation and how to update that codewise and visually.

Not that this helped at all, and there really isn't much of a nicer way to do it. Well, apart from write your own class / utility to handle timestamp rendering from the ground-up.

 

4. Redundant code. Like, lots of redundant code. My game is (sensibly) controlled by states, and for each of these states the renderer does something different (again, sensibly). The problem is when I copypaste the same twenty to a hundred lines of code for each game state (of which there ended up being several). This is the problem with rapidly-iterating on a concept without the benefit of a code review, or similar. Teamwork would expose this relatively quickly, but working by myself I always manage to catch myself a bit too late.

The same goes for the GUI logic. I'm very used to Java's Swing library and all it entails, I'm pretty proficient with it. Problem is you have access to none of that when you're painting everything manually in Graphics2D. A lot of pixel-perfect drawRect() calls, for example.

Which leads me nicely onto what went right with the project, and why I'm now working on something separate (but not completely separate) that for the sake of having to have human-readable project names I've called PlayerDemo. This is another experiment to work on a system / library that handles Shape-based GUI objects in the context of Graphics2D. You add your visual assets, you define a Shape for them to inhabit, and the whole process is made quite easy.

This was after my success in making a graphical font system that takes in a spritemap / bitmap of your font characters and maps them to an a - z / A - Z / 0 - 9 / non-alphanumerics sequence (that can be programmatically-defined). This allowed me to easily use a custom font throughout Honeycomb! that is far better than anything I could've made in the conventional TrueType format. At the moment it favours monospaced font creations, but I can extend that quite easily. The hard work is done, really.

So, a lot of progress. More updates for Honeycomb! in the future, especially when I get these Shape-driven classes fixed up. Will make building a more involved UI easier going forwards, adding in game options, etc.

Watch this space!

Anxiety

So this is my first post after updating Blogger to use my new email address. If something breaks, that's probably why.

Disclaimer: tech stuff and emotional feelings throughout. You have been warned!

I released a small prototype today - https://gorbles.itch.io/honeycomb-alpha - made entirely in Java with no libraries beyond the JRE.

The splash page for itch.io

 
This is a bit of a milestone, as simplistic and crude as the prototype is. I can create far better UI graphics by overriding Swing code (part of the JRE, still), or even in GIMP. I can make better ingame graphics the same way. I can do low-poly 3D models, and I'm familiar with older versions of the Unity Engine (Unreal still daunts me a bit). I can do bits of everything, really, a something-lower-than-a-jack of many trades. But this prototype is important, because I took a basic concept (hey let's make hexagons in Java) and I drove it to completion as well as managing to form a game out of it.

The game was unintentional, you see. I was just playing around generating sequences of hexagons that would line up nicely and spin when you hover over them (as well as the usual thing of highlights and lowlights when clicking / unclicking them). After X iterations and testing I came across a bug where all previous highlights up to Y were being kept, so I had a kinda mouse trail of highlighted hexagons. I fixed the bug, but the bug got me thinking.

"this is a way to select them easily"

This is another bug that happened

It took a lot more than that to create a draggable mode of selection, but that isn't important. Inspiration struck, I seized it, and now I have a small game that actually works how I want it to. How does this relate to anxiety, right?

Anxiety's a bit of an odd one. It can be a medical condition to the best of my knowledge, and it can just be that thing that controls your nerves before you do something you're not entirely comfortable with. It relates to how I feel a lot of the time, as good as I am at covering it up. Make a post about programming? Anxious, yes. Dealing with a problematic client? Gods, yes. Bathing the kittens? You get the point.

But this game, this little, ultimately-insignificant event, triggered more anxiety in me than most things I've felt recently. Possibly due to me not feeling much of anything recently? Personal events, family events. They hurt, and I'm dealing with them. But they come with a form of numbness. This game kinda broke that to an extent - and that's a good thing! I think. When I'm not feeling anxious, haha.

What criticism will I get? Will I get any criticism? Will anybody actually pay attention? Who knows? Who knows anything, really.

I'll probably feel a lot more reasonable tomorrow, when the nerves calm down. Or when I eventually pull myself out of this funk I've been in for the past couple of months. I have the energy to program again, now, which is fantastic. A really good feeling. And this is what I have created with that energy - more positivity.

I think the thing that makes me more anxious, really, is the realisation that I can actually complete things. I have less excuses to rely on, now. The more you know, eh?

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.

A Break in Character; Criticism of Video Games and Art

Going away from my stereotypical moaning about day to day life, or my fascination with Java (perhaps some form of madness, but it's too early to tell), I'm going to be talking about something that I find quite interesting.

Warning: this article won't contain any pictures. I can't guarantee it will be short, either. Read on at your own peril.

There's been a thing over the Internet for the past few months, which I won't get into the specifics of because it really helps no-one, that is apparently campaigning for, well, various things. I wouldn't exactly say it's succeeding at any of them, but a core principle is that it rejects the criticism of video games as an art form.

Distressingly, I've seen this opinion thrown about my old haunts across the Web, and it becomes very hard to have a mature debate on the subject. Other people get mad, I get mad, it gets to be a mess. You're on the Internet, you know the drill. People don't seem to grasp the concept that art isn't perfect. This mantra of "the developer's intent must be preserved".

Why?

Criticism drives progress. If we never changed anything, we'd never progress as a species. To hold, say, Call of Duty: Black Ops up as a shining example of video game art (it's an example, just an example, haha) . . . but prevent criticism from affecting that product, or future products? What progress are we making there?

People throw out the example of novels as art that hasn't been changed, so "how dare you change video games". Well, for starters, a novel changes about a bazillion times before it makes it to the editor, nevermind the iterations after that before it makes print. So to claim that criticism doesn't affect a novel's creative process is . . . flat out wrong. People also use the literal form - actual artwork. The problem here is that a piece of artwork is static. Once created, you don't generally go back and scrawl all over it (notable and famous exceptions exist, of course). You incorporate your mistakes and progress going forwards. Your pieces get better, or your style changes. You improve as a painter / sketch artist / you name it.

None of this works as a comparison with video games. I mean, it might work if a video game was released and then never touched again, and developers never patched their product. But the same people who are shouting about preserving the artistic intent of the creators . . . also demand post-release support. They vilify developers who, for whatever reason, don't patch the game to these users' specific likings. Balance patches, content patches, bug fixes. Arguments about whether a specific mechanic is bugged or if the developer simply intended it to work that way (with a liberal amount of 'well that way is stupid they should fix it' thrown in for good measure). I'm not singling out a single forum here, or community, or even a user. I see it all over. Heck, I used to be particularly guilty of it myself. Thankfully, with much less free time to spend on forums, I don't get dragged down in so many arguments. Certainly, barely any about that horrific entity known as game balance.

So games 'have' to be supported. The games therefore change, often with feedback from the community around that game.

But the 'artistic vision' is beyond reproach? This really isn't a consistent argument, is it?

And yet people think it is. People get so angry over the reload time of a fictional gun in a futurstic shooter and demand the developer change it to suit them. But when people get angry, or offended, over the inclusion of a volatile piece of worldbuilding? Their offense isn't important enough to warrant a change.

Weird, isn't it? Especially when you consider this specific example (that's exploded over the Internet recently) has been generated by a member of the community, and isn't a part of the artistic vision of the developers in the slightest.

An increasing lack of sound logic, right there. Games need to change in face of legitimate criticism, in order to reach the same heights that older art forms have reached. Only by making games better can we actually call them 'art' in the first place.

No?