Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (799)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Airships: Conquer the Skies  (Read 101665 times)
0 Members and 1 Guest are viewing this topic.
Offline Zarkonnen
« Reply #30 - Posted 2014-09-09 14:12:14 »

I'm continuing work on boarding combat, which will be the major addition in the next release of Airships, according to the development plan.

Last time, I got to the point where air marines could teleport over to an enemy ship and fight the crew there. This disrupts the enemy ship's operations, with marines killing crew who would otherwise be busy firing at your ships. But marines should also be able to take over ships with enough effort. This was the next thing to implement.

Because airships are complex entities with a lot of internal structure, a takeover can be ambiguous: Imagine you're an air sailor operating a propeller somewhere in the ship. You can hear that there is fighting elsewhere, and after a while you get an order barked down the speaking tube by an unfamiliar voice: you are to turn the ship around. Do you obey? Seconds later, there is another, more familiar voice rescinding this order, the sound of gunfire in the background...

So crew will be at least somewhat aware of what's going on on their ship, and are unlikely to cooperate fully with any occupiers. Still, for practical purposes, there has to be a point at which the ship moves from one side to the other. So a ship will switch sides if its bridge(s) contain no (living) crew and at least one (living) invading marine. The original crew of a captured ship will only perform duties from self-preservation: they will operate suspendium chambers to keep the ship from crashing, and they will put out fires. Everything else will have to be handled by the invaders.



To effect this takeover, air marines will converge on the ship bridge(s) once they've run out of important strategic points to disable. The combat code continually checks the requirements for a side switch and executes it when possible. You can also recapture your own ship, and the crew will stop being in "occupied" mode and resume their normal range of activities.

Once I got that all working, it was time to tackle the other half of boarding: the process of actually moving from one ship to another, replacing the stand-in "teleporter" I'd been using so far.

Boarding an enemy ship happens in the following phases:

  • Upon receiving the command to board, marines inside a ship move to a place where they can exit - a hatch or a hull breach.
  • Arriving there, they leave the ship, which means they are now treated as a separate entity by the game.
  • Next, they move along the outside of the ship to a place where they can safely cross over - jump - to the target ship.
  • A mad leap across the open air follows!
  • Having arrived on the other ship, they move along the outside of the target ship to the nearest entrance - again a hatch or hull breach.
  • Finally, they enter the target ship as boarders, and the boarding combat code I've already written kicks in.



To get there, crewmen (marines) need to be able to exist outside an airship. As previously mentioned, crew normally exist on their ship's coordinate grid, which of course stops working when they leave.

To start, I introduced a new list of outside crew members. I decided to treat them differently from normal physics objects like ships and floating rocks, as they are able to move along the side of them, overlapping. Their simplified physics mean that they can move and fall down, but if they collide with a ship or rock, they hold on instead of bouncing off.

The exception to this is the ground, which they should not overlap with. Since there is only ever one ground object, I was able to solve this fairly simply: when an overlap with the ground is detected, the game moves the crew member back along his trajectory to neatly leave him outside of the ground. This would be harder to do if crew needed to be moved back out of multiple things. For example, if crew were also shifted out of airships, an airship squashing a crew member against the ground would pose a problem: he could not be moved out of the way of both of the ship and the ground at the same time.



Once I got this basic physics to work, I added a visual layer for displaying the external crew members and got started on the functionality for entering and exiting ships. To start, I ignored the planned restrictions that crew could only move through hatches or hull breaches and just... sort of let them phase through walls. One step up from teleportation, anyway. The actual code for making the switch was mostly a lot of bookkeeping - unregistering the crew member in one place and adding them in the other, translating in-ship coordinates to global ones.

The first time I tried out the code by giving the boarding order it turned out that I had forgotten one small thing: only marines should exit the ship for boarding purposes. Instead I got everyone shifted to the outside - in the wrong place too - with rather unfortunate consequences for the ship that suddenly found itself without a crew to operate it!



Having fixed this up, I had part of the boarding cycle working, but there was still a lot to do, especially the actual jumping across, which will be the focus of the next article.

Also, in exciting non-boarding news, Airships got nominated for the Swiss Game Award 2014 of the Swiss Game Developers' Association. Pretty pleased with that.
Offline Zarkonnen
« Reply #31 - Posted 2014-10-21 16:06:44 »

I am pleased to announce that Airships early access version 5 is out. This release introduces boarding combat, ramming prows, and new ship modules such as sails - and music!

Boarding and ramming makes airship combat yet more physical: A well-placed ramming manoeuvre can instantly take out whole enemy ships.



Air marines can leap across the gap between two ships and invade through hatches and hull breaches. Once inside the enemy ship, they will attack weapons and command systems, seeking to disrupt and even capture. If the marines manage to take control of the bridge, control of the ship switches to the invaders. The remaining enemy sailors will do minimum duties keeping the ship flying, but the marines are going to have to do the rest of the fighting themselves, so send over lots if you want to make good use of your prize.



Apart from air marines, there are also air grenadiers, elite troops with grappling hooks that make it a lot easier to get from ship to ship, and guards for buildings. Because troops need a way to get in and out, ship and building designs now require the addition of hatches or cargo doors, so if you have existing designs, they will require some updating.



Airships' music is created by Curtis Schweitzer, who previously did the soundtrack for Starbound.

