Hobnob's site

Bunch of Lightweights

Wed, 02 Sep 2009 18:24:52 +0000

Chatters has been on a Minecraft kick recently, and from that I discovered LWJGL, the Lightweight Java Game Library. This provides a Java program easy access to a bunch of useful stuff for games programming, including OpenGL.

Now I've tried using OpenGL in Java before, and found it a right pain. LWJGL however is pretty transparent, and about as easy as you could make an OpenGL interface while retaining full functionality.

Playing around with it produced this, which should look at least slightly familiar to some people:

Probably nothing will come of it, but it's a fun project to try while (re-)learning OpenGL. One thing I've found is that I desperately need a more modern book on the subject, since the reference I have are massively outdated.

One interesting thing is that this is a "real" 3D display, rather than the fixed-viewpoint of a traditional sprite-based isometric display. This means it can be spun and viewed from any direction, rather like the game Dungeon Keeper. Actually something like this would probably be necessary if it were ever a real game, since otherwise things get hidden by walls too easily.

Also the networking aspect might be fun to try, since LWJGL lets you run the client as a browser applet, connected to a server on the backend. That is a seriously neat and useful way of doing things, since everything necessary is downloaded by the player automatically.

Don't you wish BYOND could do this stuff easily? Maybe one day.

Spacewar!

Sat, 25 Jul 2009 20:22:26 +0000

The Dream Makers article on vectors I mentioned in the previous post is almost finished. All that's left to do is finish off the sections on describing how the example demos use vectors, which shouldn't take very long. As another teaser, here is the third and final demo, and the only one of them that could be described as a full game: It's a version of Spacewar!

If you've never heard of it, this was one of the very first computer games ever written, and as such it's an important part of gaming history. It's a two player game in the old-fashioned sense - both players sharing the same keyboard.

Full source for all the demos will be available when the article is finished, which should be within a few days if I can manage it.

Edit: The source for all three demos has now been release - see the Demos box to the left. The article is finished, and just needs some formatting and proof reading before I will submit it.

Ima chargin' my lazors

Thu, 16 Jul 2009 20:08:29 +0000

I'm currently writing an article for Dream Makers giving an introduction to vectors and the jt_vectors library. As part of it, I'm writing a few demos to show how to use them.

Here's a little taste of the first one that's ready. For sure it's not going to win any prizes for graphics or sound design, but it's reasonably fun to play with. See if you can shoot all 25 targets!

Get Something Done: Railroad Tycoon as an inspiration

Thu, 07 May 2009 21:17:36 +0000

So as I said in the previous post, the Something that I am resolving to Get Done will be inspired by Railroad Tycoon. If you've never played that game, I will give a brief recap as many aspects of my game will be based on it. RT was a business simulation in which you built a railway across a map (various regions were playable, such as the UK, Europe, Eastern US etc.). To make money, you ran trains which picked up and delivered cargoes, such as mail and passengers between towns and cities, and materials and goods between industries and ports. It cost you money to build new track, stations and trains, and you had to pay maintenance on what you already had.

Playing against you were (up to three) computer-controlled opponents, theoretically doing the same thing as you (though one of the major annoyances of RT was that the AI followed very different rules than the player, joining cities to cities with straight-line track and obviously operating some kind of statistical simulation of profit rather than actual trains and cargoes). You couldn't cross an opponent's track with your own, so it was pretty easy to get boxed in by enemies, with the only way to expand being to initiate a "rate war" by running a track into an opponent's station. There were also various financial machinations where you could buy and sell stock in all the railroads to attempt to get a controlling interest and make more money.

As the game progressed, newer locomotives would be introduced - for instance, in the UK scenario starting in 1830, you start with only the rather low powered Planet class engine, which can barely pull one wagon, and as time goes on get newer and better steam engines which can pull heavier loads and do so faster, and eventually diesel and electric locomotives which can pull large trains at high speed. The more cargo you deliver and the faster you deliver it, the more money you earn, so upgrading the engines is a must.

