Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (565)
Games in Android Showcase (151)
games submitted by our members
Games in WIP (606)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3
1  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
2  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-09 20:39:55
Actually that looks like a driver bug to me.

Cas Smiley

Yeah, driver bug is probably more precise. Smiley I've patched Slick to not check for pbuffers, and now it's fixed.
3  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-05 16:10:06
OK, this turns out to be caused by a lwjgl bug.
4  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-05 07:21:12
I'm afraid none of this matters, because it's the call to getGraphics that makes things crash!
5  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-03 06:44:39
In your real code, are you doing this:
Graphics g = img.getGraphics()
and use the graphics object or are you calling it the same way you are in your sample code?

In the real code, I create the Image once only, and I do use the Graphics, of course. But having minimized the reproduction, the thing that causes the crash is getGraphics() alone. Note that it doesn't crash at getGraphics. It crashes later, at the end of the frame, during nSwapBuffers.
6  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-02 20:09:29
It's a native crash Pointing There won't be an Exception.

Anyway, as you are creating an image every frame, you might run out of vRAM, making the texture allocation fail, after which Slick2D might be sending its pixels to a null pointer.

This happens on the very first frame. Sorry if the example is misleading. In-game, I don't recreate the image each time.
7  Java Game APIs & Engines / OpenGL Development / Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-02 14:14:52
On some machines, creating a new Image and calling getGraphics() on it causes lwjgl to enter into some kind of faulty state that crashes when swapping buffers. Any idea what causes this and how to make Slick clean up after itself properly?

Reproduction code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
    package crashrepro;

    import org.newdawn.slick.*;

    public class CrashRepro extends BasicGame {
        public static void main(String[] args) throws Exception {
            CrashRepro cr = new CrashRepro("CrashRepro");
            // Crash only happens in fullscreen mode.
            AppGameContainer agc = new AppGameContainer(cr, 800, 600, true);
            agc.start();
        }

        public CrashRepro(String title) { super(title); }

        @Override
        public void init(GameContainer gc) throws SlickException {}

        @Override
        public void update(GameContainer gc, int i) throws SlickException {}

        @Override
        public void render(GameContainer gc, Graphics grphcs) throws SlickException {
            Image img = new Image(128, 128);
            img.getGraphics(); // This crashes the game.
        }
    }


Stack trace:

    Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
    j  org.lwjgl.opengl.WindowsContextImplementation.nSwapBuffers(Ljava/nio/ByteBuffer;)V+0
    j  org.lwjgl.opengl.WindowsContextImplementation.swapBuffers()V+35
    j  org.lwjgl.opengl.ContextGL.swapBuffers()V+3
    j  org.lwjgl.opengl.DrawableGL.swapBuffers()V+0
    j  org.lwjgl.opengl.Display.swapBuffers()V+39
    j  org.lwjgl.opengl.Display.update(Z)V+44
    j  org.lwjgl.opengl.Display.update()V+1
    j  org.newdawn.slick.AppGameContainer.gameLoop()V+78
    j  org.newdawn.slick.AppGameContainer.start()V+17
    j  crashrepro.CrashRepro.main([Ljava/lang/String;)V+27
    v  ~StubRoutines::call_stub
8  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
9  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
10  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
11  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
12  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.)
13  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
14  Games Center / Contests / Re: Java4K Competition 2015 on: 2014-12-08 15:46:57
I would be up for that. How about say 12 kB of Jar created with vanilla javac and jar as suggested by SimonH?
15  Java Game APIs & Engines / OpenGL Development / Re: Slick2D Shader Crash on: 2014-12-04 07:26:23
To be honest, what concerns me is the error message.

1) I've never seen a an error printing the native stack.
2) The stack trace doesn't make sense.

this function "org.lwjgl.opengl.ARBShaderObjects.nglUniform4fARB(IFFFFJ)V" is not called in the source you have shown us. The method you are calling is "setUniform4f()" in ShaderProgram.

Ah, I can explain!

1) It's an error.pid trace. The program crashed in native code.
2) The disjoint between the function called and the function in the trace is because the JVM optimized out intermediate function calls. So setUniform4f calls nglUniform4fARB.
16  Games Center / Contests / Re: End of 4K. Thanks all! on: 2014-12-03 09:32:25
That is understandable if sad. I continue to love the format for prototyping if nothing else. Thank you for all those years of crazy Java fun.