The next major version of the game is going to concentrate on improving graphics and polishing the user interface, all according to the development plan.
Offline atombrot
« Reply #32 - Posted 2014-10-21 18:27:34 »

Just checked my youtube subscriptions and look what I've found Cheesy

<a href="http://www.youtube.com/v/vqegru9otQg?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/vqegru9otQg?version=3&amp;hl=en_US&amp;start=</a>
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Zarkonnen
« Reply #33 - Posted 2014-10-27 11:20:33 »

My airship combat game is getting pretty close to being greenlit - three quarters of the way through - but I really really need a last big push to get it there. Players really love it, and the greenlight page is full of enthusiasm. I've been trying to do this without resorting to vote-stuffing deals like Groupees that tend to get used to propel games over the finish line - so I'd like to ask you to give the game your greenlight vote.
Offline Zarkonnen
« Reply #34 - Posted 2014-12-01 12:28:42 »



The turtledove, like many other creatures in Suspendium-rich regions, has learned the trick of bio-accumulating Suspendium to become flighted. In the turtledove’s case, the accumulation is confined to the shell, which as a rigid mass of bone acts as an excellent and safe matrix for the Suspendium. As a result, these animals are able to grow to large sizes while remaining afloat, using their elongated flippers to propel themselves.

I've been pretty busy over the last two week with some non-Airships work, but I did get around to doing the above concept sketch. Blame getting "Twelve Days of Christmas" stuck in my head.

Meanwhile, Stuff+ has been doing an excellent series on ship construction and strategic conquest, which is well worth watching if you want to see some serious gameplay.

Development is going to gear up again now, so what's next? There's some audio and video bugs I'm currently tracking down, which means there may be a bugfix version 5.3.

Beyond that, the main focus of version 6 is going to be prettiness, which means both the aforementioned new lighting system (the second devblog for that is coming soon), and a new user interface as well:



(Concept, subject to change.)

Finally, you should totally vote for Airships in the 2014 IndieDB awards.
Offline Chequered

Senior Newbie


Medals: 1
Exp: 2 years


I could use a cup of Java.


« Reply #35 - Posted 2014-12-03 11:42:29 »

This looks great,
I really like the UI. May I ask. What libraries etc did you use to make this?
Offline Zarkonnen
« Reply #36 - Posted 2014-12-10 15:35:36 »

This looks great,
I really like the UI. May I ask. What libraries etc did you use to make this?

So that UI is just a mockup made in GIMP, put together at the pixel art level. The UI in the game doesn't really have a library, it just has convenience functions for things like "draw a button here with this callback". I may formalize that a bit when I update the UI though.
Offline Zarkonnen
« Reply #37 - Posted 2014-12-10 15:35:56 »

When you start upgrading the visuals of your game, some parts start sticking out like a sore thumb. In this case, I'm really unhappy with the way damaged armour looks, so I'm going to outline a way to make it look better. This is a bit involved, but there is a really cool picture at the end...

Currently, each type of armour has a series of five appearances, from "unblemished" to "destroyed". When undamaged, the armour tiles nicely and looks quite nice, especially with the lighting effects now applied. The problem comes when there's heavy damage: since there's only one picture for a destroyed armour tile, this gets tiled and looks very bad: a regular series of holes with the exact same shape.



The obvious way to fix this is to add more pictures for damaged armour tiles, but this doesn't fix one problem: a damaged tile may be right next to an unharmed one, which means that the hole can't quite extend to the edge without a sudden and obvious transition from one tile to the next. So I'd still up with a grid of holes, just of different shapes.



I could add pictures for all the configurations of tile adjacency, but this produces a combinatorial explosion: including diagonal adjacency, each tile has eight neighbours that could be damaged or fine, which means that I'd need to draw two to the power of eight different tiles. I am not drawing 256 armour tiles for each type of armour if I can help it!

So instead I've hit upon a different idea to make the armour drawing look really good. Unsurprisingly, this involves a clever shader. (I get this feeling that more and more of the game is moving to shaders, until eventually the entire thing will just run on your graphics card.)

Note that I haven't actually implemented what I'm about to describe, so it's perfectly possible that I'll have to abandon it because it's too hard, or too slow, or just looks bad. Normally, when I write dev blogs I do retrospectives where I can describe what I ended up doing, leaving out all the false starts and dead ends, which makes me look more clever than I really am.

On to the idea: per-airship damage maps. Each airship gets an associated grayscale image of where its armour has been damaged: white means undamaged, black means the armour's been punched through. Impacting shots draw splashes of damage onto this image, bigger and darker for stronger projectiles.


This damage map is then used in the shader to put together the look of each tile. In places where the map is nearly white, it draws the normal look of the armour. In places where it's grey, it draws an alternate, damaged look, which comes from a second armour picture that looks all roughed up. Finally, in places where the damage map is black, it doesn't draw the armour at all, leaving a hole.

 

 

The result is that each airship gets its unique patterning of armour damage and holes, going across tile boundaries with no visible transition.



What's more, the shader can also calculate the lighting for that tile using a few bits of extra information. First, it needs a height map for the undamaged armour. This is different from the bump map described in the lighting post. A height map shows where the armour sticks out. A bump map is the derivative of a height map: it shows where the height map changes.

The shader combines the height map of the undamaged armour with the damage map for the tile, which results in a new height map that shows what remains of the armour after the damage has been done. Then it derives the bump map and uses it for the lighting calculations.

 

 