One slightly odd aspect of the game is that the economic simulation runs at a different rate than the train simulation. Thus though you see trains moving from city to city pulling their loads, they might take a year or more of game time to make a single trip (with a year corresponding to about 10 minutes of real time). The official explanation of this is that a single day of train operations is expanded to a two-year fiscal period, with each day representing the average performance of the train over the whole period. This is a bit hard to graps at first, but actually works quite well, giving you a feel for the movement and efficiency of the trains, but allowing time to progress fast enough that building new tracks and introducing new engines makes sense. It's a scheme that I will probably be following with my game.

So that was Railroad Tycoon, but as I said before although my game will be inspired by it, I don't intend to make a slavish copy of it. I want the game to be more like a virtual train set - you will control trains individually, for instance (though a certain amount of automation with signals and an "automatic driver" will be possible), unlike RT where trains moved from station to station without human intervention. Another major difference will be the much closer scale - stations won't be a single-tile object, but spread over a number of tiles, with platforms and buildings that can be placed next to the track. Wagons won't magically appear when needed (as in RT), but will need to be built and stored at sidings and shunted to the right locations. This will make my game a rather more micro-managed sim than RT, but hopefully by good design can be kept fun. More details of these aspects in later posts, plus how things will work as a multiplayer game, but for the moment I want to talk about the graphics.

Railroad Tycoon was a strictly 2D, top-down experience, and looks rather dated even compared to many BYOND games nowadays. The series didn't end there though - RT2 introduced isometric graphics, and RT3 was a full-3D environment with a free camera. I'd like to upgrade the graphics somewhat over RT's top-down look, and isometric is the obvious way to go. But there are complications as I'll explain.

Most "isometric" game don't use a true isometric projection, instead opting for a so-called 1:2 isometric which looks better when applied to pixel art. Technically, a cube drawn in true isometric would have it's top and bottom edges at 30° to the horizontal, but in 1:2 isometric they are instead at 26.6° (= atan(0.5)). In BYOND, though, even pseudo-isometric is tricky to do. We are stuck with a uniform 2D grid which imposes a lot of work on a programmer trying to adapt it to the non-uniform vertical scale of isometric projection. Instead, I'm going for a compromise, called military projection, where the cube's edges are 45° to the horizontal. Although this looks a little distorted, it emphasises a top-down view over the side view, and there is no need to fight the standard BYOND grid at every stage. Another benefit of the near-top-down view is that fewer objects will overlap those behind them - always a problem in isometric systems, since you are looking more to the side. The few remaining cases (e.g. tall buildings or structures) can be handled by careful use of the object layers.

More details, and perhaps some placeholder art to show the "look" of the game, in the next update. So far the game doesn't have a finalized name - for a while, I was using Railway Tycoon, currently I'm thinking Age of Steam, though that's also a misnomer since I fully intend to cover diesel and electric locomotives as well. Perhaps a name will suggest itself as the game progresses.

Slow ones, they don't get nothin' done son.

Tue, 05 May 2009 20:08:01 +0000

So as you can see, I haven't got anywhere with my Naval RTS game Warspite, partly because of lack of free time, and partly because of lack of motivation. Most of this demotivation is because the tech demos quickly showed how badly the pixel movement worked over a network. Even over a LAN, gameplay was jerky and annoying, and attempts to play with a remote server and any kind of real lag were awful. Since the RTS was always envisioned as multiplayer, this is a big problem.

I hope to resurrect the game eventually, either as a single player game (which would remove the movement problems but require a lot of work developing an AI to be worthwhile), or perhaps just finish it as the intended multiplayer game and hope that it would be playable enough, and the jerky feel could be improved eventually (possibly by improvements to BYOND itself). However, for the moment it is on permanent hiatus.

Recently, IainPeregrine's Get Something Done caught my attention. Since I've been failing to Get Anything Done for a while now, it's possible an external framework might help with my motivation a bit. I have about four ideas percolating, none of which have got any further than paper (apart from a few small test programs for various systems). The common feature of all the ideas is that they basically follow BYOND's traditional tile-based layout, which should help development immensely.