A successor JS/HTML5 contest could be cool. In fact, there is such a thing, called Js1k, though it's not specific to games and most entries aren't games.
17  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
18  Java Game APIs & Engines / OpenGL Development / Slick2D Shader Crash on: 2014-11-30 14:35:30
I'm using Slick2D's ShaderProgram for shader-based drawing in my game. Some players report that after 3-10 minutes, the game inevitably crashes hard during what appears to be a setUniform4f operation that's happened thousands of times before:

1  
2  
3  
4  
5  
[error occurred during error reporting (printing native stack), id 0xc0000005]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  org.lwjgl.opengl.ARBShaderObjects.nglUniform4fARB(IFFFFJ)V
J  com.zarkonnen.airships.Appearance.draw(Lcom/zarkonnen/catengine/Draw;DDDDILcom/zarkonnen/catengine/util/Clr;Z)V


Why might this happen? Is it a transient problem, or maybe a driver issue? I'm confused that this happens not when the shader is bound, or when textures are set, but at the point of this utterly mundane operation of setting a 4f value. I'm in fact pretty lost here, as I can't even repro this on any of my own machines.

This is the culprit function in its entirety:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
public void draw(Draw d, double x, double y, double w, double h, int ms, Clr tint, boolean flipped) {
if (shaderLoadFailed) {
   drawFallback(d, x, y, w, h, ms, tint, flipped);
   return;
}

if (tex == null) {
   tex = loadTex(SPRITESHEET);
   if (tex == null) {
      shaderLoadFailed = true;
   }
}
if (sp == null) {
   try {
      sp = ShaderProgram.loadProgram(
            AGame.getGameDirectoryPath("data/passthrough.vert"),
            AGame.getGameDirectoryPath("data/frag.frag"));
   } catch (Exception e) {
      e.printStackTrace();
      shaderLoadFailed = true;
   }
}

if (shaderLoadFailed) { return; }

sp.bind();
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL11.GL_TEXTURE_2D, tex.getTextureID());
sp.setUniform1i("tex", 0);
if (tint == null) {
   sp.setUniform4f("tint", 1.0f, 1.0f, 1.0f, 1.0f);
} else {
   sp.setUniform4f("tint", tint.r / 255.0f, tint.g / 255.0f, tint.b / 255.0f, 1.0f);
}

Img img = frames.get((ms / interval) % frames.size());

glBegin(GL_QUADS);
if (flipped ^ isFlipped) {
   glTexCoord2d(img.srcX, img.srcY);
   glVertex2d(x + w, y);
   glTexCoord2d(img.srcX, img.srcY + img.srcHeight);
   glVertex2d(x + w, y + h);
   glTexCoord2d(img.srcX + img.srcWidth, img.srcY + img.srcHeight);
   glVertex2d(x, y + h);
   glTexCoord2d(img.srcX + img.srcWidth, img.srcY);
   glVertex2d(x, y);
} else {
   glTexCoord2d(img.srcX, img.srcY);
   glVertex2d(x, y);
   glTexCoord2d(img.srcX, img.srcY + img.srcHeight);
   glVertex2d(x, y + h);
   glTexCoord2d(img.srcX + img.srcWidth, img.srcY + img.srcHeight);
   glVertex2d(x + w, y + h);
   glTexCoord2d(img.srcX + img.srcWidth, img.srcY);
   glVertex2d(x + w, y);
}
glEnd();
sp.unbind();
TextureImpl.bindNone();
}


And the shaders FWIW:

passthrough.vert
1  
2  
3  
4  
void main() {
   gl_TexCoord[0] = gl_MultiTexCoord0;
   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}


frag.frag
1  
2  
3  
4  
5  
6  
uniform sampler2D tex;
uniform vec4 tint;

void main(void) {    
   gl_FragColor = texture2D(tex, floor(gl_TexCoord[0].st) / 1024.0) * tint;
}


As you can see, there's very little to them.
19  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
20  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
21  Game Development / Game Play & Game Design / Re: How do I make a moddable game in Java? on: 2014-10-14 08:19:10
I ended up supporting modding in my game due to user request - that is, people started modding the game even with no formal system in place.