The result should be pretty awesome: armour that can be blasted off pixel-by-pixel and dynamically lit at the same time, so flashes of light will play across the jagged edge of the holes, making splinters of still-unblemished metal light up.



Can I pull it off? As you can tell, I've got the logic of the shader pretty much worked out. The bigger question is whether it's feasible to attach a damage map to each ship, update it, and feed it to the shader in the correct way with all the offsets set up properly.For now I will leave you with this amazing piece of Airships fan art created by Jenny Thorne:



(Oh, and please vote for Airships on IndieDB! Only a few hours left.)
Offline Zarkonnen
« Reply #38 - Posted 2014-12-30 08:23:47 »

At the start of 2014, I'd been working on Airships for a few months, and the major components were beginning to take shape: ship design, combat, heraldry, even a simple strategic map and multiplayer. I'd been blogging about the game on my site and IndieDB right from the start, and the very positive response was a major source of motivation. Still, the game lacked much of a user interface, and the computer's ships just hung in the sky and fired, with no tactical AI to drive them.



I wanted to get an early version of the game into people's hands quickly to start getting more feedback, so on March 23, I released the first early access version. To sell the game, I chose itch.io, a relatively new game store which is wonderfully straightforward for both players and developers. There's no application process, and no super-complex backend - you just upload the game, write a description, set the price, and you're ready.

As these things go, having activated the store, published the blog posts, and sent out the press releases, I then spent the rest of the afternoon hitting refresh in various places, anxious to see if people noticed or cared. And they did - the game sold maybe 30 copies in the first day, which isn't a lot, but a clear indicator of interest. Compared to my previous, much smaller game, Patent Blaster, which only ever sold about seven copies, things were definitely looking good.

A second and third version followed pretty quickly, adding smaller modules, an Internet game server, and a lot of balancing and bug fixes. By that time, I realized that Airships really needed a soundtrack. I advertised for a composer on Reddit and was fairly flooded with responses. I ended up making a spreadsheet of nearly forty candidates, whittled those down to seven, and finally chose Curtis Schweitzer, who impressed me with his orchestral scores, high quality of work, and previous experience making the soundtrack for Starbound. Frankly, I was a bit amazed that he was willing to join up with some tiny unfinished game, but clearly he could see its potential.

By the end of July, version 4 was ready, adding floating rocks, espionage, flamethrowers and Suspendium cannon. Most of the major changes were under the hood, as I'd reorganized the main game view into a more flexible componentized system that's since held up very nicely. Shortly afterwards, I took the plunge and added the game to Steam Greenlight. Sure, itch.io is great, but Steam still utterly dominates the PC games market, so Airships has to get onto the Steam store sooner or later.

This did mean that promoting the game got a bit more complicated: in general, you want to suggest one concrete action for people to take. Previously, this was obviously "buy the game", but now "upvote the game on Greenlight" competed with this. In practice, I've found the conversion rate to be about the same, which is kind of weird. People are as likely to fork over $5 for the game as they are to click "upvote" on Greenlight!

Early access 5 added major new features in the form of ramming and boarding, opening up new combat strategies. Subsequent updates finally brought a degree of balance to the strategic mode as well.



Shortly after the release of EA5, Youtuber Stuff+ started his very popular Construct+ series on Airships, introducing many new players to the game. I think that by now, about half of Airships players found it through Stuff+.

And indeed, by the end of November, the tally of games sold reached and exceeded 1000 copies, a pretty major milestone. In and of itself, a thousand copies don't make the game commercially successful: It's had about 7 man-months invested in it by now. But it's a very heartening sign that even half-done, unpolished, and with limited media attention, the game already sells.

So what's the plan for 2015? Obviously, I want to finish the game in that year. I'm aiming for early Q3, making it a solid two years of development time.

The next step, what I'm working on now, is to make the game a lot prettier: the new dynamic lighting system is now in place and looking really good, and still to come is a prettier and more consistent user interface. Early access v6 is where the game starts growing up a bit, hopefully moving beyond niche appeal to something that looks cool and plays well.



With version 6, I also hope to get the game greenlit. There's a mere 300 votes still needed to reach the top 100. Valve no longer do whole batches of greenlighting but rather pick individual games, usually from the top 100. I'd like to think that Airships is a pretty good contender. It's distinctive and already has a track record of success.

Beyond v6, it's a question of spending some time adding cool features. This will be a balance act between putting in all the things I can think of, and having enough time to really debug and polish it within my timeframe. If it turns out that I have to cut major features I wanted to put in, and the game sells reasonably well, there's always the option of creating an update or expansion to add in the extra stuff.

Finally, by early summer 2015, I want to switch full-time to polishing and debugging, ensuring the game's quality and compatibility. The words "early access" have lately acquired a bad reputation for games that are abandoned partway, and this is not what I want for Airships. I buy and play games too, after all, and it's so heartbreaking to end up with something that would have been really cool if only it had been fixed, polished and balanced. And after all, I want you to buy my next game too, and the one after that!

