Messing around in boats: Part the Next.

Making those hoverzellepins has got me thinking about my set design for Pineapple Boats (tentative codename: BALLAST).

I described in my earlier post the set design which has been hanging around since February; different generational graphics on single IDs, narrowly refittable cargo classes, BAD FEATURES galore. So tonight, I came up with a new design:

ballastplan16 ships – a nice round number – featuring ships from steam to modern, and a sailing ship for those wonderful people who like to start their games super early.

A few key points of this set design to consider:

  • High-capacities, and a large range of capacities, to suit different industry sets and different playstyles.
  • Nice round numbers make it easy to judge ships at a glance. I’ve found rounding off the capacities in Av9.8 has made it much more pleasant to play with. In the table I’ve also included the equivalent capacity in 10CC train cars – I think this is a useful way to visualise ship sizes.
  • Extensive refitting options, and gameplay in those options. Have a look at the Steam Trader and Steam Freighter. Same introduction date, same capacity, same speed. So why is the Trader more expensive? Because it can refit to more cargo types, making it more flexible. Refit-in-stations makes carrying multiple cargos with one ship much more feasible. Good job OpenTTD devs. 😀
  • On the other hand, this set has no differentiation between “ocean” and “canal” ships or speeds. I’m not sure this difference makes much sense to players. I know it doesn’t make much sense to me, in a TTD context.

16 ships. Two are done already. 😀 A couple more things I have to think about: firstly, these ship sprites are huge. Limiting the number of sprite sets is very important, to keep the NewGRF file size down; this means limiting livery differences and visible cargos. It also means no animated ship wakes or washes – the ships will just have to glide over the water for now, until wake effects can be produced using the smoke/steam effect system.

Nevertheless, hopefully it will be a fun set to play with, and will a worthwhile addition to the 32bpp/EZ catalogue. As always, keep watching this space.

The Hoverzellepins are coming…

Image13Andy actually wants a full-cabin passenger hovercraft for FISH, but I started with the deck well container carrier. Just because it’s cool. :)

This vehicle will be rendered in 32bpp EZ for Pineapple Ships, as well as being rendered in unanti-aliased, normal zoom, TTD pallette for FISH. It’s a good job I kept all my palette-swapping scripts I used to use for Av8!

Edit: for those interested, here is the cabin version (in mauve company colour):hovzep_cab

And finally, the raw 8bpp/nz sprites for FISH. Andy will presumably tidy up the pixels on these a bit (or get some other poor sap to do it 😉 ) before they’re incorporated into that NewGRF.hovzep8p

River City

I went on a boat ride earlier in the week, to get some references and inspiration for TaI (“Pineapple Houses”, I suppose). I took about 250 photos. Here are five.
rc1 rc2 rc3 rc4rc5I have come to two conclusions: firstly, that I need to repeat the exercise with a better camera; and secondly, that one only has to look around to plenty of good material for a building set. Obviously, these big modern buildings aren’t all TaI will need; a few photographic expeditions to other parts of the city will be required, also.

Basic ship geometry

Here’s a test render. It looks huge, but this is the actual 4x sprite size!

bootThis is two tiles long and not-quite-one-tile wide. It looks a bit dull at the moment, but with cargo-specific detailing, water reflections and proper materials it should end up quite nice. I hope.

Messing around in boats

Ships are probably the most neglected transport method in NewGRF. The only two complete sets are mb’s venerable NewShips from 2003 (!), and andythenorth’s FISH / SQUID.

Andy’s ideas for FISH are constantly changing, and he’s asked me to contribute some graphics for the set. If I’m doing ship graphics, I may as well create Pineapple Ships at the same time. So, time to set designing!

The default ships are pretty uninspiring:

shipsPart of the reason for this is that there’s little to distinguish between different ship models. They all travel at roughly the same speed; they don’t have tractive effort or power simulation; and – unlike all other transport types – their routes cannot become congested, because they pass through each other and an infinite number can use one dock. In a word, ships are boring.

  • Because ships are boring, players don’t use them much. They’re mainly used to transport cargos across water (obviously) which isn’t easily bridgable, and as a first (from oil rigs) or last (across the bay) stage in a feeder system.
  • A variety of sizes are required. True, there’s no real gameplay difference between having one big ship or three small ones. But having a lot of ships on one route, all crowding and overlapping each other, doesn’t look very nice. We can make ships look nice, even if they’re boring to use.
  • Ships can be refittable – indeed, they were refittable in the original TT. This, possibly, makes them more flexible, especially with the refitting in stations feature. They’d be much more flexible if they could have multiple holds (“articulated” ships), but that’s a discussion for another day.
  • Hovercraft. Hovercraft hovercraft hovercraft.