So the laziest way you can support mods is to add an external mods directory to your classpath. This way, modders can drop in modified versions of your code and mod the game like that. That's basically the Minecraft approach. But it comes with severe limitations: you have to let people fiddle around with the code of your game, the mods will break whenever you bring out a new version, and the learning curve is really steep.
22  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 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.
23  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 2014-09-02 07:58:01
Air-to-air paratroopers sounds awesome. Also adds to the mechanic that you have to get above the enemy to be able to board them, unless you get jet pack upgrades or something.

Yes, definitely! I'm thinking the grappling hooks could be an upgrade which lets you do more horizontal boarding.

And then there might be Air Dragoons... Cheesy
24  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 2014-09-01 09:27:29
I'm now getting started on airship-to-airship boarding, which is the major new feature in the next development release. With boarding, you can send air marines to enemy ships to disrupt them and even take them over.



The actual sending over part is a bit tricky, because crew members move inside the grid of their airship. This means there is currently no way to represent someone not inside a ship. To allow air marines to jump or glide or grappling-hook across the gap between two ships, I will have to introduce a second system of tracking people's position. The second system will be in the same coordinate system as the ships itself, and will have to deal with physics, collision detection, etc.

So for now, I'm just going to ignore all that and make the crew teleport over! I even added a completely pointless particle effect for it.

Click to Play


Why? Because I want to get to the more fundamental part first: what happens during boarding?

Air marines boarding an enemy ship should try to disrupt its operation, and if there are enough of them, even take it over. These two goals are somewhat at odds, since the fastest way of disrupting an airship would be to make its suspendium chambers stop working, making it fall out of the sky. But I doubt that the air marines would be inclined to make the ship they're in crash. Instead, I decided that the marines will target weapons systems, propulsion, and command centers, rendering the ship harmless but still afloat. So once an air marine has boarded a ship, he will path to the nearest "interesting" module - a gun or propeller or bridge, and start shooting the crew in there.

The other question is how taking over a ship happens. Airships are complex entities, so what does it mean for one to be taken over? The rule I decided on: if there are no crew members of the current owner in any of its command centers (bridges or cockpits) and at least one crew member (air marine) of the opposing side in a command center, the ship's owner flips. The invading marines get added to the crew list while any surviving defending marines are now considered the new invaders. The normal air sailors are set to be "under occupation", which means they will only perform a subset of duties needed to keep themselves alive: they will put out fires and run suspendium chambers, but nothing more. The occupying air marines will have to do any fighting duties.

Having figured things out, it was time to start building!

Air marines will have to perform normal crew duties in occupied ships (and they can also help out in your own), so they should be a type of crew. So first off, I introduced a concept of "crew type" to distinguish between marines and sailors. These have different sprites and different competencies: sailors are more efficient at working in airships, but much weaker in combat.



Next, I added a new module type, the barracks, which was pretty straightforward.



The game also has to keep track of whether someone is on board a ship as an invader or as a crew member, so I added a separate list of boarders, and got to work on rewiring the crewmember and airship classes to make this difference clear. A lot of questions like "how many crew are in this ship" had to be made more precise.

Next, I implemented a "board" command for airships, borrowing liberally from the existing "target" command and fiddling in GIMP until I got a decent-looking grappling hook for an icon.



So I got to the first tests: the marines would teleport over to random locations on the other ship - and then just stand there, going "Oh, that is a nice cannon you have here. And it is indeed shooting at my ship. oh well, carry on!".

I needed them to actually go and do some mayhem, so next up was pathing: identify the modules of strategic interest and move there. Pathfinding was already available from the code for air sailors, so this was pretty quick. And of course, once they got to their targets, it was time for them to shoot things!

The game already has a concept of shots from ship-to-ship fights, so I reused and extended this. It's cleaner than introducing another mechanic, plus it potentially allows for things like boarders shooting ships, ships shooting boarders, etc. This meant extending the shot class so it can come from a crew member as well as a weapon, and differentiating whether it comes from inside the ship or not. (Shots from inside the ship don't get held up by armour.)

Now I just had to tell boarders to shoot crew and vice versa, and a fight for the ship finally happened! And, as it turns out, a rather silly bug: I forgot to tell marines that they can't move when badly injured or dead, so now I had casualties and corpses sliding around on the floor and impossibly climbing ladders while prone, slowly moving to the next place to conquer.