So what are the cool additional features I still want to add? A lot of this is in the plan file, but that's actually somewhat out of date, so here's my current list, in no particular order. Not everything may make it into the final game, for reasons of time, balance, or implementation difficulty.

  • Land-ships that walk on legs or drive on tracks. Cheaper but less flexible than airships.
  • Infantry: Cheap but squishable.
  • Bodies of water in combat mode.
  • Dragons, Sky-Krakens and other monsters.
  • Ship captains with special abilities.
  • Magical spells for combat.
  • Turreted weapons and droppable bombs.
  • Diesel engines as a more powerful alternative to coal.
  • A more fleshed-out single-player campaign.
  • A multiplayer ladder system.



I'm certainly having a lot of fun making this game, and I'm very happy that people are playing and enjoying it. 2015 should be a good one.
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 167
Projects: 5
Exp: 6 years



« Reply #39 - Posted 2014-12-30 08:34:36 »

Nice to see you've continued working on this project. The art style is great, and I think the gameplay has a lot of potential. Gave you an upvote on greenlight Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TritonDreyja
« Reply #40 - Posted 2014-12-31 20:05:18 »

Best of luck with GreenLight!

I will be getting my hands on this as soon as i can.
Offline Zarkonnen
« Reply #41 - Posted 2015-01-04 12:37:30 »

Thank you both for your greenlight votes! The game's now entered the top 100 and is currently listed at #92, so we'll see...

Dev blog update:



One of the nifty features of Airships is that you can create your own coat of arms. You can do this for your single-player empires, selecting a symbol (a charge) to give you a particular bonus. And you can design and register a coat of arms for your unique use in multiplayer. The system hasn't really changed since the initial release with the exception of a few added charges, but with dev 6 - the update of prettiness - I want to improve on what's there.

Currently, a coat of arms is defined by selecting a layout, a charge, and two or three colours. This leaves some coats of arms looking rather bare, though. In a quartered coat, only the top left quarter contains anything, whereas it would be much nicer and more realistic if all quarters could contain charges.



In the new system, each layout has between one and four slots that can be filled with different charges. I'm also adding a whole bunch of minor charges such as stars and wings that don't have a bonus effect in the single-player game and can be added freely. You will be able to combine multiple major charges (say a scales and a lion) on your arms, too. In single-player, the most prominent major charge (the one closest to the top left) will be the one that provides the bonus.



This opens up a whole lot of options for much nicer-looking arms:

     

     

Your already-registered arms will stay unaffected by this change, of course, though you might want to look into upgrading them.
Offline Zarkonnen
« Reply #42 - Posted 2015-02-06 13:43:18 »

I've been hard at work on Airships dev 6, and have now fixed upon a release date for it, and for Airships on Steam: February 25. So unless anything goes majorly wrong in the next two weeks, that's when you get the fancy new version of the game.

There's still a fair list of things I want to improve before the release, mostly on the visual side. Right now, I'm working on making the strategic map screen nicer. The idea with that screen has always been to make it look like a desk you're looking at, plotting your empire's path. To make it look less bare, there's going to be some pieces of paper at angles half-beneath the map, and probably some coffee stains.

Of course, the pieces of paper are an irresistible opportunity to do some worldbuilding:



Can you decipher the scrawled handwriting to discover the terrible secret of dragon-rearing?



An important part of any imperial presence is maintaining positive relations with the natives.



To be fair, airsailors will eat pretty much anything that's not even more hardtack.
Offline GreenLantern101
« Reply #43 - Posted 2015-02-08 03:49:55 »

That new coat of arms mechanism adds so much more freedom to strategizing and decor! Well done indeed! But quick question about the dragons: will they be neutral and in battles randomly, or are they more like bossfights?
Offline bilznatch

JGO Coder


Medals: 11
Projects: 2
Exp: 4 years


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #44 - Posted 2015-02-09 01:43:33 »

I'm glad this project still seems to be going strong. Looks very promising still.
Offline Zarkonnen
« Reply #45 - Posted 2015-02-25 16:42:22 »

It's out! Airships version six, bringing new lighting, new heraldry, new guns, and weather!

It's out on Steam too, which means this finely crafted link now brings you to the Steam store page.

So what's next?

First and foremost, with new players coming in, there's sure to be new bugs discovered. So my first priority is likely going to be putting out some bugfix patches. After that, I want to spend some time on game performance. The new fancy graphics take their toll on the graphics card, and while you can switch them off, it would be much nicer if everyone could enjoy them.

Improving performance means restructuring how airships are drawn from the ground up, which is why I didn't want to risk it in the week going up to version 6. The core problem is that graphics card really hate it when you do lots of small draw calls, and currently that's exactly what's happening. You might think that a 2D game shouldn't tax the GPU that much, but when you have hundreds of airsailors on-screen and make a separate draw call for each of their limbs - it's quite bad.

The solution is to organize drawing into layers. Instead of drawing one ship, one crewmember, after the other, the game will draw all the back walls, then all the modules, then all the gun barrel, then all the crew limbs, and so on. Each of these layers can be a single draw call, collapsing hundreds of them into one.

OK, so that's the immediate plan, but what about new features? What's coming between now and the final release? Well, the development plan I laid out months ago is still more or less correct, though which feature comes in which version is subject to change. There are five major additions I have in mind:

Better troops



The boarding stuff is cool and works really well, but it took such a long time that I stopped working on it as soon as I had something to show. Which means that there's some... odd missing bits: Crew stranded on the ground just stand there and are unable to move anywhere. Fixing that would pave the way for having ground troops fighting amongst one another and attacking buildings and ships. Most importantly, they can then be trod on by...

Landships