My current favourite is inspired by the old ST/Amiga/PC favourite Railroad Tycoon, though rather modified from that game (there's little point in making a straight copy, since the original is available to download for free). For one thing, it's intended to be multiplayer rather than single player, and for another, I want it to be rather smaller scale than RT was, with more emphasis on control and movement of the trains, and less on financial manipulation of stocks etc. In many ways, it'll be a virtual train set with a game bolted on to provide some competitive interest. More details in my next update.

Down to a Sunless Sea

Thu, 20 Nov 2008 18:45:15 +0000

Work on the RTS continues, and I now have an updated demo with the ships shooting back at you! That doesn't sound like a lot of progress, but it required a fair bit of behind-the-scenes effort. Ships now have attachment points (for guns and other effects), each ship has a number of gun objects defined (with a set size and turning range), and ships now track nearby enemies.

It also required some graphic work for the flak and gun firing effects, which probably took the longest since my pixel art abilities aren't great. They look good enough for now, but I have to wonder why Photoshop's handing of PNG transparency is so broken. I had considered making the actual gun turrets on each ship rotate visibly, but the scale is small enough that nothing would be really visible, except perhaps for the battleship's large guns.

So far, ships only fire on enemy aircraft (and again you can only control aircraft in the demo), but ship-to-ship attacks should be a simple extension. Dodging the flak fire makes the demo much more challenging, especially against destroyers, so watch out for the buggers.

The next part of development will improve the damage model (so far everything has a simple number of hitpoints, but I want it to be possible to, e.g., destroy a particular turret or reduce a ship's speed, depending on where it is hit). After that, I will try to settle on the ship control interface (though probably not the final game interface) including such things as manual and auto-aggressive firing and escorting other ships.

First Demo

Tue, 11 Nov 2008 19:51:41 +0000

I've now done some testing of the game while running over a network, and as I was half-fearing, it turns out to be irritating jerky, even when just playing over a small LAN. It seems that BYOND's networking just doesn't handle smooth pixel scrolling well.

It's mostly a problem with fast moving craft (like airplanes), so it will be less noticeable for the slower-moving ships which will form the main part of the game. I may just live with the problem, though there are alternatives such as making aircraft a non-pilotable craft.

I now have a demo available that shows off some of the game systems. You fly a torpedo bomber and destroy NPC ships and aircraft (which move around, but don't yet fire back).

Please bear in mind that this demo is quite different from the way I envision the final game (it's more like an action game than an RTS), there's no sound, and some of graphics are placeholders. The multiplayer support is also quite rudimentary.

Ships That Collide in the Night (II)

Fri, 07 Nov 2008 20:55:21 +0000

Ship collisions are now working, though unfortunately the method I discussed last post proved a little too inefficient. So now, after the tile-based collider objects find a hit, a secondary object-aligned bounding box is tested between each ship, and then finally the expensive hull-hull vector intersection is run. This new scheme seems efficient enough that, short of a pathological situation (e.g. lots of ships together in a small area, all almost touching), the server should be able to cope.

With collisions working, I'm now able to detect torpedo hits on the ships, which smoke when they take damage, and explode satisfyingly when hit enough times. I also have given the client a plane with a rudimentary control system (click a turf to fly in that direction, double click to release a torpedo).

This seems to be fun enough that even if the multi-player RTS aspect turns out not to be possible, I may end up making a single-player game based on the system. Ships, however, don't fire back yet, nor do they do anything other than move in one direction. The firing back requires some substantial programming (plus new graphics for flak, gun firing, etc.) so that will wait for a bit. However, a simple ship movement system where they follow a set path should be easy enough to implement.

With this done, I'll be able to release the promised tech demo of my work so far. This will be nothing like the final game, but it should be enough to see how well the system will behave under network conditions.

Ships That Collide in the Night

Wed, 29 Oct 2008 07:39:10 +0000

Work on the naval RTS game continues, with a few issues turning up that required some redesign. I now have red and blue-team flashes for each ship marking the deck, since my original team marking scheme didn't look good. And I found that even with 32 ship direction states, the three largest vessels (carrier, battleship & cruiser) appeared too "jumpy" when they rotated. These three now have 64 direction states (which fortunately are easy enough to render and import), and the ship code updated to support them.

Collision detection is going to be an important part of the game implementation - as well as ship-to-ship collisions, I want weapon hits to be accurately placed. Ship turret guns will be semi-automatically aimed, but the hit location will vary depending on range and relative movement, etc. There will also be some weapons (torpedoes and bombs) that have some element of aiming required, and their hit locations need to be accurate too.

The method I'm using wraps a set of points around the outline of the ship (defined using a small Java utility I wrote). Vectors between each point can then, with a bit of vector maths, be used to find if a point is inside the outline, or if another vector crosses them. This calculation is relatively "expensive" to compute, so comparing every ship to every other ship is out.

Instead I plan to cull the potential collisions using a grid approach - handily enough, based on BYOND's standard tile grid. This picture shows each ship overlaid with collision objects (red boxes), which are recomputed every time a ship moves. A ship can only collide with another ship if two collision boxes overlay each other, at which point I can perform the expensive vector-based calculation. Likewise, a weapon shot can only hit if it's inside a collision box. You can see in a few cases this is not perfect - ships sometimes aren't completely covered by collision boxes - but it should be good enough.

The collision method would also allow sub-tile collisions with land turfs, should I want to do so. Currently turfs are just green land tiles in a blue tile sea, but I hope to make them prettier for the real game. Turfs, bases (shipyards etc.) and the occasional explosion effect will be the only non-externally generated pixel art I need, so hopefully my limited skills will be up to it.

Once collisions are working, short of a major problem, I am planning a tech-demo release of what I have so far. This will probably have some minor playablity (I'm thinking torpedo-bombers vs. NPC ships), but will mostly be for checking the game viability under network conditions.

Nothing Is Sure In a Sea Fight Above All

Fri, 24 Oct 2008 01:07:19 +0000

Taking a break from OpenSS13 for a while (still lots of stuff I want to add to it, but not for the moment). Instead I'm working on a completely different project, an RTS naval combat game.

This is an idea I've had kicking around for a while, in various forms. The concept is a two-team game (1 or more players per team) where each player controls a single ship at a time, and can swap to other ships at will. I'm aiming for a WWII-era sea combat feel, though without submarines at least for the moment.

I'm planning 8 ship types (from motor torpedo boats up to aircraft carriers, and an unarmed cargo ship), with unit building limited by base upgrades rather than any kind of research tree. You'll also be able to build new bases in redefined parts of the map, and the win condition is destroying all your enemy's bases.

So far I have ship display working, with pixel positioning and scrolling, and 32 movement directions. The ship graphics were traced from various deck plans using Adobe Illustrator, then rotated to each of the 32 directions and rendered. I then used some small custom Java programs to chop up each PNG file into chunks useful for importing as a DMI file.

A quick test showed the display of 250 ships is fast enough that under real conditions (max 30 or so ships active) I shouldn't have any problems with speed.

The next job is collision detection, ship-to-ship and ship-to-land, which needs to be pixel-precise, so I'll probably be using a crossing-vector method with each ship's outline. Fortunately DM's built in tile system works for quick-culling of potential collisions, so speed should be tolerable.

I'm still deciding on the role of aircraft (perhaps player controllable just like a ship), and overall ship speed. I don't want a twitch game, so I'm thinking of a quite slow pace to
movement (except for fast things like MTBs and aircraft). After some research, I was surprised to find that WWII-era carriers and battleships tended to move faster than frigates and smaller craft. I will probably forsake realism and make bigger ships slower than smaller ones, for the sake of balance.