Click to Play


Having fixed that, combat now proceeds reasonably: the boarders go and shoot up the bridge and cannons of the enemy ship, weakening it. Next up will be the takeover phase: boarders converging on the bridge, and the ship's allegiance switching over.

No doubt boarding will need a lot of balancing work. Right now, it feels way too powerful, but this may be because it's very easy thanks to the temporary teleporting. In the end, boarding should be one tactical option in your arsenal that works in certain circumstances, much like ramming, sniping with rifles from high up, grounding your ship, forcing down an enemy, and so on.

Join me next time when I put in the ship takeover mechanic and start figuring out how to make the marines move between ships!
25  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 2014-08-11 18:15:02
Ramming is already an important part of airship battles, which tend to be quite physical. In early access version 5, one of the major goals is adding external modules - such as proper ramming equipment.



Credit

I started out with some historical research: what did ships' rams actually look like? There isn't that much visual material available, but it turns out that a common pattern for ancient Greek and Roman vessels was a bronze ram with three projections, as seen above.



Credit

One of the cool things I discovered during my trawl is that there is a full-size, fully functional reconstruction of an ancient Athenian trireme, called the Olympias. The ram on it is really quite prominent, and you can see how it could be used to good effect to hole enemy ships.



Credit

Another interesting detail is that some ancient warships had two rams - a main one to hole the ship, and a smaller, spiky one, to break the enemies' oars.

More modern naval rams look more boring, as they are basically projections of the metal hull of the ship. So in the interest of fun, I decided to pattern the ones in the game on the more ancient type. This is what I came up with for the basic ram:



And then this is what you get as an option if you pick the Ram as your heraldic animal:



Which lets you do this:



I am quite pleased with this outcome.

Next up, I'll be writing about some other new external modules, such as sails and tanks of suspendium dust. If you want to try the game out, have a look at the early access version, or upvote it on Greenlight...
26  Games Center / WIP games, tools & toy projects / Re: Airships: Conquer the Skies on: 2014-07-31 10:57:47

So the game's on Steam Greenlight now, which is a "fun" experience of watching a number intently, willing it to go up. I would be extremely grateful for upvotes, as I still need several thousand to have a chance of being picked by the great steam bird when it next visits, plucking the ripest game-berries from the greenlight tree. Uh.
27  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-07-04 12:10:07
Reminds me of the land ships from the book Leviathan.

Oh cool - both of these look like a goldmine of inspiration, visual and otherwise. Thanks!
28  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-07-03 10:21:15
I've been sketching some concepts:



A turret with a > 180 degree field of fire. Flexible, but very big and expensive.



A landship, totally inspired by these from Girl Genius.



A wurm, a juvenile dragon...
29  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-04-30 07:54:06
There's a shiny new version out, mostly focusing on stability and UI things, but also adding some huge new modules like a targeting computer and a repair bay. The next version's going to focus on adding some new mechanics like boarding. Cheesy

30  Game Development / Performance Tuning / Re: Taming Java GC to prevent stutter, an in-depth post on memory management on: 2014-04-23 19:25:11
Yeah, I'm not using object pooling at all here, I just found three places where I was allocating objects for no good reason. And yeah, I measured before and after my modifications to make sure I was actually catching the right things. And yes, it did definitely remove noticeable spikes in frame times. Smiley

As lots of people say, the GC is very good these days, and you don't often have to worry about this kind of stuff outside of Android - but in this case, the game was allocating so many objects there were actually noticeable GC pauses messing up the feel of the game.
Pages: [1] 2 3
 
ags1 (21 views)
2015-03-31 10:55:12

theagentd (13 views)
2015-03-27 23:08:20

wxwsk8er (54 views)
2015-03-20 15:39:46

Fairy Tailz (48 views)
2015-03-15 21:52:20

Olo (29 views)
2015-03-13 17:51:59

Olo (33 views)
2015-03-13 17:50:51

Olo (40 views)
2015-03-13 17:50:16

Olo (44 views)
2015-03-13 17:47:07

ClaasJG (61 views)
2015-03-10 11:36:42

ClaasJG (44 views)
2015-03-10 11:33:01
How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27
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!