Okay, yes, the name of the game is "Airships". But landships, war stompers, steam mechs: totally cool, right? And they're basically the same as a ship or a building, they just have a different method of propulsion. The slightly hard bit here is getting their limbs and tracks to interact properly with the ground.

A more detailed strategic game



As it stands, the strategic mode is really very simple. It could be a lot more interesting. I'm still working on figuring how best to do this. There's a lot I could add, but it's important to pick additions that make the gameplay deeper rather than just more complicated. More detail on this in a later post.

Diesel!


CC

I used to insist that Airships was totally a "Steam/Dieselpunk" game. This will finally become sort of true when diesel engines are introduced. These will be much more powerful and lightweight, and won't require manual supply of fuel, but they'll also be expensive and quite prone to catching fire in a bad way. The reference time period for Airships is about 1860 to 1940, so we'll see a bunch of slightly more modern things cropping up.

Monsters!



Last but not least, the game needs monsters. There's actually dragons in the game now, but only ever seen in the distance, flying past at high speed. Dragons, Turtledoves, Air Krakens, Sentient Floatweed, Giant Spiders, Mechanical Ducks! Some of them you must fight, others might be useful to your own side.

Stay tuned.
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #46 - Posted 2015-02-25 17:36:33 »

Wow! OP is a great artist, and this game is amazing! Why isn't he getting slapped with medals?

Offline TritonDreyja
« Reply #47 - Posted 2015-02-28 04:14:55 »

Seems like theres a load of ideas that can be thrown into a game of this sort. Great job on the whole thing!
Offline Zarkonnen
« Reply #48 - Posted 2015-03-18 11:03:18 »

Having covered the kind of stompy war machines I want to make in the last blog post, let's get into how to implement them.



Mostly, landships and airships can be treated the same. Buildings are technically a kind of immobile airship, so landships aren't much of a stretch. The difference is that a landship is held up and propelled by tracks or legs, rather than through Suspendium and propellers.

The question is how the ship navigates changing terrain. What happens when there's an upwards step? A real vehicle tilts when it drives up or down a slope, but the game engine can't support rotation of ships without massive complication.



On a slope, I want to keep the body of the ship level, but raise it up gradually so it can adjust to the new terrain height. To do this, I add a suspension, a set of springs that raises the landship off the ground. The ship won't bump against minor changes in terrain, and its vertical position gets smoothly adjusted. The springs aren't real physical objects, so they won't bump against the side of a hill. The tracks or legs the ship uses will get drawn on top.



This is what happens when the ship encounters a step upwards: As the springs move across the ground, the first one encounters the new height. It becomes more compressed and the additional force starts shifting the body of the landship upwards. As more springs move over the new area, the ship keeps on rising. Of course, if the hill is too steep, or the ship too heavy for the springs to push it up much, it will get stuck. But that's fine, that's realistic.



It also works when going down, though again the ship can get stuck if it doesn't have enough clearance.

So let's start implementing these springs, which will be attached to new tracks/legs modules. I start by creating a Spring class and putting in code so it can find the closest bit of ground. That gives me the length of the spring, and from that the upwards force the spring exerts, which can be easily plugged into the physics engine. Create a test module and put it on a building - and it sproings up!

Click to Play


Great! The next step is to actually introduce landships as a type of construction, beyond ships and buildings. Turns out that lots of things key off "is it a ship or a building", which is too specific. What matters is "can it move" and "does it fly", which nicely separates airships, landships and buildings in how they need to be treated.

Next time: Creating some basic landship modules that are able to both hold up and propel the ships.
Offline atombrot
« Reply #49 - Posted 2015-04-02 07:56:04 »

Hey, you are getting famous Cheesy

I've found very small article about your game in todays 20min (a local free 'news paper'):
 http://m.imgur.com/TjxNBZG.png

Sorry, but I could not make any better picture with my phone.
Offline Zarkonnen
« Reply #50 - Posted 2015-04-03 16:24:41 »

Hey, you are getting famous Cheesy

I've found very small article about your game in todays 20min (a local free 'news paper'):
 http://m.imgur.com/TjxNBZG.png

Sorry, but I could not make any better picture with my phone.

Cheesy Good stuff! You live in Zurich too, then? I wonder if we know each other...
Offline Zarkonnen
« Reply #51 - Posted 2015-04-03 16:25:08 »

I'm still working on Airships 6.3, and it's shaping up to be a *very pretty* update. Most recently, I've made particles and explosions look much better and am now replacing the simple low-res backgrounds with more detailed ones. Also, Airships has an official wiki now!

Up until now, particles in Airships have been very simple: they were all coloured squares of various sizes, which works well for small things like sparks, but is a bit bland for smoke and explosions. In particular, I really wanted the smoke to be lit up dramatically by the flashes and fire of battle.

Getting particles hooked up to the lighting engine wasn't that hard - all the shaders were already in place - but it took me a while to find a good look for the smoke. I first tried using a smooth look for the particles, and while it looked quite nice, it didn't fit the look of the rest of the game.



Eventually, I ended up with square-ish particles with square-ish lighting maps, which I do think is an improvement:



Then I came across an article about how explosions are handled in Vlambeer's Nuclear Throne, including a very nice-looking explosion animation:



Nuclear Throne explosion by Paul Veer. Reproduced with permission.