So, my current thinking on Pineapple Ships is this:

  • Three generations of cargo ships (small, medium, large). The earlier generations will not expire: they will remain with the same stats throughout, but have their graphics updated (eg, steam to MV). The goal is to cover the different size bases while not cluttering the purchase list.
  • Separate piece/goods carriers, bulk, and tanker ships, each refittable (within its cargo class) at the dock.
  • Fun special ships! Ferries, hovercraft, and maybe a barquentine early on.

As with the Pineapple Trains, the overall aim is to create a feeling of simplicity and vanillaness, but with the extra playability provided by OpenTTD features like refitting and simple variable running costs. And pretty extra-zoom graphics.

Watch this space.


 

In other news, the Pineapple Trains update is completed!
powerupdateThese five new locomotives are now available from the in-game content (or will be shortly – uploading 160mb takes a while!), and the version number of the set is now 1.1. Enjoy, and as usual please report any problems in the forum thread.

100%

Many strategy-game players (and designers) seem to believe that maximum efficiency is the default state; if you don’t have 100% ratings for everything, all the time, it means your strategy – or the game mechanic – is defective. This is certainly the case in OpenTTD, and is something I try to subvert when I can. The Pineapple Trains, for example, are fast but underpowered, meaning a heavy train might take half its route to reach its nominal top speed (if it reaches it at all), rather than hitting top speed before it’s out of the station as more “realistic” train sets do.

With that said, I am hesitantly adding a little more power to the roster in the next update to Pineapple Trains. The update will include five new locomotives, bringing the total count up to 20. Included are a third “Stanley” steamer – a large-boilered 2-8-0; two low-speed, high-power electrics; and the return of a TT classic:
turbosThis latest incarnation of the Turbo is a DMU, with passenger capacity, but you can still use it to haul coal if you really want to. :)

Look out for the Pineapple Trains “Power!” update, coming to the in-game content system, Bananananas, in the next couple of weeks! In the meantime, you can find the forum thread for the set here. I should think about resurrecting the wiki, too…

Evolution of a render

As I’ve been developing the 10CC train set, I’ve gone through three different render “standards”. Hopefully, I won’t do too many more, as every time I change the standard I have to rerender everything!
evo1
This was my initial render style, as I posted earlier. At this point I was still thinking very pixelly – chunky stripes and distinct outlines.

evo2
My first redo involved antialiasing the sprites and filtering the textures (I individually unfilter textures which need to look noisy, such as hopper loads). I also changed the material properties so, rather than using a flat specularity, the main texture was used as a spec map. This meant dark details didn’t get washed out so much, but it did tend to make light liveries look shiny and dark liveries look matte.

The eagle-eyed will also note a change in the model here – the nose has been shortened to reveal the coupler more. The original Chief model had the nose extend out past the end of the “vehicle”, which looked fine on a lead engine, but produced clipping when it was against another vehicle (and was particularly egregious, obviously, when two Chiefs were coupled nose-to-nose).

evo3
My second – and hopefully last! – redo introduced a dedicated spec map, which allowed the darker liveries to also look shiny. I also added an additional light in the scene directly above the model, lighting the roof more evenly. This brings the back side of the model forward and makes it look a lot more “solid”, as well as showing truer colours on the top of objects – I first realised I needed this light when rendering flat-topped containers, which looked very strange with their tops much darker than their sides.

Image4
It’s going well. :) I’ll be moving on to ground tiles and the beginnings of the base set when I’m done with the trains.

A Matter of Perspective

Transport Tycoon’s vehicle sprites are, as I’m sure we all know, not strictly dimensionally accurate.  In order to make his life easier, with a 2:1 dimetric projection and a movement system based on whole pixels and powers of 2, Chris Sawyer decided vehicles displayed in diagonal directions should have sides 0.5x the length of vehicles displayed in the horizontal direction, instead of the mathematically correct ≈0.72x.

perspective

This is unfortunate for us latter-day artists who want to draw something “realistic” (or, worse yet, use 3d rendering), but there is nothing we can do about it (at least for trains and road vehicles, which need to be chainable) *cough cough*, and it is at least somewhat understandable from a technical point of view.  However, there’s another TTD vehicle graphic anomaly which is avoidable, nonsensical, and ugly, and which we persist in recreating:

Chart of bad diagonal heights

On the left are TTD original sprites and OpenGFX; on the right are sprites from various 3rd party train sets – I hope no artists feel I’m singling them out, because my point is to illustrate that we all do it.  And what we all do is make our diagonal sprites smaller in height, by one or two pixels, than our horizontal sprites.

There is no geometric reason for this.  It’s a pain in the backside to draw, because you have to convert 8px of vertical information into 7px.  It makes the diagonal sprites look even smaller compared the horizontals, in addition to the excessive shortening in length.  The only reason we do it is because we’ve always done it.

Therefore, among the many TTD graphic conventions I’m abandoning for 10CC and other future work, I am no longer reducing the height of my diagonal vehicle sprites.  The resultant “full height” diagonals are, in my opinion, much nicer to look at.  They’re also a lot easier and more pleasant to draw. :)

F-Units with lightweight carriages