Looking at it in detail, you can see that after the initial flash, the explosion consists of a number of particles that don't move all that much but steadily shrink and darken. I produced a similar effect in Airships by spawning a central light-emitting flash particle and a number of smoke particles surrounding it:

Click to Play


And the same effect but on a smaller scale for cannon blasts:

Click to Play


Having settled on a style for this kind of thing, I also re-added clouds, again using the lighting system for them:



As I wrote previously, the point of 6.3 is to really get the game looking pretty in a bid for mainstream success. This left one major sore point: the low-res and rather uninspired forest and mountain backgrounds. At this point, they were pretty much the only thing not using the new colour palette or lighting system, so obviously they had to go. This is what they're getting replaced with:



A much larger set of modular backgrounds: hills, forests, towns, towers, windmills, and so on. This is a lot of pixeling, and it's kept me pretty busy over the last few days, as each image needs to be first drawn and then given a bump map for the lighting to work. But the end result should be really quite good.



That's all for now, except for this wiki thing: There's now an official Airships wiki hosted on Gamepedia. Right now, content is still pretty sparse, but I've put in a bunch of entries. Head over there and contribute, and one day it should be an excellent resource for the game.

And join me next time, when I'll be writing about the new modules getting added in 6.3.
Offline Zarkonnen
« Reply #52 - Posted 2015-04-30 09:21:09 »

Airships 6.3 adds lots of new decals to apply to your ships. The decal system's been around for a long time, but after the initial set of options for putting your coat of arms onto your ships, it got neglected for a while. As part of the push for increased prettyness, I added a whole bunch more, mostly inspired by real-life aerial decorations.



Eyes and teeth: These were in fashion for decorating fighter planes in WW2 and ancient Greek triremes.



Gold leaf, because sometimes you want your airships to look fancy. None of the decals cost any money, which is a bit weird in the case of gold leaf, but roll with it.



Roundels, which turn out to be a fascinating side-branch of heraldry / vexillology (the study of flags). Much as with flags, there are a number of classic styles of roundels, which many countries follow, some variant styles that are popular, and some truly weird stuff where the designers clearly didn't get the memo of "maybe make your war plane unambiguously identifiable".

In flags, the most classic layout is probably the tricolor, a field evenly divided into three, horizontally or vertically. It's a design associated with European nations. The roundel equivalent is a roundel made of three concentric circles of a solid color - pretty much the tricolor in polar coordinates!

   

European roundels: France, UK, Germany. All insignia images are public domain and sourced from Wikipedia.

Not that there's a perfect match: the UK uses a classic tricolor roundel design but doesn't have a tricolor flag, whereas Germany uses a kind of worrying throwback design instead of their tricolor.

   

Variations: Bangladesh, Equatorial Guinea, Switzerland

Fairly popular variations include different numbers of concentric circles. Bangladesh has two, Equatorial Guinea has four. Another popular option is putting a symbol into the center of the roundel. Switzerland's got it pretty easy there.

   

Bad ideas: Belize, Syria, Yemen

And then there's Belize, who just use their overcomplicated flag, and Syria, who picked a design near-indistinguishable from Yemen's. Good job!

In Airships, I've stuck to two basic designs: a bi/tricolor roundel with colours extracted from your coat of arms, and one containing your main heraldic charge.

So, what's next? I spent much of last week at A MAZE Berlin, showing around my game, and returned with my head full of ideas for improving the way it feels. Thing is, I may be a decent programmer and creator of game mechanics, but I have to observe people playing the game to notice all the rough edges in what I make. And other developers are way better at figuring out what makes a game feel fun. So now I have a long list of small things I can do to make the game subtly feel better, and it's a list I urgently want to get to.

This means that rather than going straight to version 7 with its landships, there's going to be a v6.4 and 6.5 incorporating these improvements. I know you're all looking forward to your war stompers and spider mechs, but smoother UI and more satisfying screams and explosions are going to be a pretty nice thing to tide you over until they arrive.
Offline Zarkonnen
« Reply #53 - Posted 2015-05-10 11:06:20 »



No, I’m not adding a paintball mode to the game.

One of the major bits of feedback I got from showing my game at AMAZE Berlin last month was that there’s a lot of potential for more spectacle in the game: more satisfying crashes and explosions and things whizzing past. We like large amounts of kinetic energy, don’t we?

So Airships 6.4 concentrates on making that happen. Airships now crumble majestically instead of evaporating in a single flash. Bullets and cannon balls leave trails in the air, which both looks cool and helps communicate what’s going on.



With these updates, it became clear that there’s one major missing piece to the spectacles: module destruction looks really boring. The module just winks out of existence and leaves behind a small number of boring brown particles. This needs fixing. Modules should break apart into parts and shrapnel, spinning and arcing away. To make this work properly, I’ve created a new layer in the sprite sheet that splits each module sprite into the regions it should break up into.

This information is then going to be fed to a program that combines the original sprite sheet and this layer into a new sheet of shrapnel and a bunch of data that ties the shrapnel to each module appearance. Then, when a module is destroyed, the module still winks out of existence, but at the same time, the shrapnel bits are placed in their starting positions and given a velocity and spin, which should give the appearance of the module breaking up dramatically...

Click to Play


In other news, if you’re in Switzerland or Germany: I’ll be exhibiting Airships at Fantasy Basel on May 14 - 16. More details. (Airships isn’t listed there yet, but it will be present!)
Offline DavidBVal
« Reply #54 - Posted 2015-05-10 17:29:14 »

Your game looks awesome, I love the art style.

Offline Zarkonnen
« Reply #55 - Posted 2015-05-24 17:56:22 »

I used to devour "Making Magic", the game design column written by Mark Rosewater, then lead designer of Magic: The Gathering. I never got into playing Magic itself, but I found the inside view of game design and balancing interesting nevertheless. Probably the most famous column is Timmy, Johnny and Spike, where he introduces three archetypal player profiles that the game caters to.

Airships isn't much like M:tG in its details, but there are certain similarities: it's a 1v1 game that is played in two distinct stages of preparation and combat. In Magic, the preparation is the deck building, whereas in Airships it's the ship design. Victory is secured by some combination of good preparation and being able to use your assets effectively. With that in mind, I think that Timmy, Johnny and Spike are applicable to my game. I'm going to first explain what each of these player types is about, and then how I'm working to accommodate the interests of each of them.

Player profiles form a loose categorization system for different motivations and styles of play. Not everyone falls neatly into one category, and beyond the Timmy/Johnny/Spike system, there's a whole bunch of other categorizations that draw the lines in different places or are applicable to different kinds of game. TVTropes has a decent overview.

Timmy


This player likes things big, and dramatic. Sure, winning is nice, but spectacular wins are so much more satisfying than subtle ones. This is the guy who wants to take you out with the really dramatic finishing move, or crush you with the giant battleship.

Johnny


To Johnny, playing the game is a form of self-expression. What matters is cleverness and innovation. Sure, winning is nice, but winning in a clever way is so much more satisfying than doing it in an obvious fashion. He will try out the obtuse combos and weird tactics that take you by surprise.

Spike


Spike wants to win. He doesn't care how he does it. Tactics don't have to be clever, or exciting, they just have to work. He's the one who will happily kill you by using a perfectly executed punch 57 times in a row.

(Note of course that these archetypes apply to all genders - their names are male, and so I'm using "he" throughout for grammar reasons.)

What does Airships currently do to cater to each of those archetypes, and what future improvements can I make?

Timmy
Big airships, big weapons, flamethrowers. Ramming! The most recent update, 6.4, was very much one for Timmy, adding more visual spectacle and visceral destruction. There's still a bunch of things I want to try out for increased spectacle:

  • Temporarily panning the camera for particularly large explosions.
  • Adding crew portraits to the shouts so you can see their faces, lit up by fire, screaming dramatically.
  • Better and more varied audio for all things smashy and explodey.

Johnny
The ship editor is Johnny's domain, of course. What makes a game like Airships work long-term is a wide variety of viable strategies: high-altitude snipers, rammers, boarders, swarms of grenade ships, etc. What matters for Johnny is adding new options that expand the space of interesting things to do.

This is trickier than it sounds, because each added option needs to be *situationally* dominant rather than *globally* dominant or inferior. If I add a new gun that's better in all situations than two existing weapons, I've actually shrunk the space of interesting designs. And if I add an option that's just not very good, well, it just clutters up the game's design.

So what's definitely planned for Johnny, apart from a continual search for interesting new weapon concepts?

  • Landships: Not as flexible as airships, but cheaper and a bit more durable.
  • Most likely, small auxillary craft. This is a concept that's been worked out in some detail by people on the forum, and I think it's a good one.
  • Diesel engines: More powerful, easier to operate, but more flammable and expensive.

Spike
Winning is what matters to Spike, and especially winning against other people. Airships has had online multiplayer for a long time now, but we haven't reached a critical mass of players where you can play a match when you want to. The multiplayer calendar sees the occasional flicker of activity, but it's kind of cumbersome. This may get better over time as more people discover the game, and old players revisit it at the time of major releases, but it's clear that Spike needs some love, in the form of:

  • Tournaments! Players are self-organizing one at the moment, but it's something I want to build support into the game for.
  • Relatedly, a ranking system where players can compete for the top spot by winning multiplayer fights.
  • Practical improvements to the multiplayer calendar like being told further in advance that you have an upcoming match, and the ability to opt in to being told that there's an unmatched slot available in the near future.

All of these improvements are going to come in over time in the next three versions of the game or so. As you can see, I have a vast quantity of things I want to do with the game to make it more fun for players, as well as finishing up the list of large game features. So stay tuned, let me know your feedback and ideas, and fight me in multiplayer some time!
Offline Zarkonnen
« Reply #56 - Posted 2015-06-04 10:49:48 »

I’ve been trying out a new thing: streaming the development of Airships on twitch.tv[/url]. So far, I’m really enjoying it for a whole bunch of reasons: It’s nice to interact with people. It’s helpful to think out loud. And, uh, I can’t procrastinate while I’m streaming. I can’t exactly check my Twitter account every few minutes in front of everyone watching.

I’m still very much learning the ropes on how to stream stuff - figuring out how to set up things to that I can interact with the twitch chat while working, getting better at pressing the right buttons in the streaming software, and so on. I also haven’t settled on a standard time to stream yet. Probably, the ideal point in time would be evening in the US, but that’s the middle of the night for me - so it’s going to be either US daytime or late night.

Today, I’m going to do a dev stream at 18:00 CET, which is 12:00 EST and 09:00 PST. So if you’re in Europe and want to see some late afternoon streaming, or in the US and see some morning gamedev, do tune in. If you’re lucky, one of the cats will be present as a guest star.

Probably, I will eventually settle on a regular time slot, but it’s still early days. Also, twitch makes it easy to upload the stream recordings to YouTube, which is what I’ve been doing. So even if you can’t see the live broadcast, you can watch the streams later.

Anyway, what’s been going on on these streams dev-wise? Lots of work on legs and leg movement for landships.

We’ve got four-legged ones:



Two-legged ones:



And the gait is starting to look more realistic:

Click to Play


Once all the leg stuff is fully operational, I’ll move on to tracks - which will likely be much easier - and then, better support for troops. So tune in if you like, or follow development on YouTube or through these dev blogs, which will of course continue.
Offline Opiop
« Reply #57 - Posted 2015-06-04 13:08:21 »

I haven't noticed this before, it looks awesome though! The art style is great. I'll definitely try to catch one of your streams sometime!
Offline Zarkonnen
« Reply #58 - Posted 2015-06-22 11:58:31 »



The challenge with landships is that they require a much more detailed interaction between physical objects. Until now, the only interactions that mattered were collisions as well as buildings and grounded ships sitting motionless on the ground. Walking, on the other hand, is a pretty complex interplay of movements and forces, and so it's taken me a few weeks to adjust things properly. A partial list of considerations:

  • Landships need to move their legs, placing their feet in suitable spots that are both well-placed to hold up the ship where it's going.
  • They should only be able to move if their feet are actually touching the ground.
  • They shouldn't be able to balance on a set of feet that's way off-center.
  • They should correctly estimate whether they can safely traverse terrain, and emergency-stop only when needed.
  • Feet should crush foliage and bushes, and in cases of heavy impact, even other ships, buildings and soil.

As I previously mentioned, the fact that landships can't tilt means that they have quite a bit of difficulty navigating slopes. I've generally compensated for this by making their legs and tracks pretty huge, but that in turn has led to some weird behaviour like giant war stompers gracefully tip-toeing across the treetops. Finally, though, it's coming together.

Beyond leg physics, I've also been improving the particle system, allowing particles to stick to ships and other places as decals. Explosions, impacts, mud and blood splatters can now all dirty up your ship. Did I say blood splatters? Oh yes, trampling enemy troops is now a thing that works:

Click to Play


Take that, tiny Air Grenadier!

Another kind of particle I've added is snow, and to make that more complete, there's now snowy landscapes:



So what's next for dev 7? With legs pretty much working now, it's time to pay some attention to tracked vehicles. Finally, I want to instill troops with some basic ideas about navigating the ground. This lets them board buildings by simply dropping to the ground and running in, abandon crashed ships, and reinforce their comrades elsewhere.

If they don't get squashed beforehand, that is.
Offline Zarkonnen
« Reply #59 - Posted 2015-07-13 18:36:42 »

So I'm just about finished with work on tracked landships. Compared to ones with legs, they're faster, sturdier, but less able to deal with rugged terrain.



In terms of game physics, they're held up by a set of springs much like legged ships - essentially a suspension. Wheels and tracks are drawn on top of this. The wheels are simple to draw, but the tracks are made up of lots of individual links. They alternate between big links with surfaces that touch the ground and slightly smaller ones. You can see what this looks like in real life on this image of a Japanese tank I used for reference.



Now the Hard Bit was calculating the shape along which the links are drawn. The track needs to run along wheels and between them. It boiled down the track being composed of two strictly alternating types of sections.



Curves following a wheel between two angles.



Straight lines that connect two wheels.

Curved sections can be of length zero, which happens when three wheels in a row are perfectly in line. Finally, there needs to be some special casing for when three wheels in a row form a concave shape, as the tangential lines connecting wheel 1-2 and 2-3 would cross in that case.

Once I'd coded that all up, I tried it out with debug graphics, then spent some time fiddling with things so that the rotation of the wheels gets correctly fed into the offset of the link drawing. Or to put it simply: making the tracks move!



The results look pretty good, I think.

Now as you may know, the heraldry system in the single-player campaign lets you select a heraldic charge (a symbol) for your side's coat of arms (your flag or "logo") that gives you some bonus. For example, the scales give you extra income from cities, while the lion improves your troops' abilities at boarding combat. With such a major new feature, there of course have to be some new bonuses. There are going to be three. I will unveil the first one now, the second in the next blog post - and the third one when v7 comes out.



Boar's Head Erased +20% HP for tracked landships

So what's next? I'm just working on making the crew smarter so they can move across the ground, between ships and floating rocks, enabling them to do things like transfer between ships. Beyond that, there's about two dozen bug fixes and then it's time for dev7.
Pages: 1 [2] 3
  ignore  |  Print  
 
 

 
Riven (207 views)
2019-09-04 15:33:17

hadezbladez (4943 views)
2018-11-16 13:46:03

hadezbladez (1822 views)
2018-11-16 13:41:33

hadezbladez (5222 views)
2018-11-16 13:35:35

hadezbladez (1029 views)
2018-11-16 13:32:03

EgonOlsen (4406 views)
2018-06-10 19:43:48

EgonOlsen (5237 views)
2018-06-10 19:43:44

EgonOlsen (2978 views)
2018-06-10 19:43:20

DesertCoockie (3880 views)
2018-05-13 18:23:11

nelsongames (4312 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!