Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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: 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.)
2  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.
3  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?
4  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.
5  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.
6  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.
7  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.
8  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.
9  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.
10  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.
11  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.
12  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
13  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!
14  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...
15  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.
16  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!
17  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...
18  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

19  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.
20  Game Development / Performance Tuning / Taming Java GC to prevent stutter, an in-depth post on memory management on: 2014-04-23 10:13:05
Spurred on by this post, here is an in-depth post on memory management in Airships.

Excerpt:

The game is written in Java, where unused data is automatically deleted in a process called garbage collection. This is nice, but comes with a big drawback: you can't control when garbage collection (GC) happens, and it can take too long.

The game runs at 60 frames per second, giving each frame a bit more than 16 milliseconds to advance the game state and redraw the screen. If GC kicks in during a frame and takes 30 milliseconds, the game stutters noticeably.

So this is something that needs fixing.

Read the rest
21  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-31 21:34:25
I'll look into that ASAP! Have you tried the newest version (v 2.1 from https://airships.zarkonnen.com/download )?

If yes, there should be a log in %APPDATA%\AirshipsGame.
22  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-31 15:46:34
Have you thought about checking the collision of the text boxes, so that they don't overlap?

Very good point, thanks.
23  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-31 13:06:24
Today marks the release of the second early access version of Airships. I've been working flat out to improve the game over the last week, and there's some cool new stuff:

Smaller modules

There are now small versions of various ship modules, opening up more ship design space. Previously, the smallest viable ship was about 300 gold. Now it's 90.



Internet multiplayer

There is now a game server where you can create multiplayer games and join others'. Come and measure yourself against other players!



Active enemies in strategic mode

The AI empires now go conquering, which means it's very important to keep your cities defended.



Shouty crew!



The next release is likely to take longer, as I plan to add major new features such as boarding. I also have about a zillion blog posts I want to write about the game, such as some lore things on suspendium and a ship design guide.

As before, the game's available on itch.io, and existing players can (of course) download this upgrade for free.
24  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-25 12:03:04
The early access release is up!

<a href="http://www.youtube.com/v/3iki9rKIixE?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/3iki9rKIixE?version=3&amp;hl=en_US&amp;start=</a>

Some more details about the game:

At its core, the game is about designing airships and fighting with them. Ships are put together out of modules, and the layout of modules matters a great deal: everything on board is done by individual airsailors who need to run around, ferrying coal, ammunition, water and repair tools - and sometimes their fallen comrades.

You can command fleets of airships both against the computer and against other players across the Internet. (A match-making and ladder service is planned, but right now, you just enter your opponent's IP address.)

In addition, there is a single-player strategic mode, where you use your fleet to conquer city after city, unlocking new modules and bonuses with each of them.

The game has an authentic-ish system of heraldry where you can create your own coat of arms, and register it with the game forums as unique to you.

Interested? You can get it on itch.io for $5.

This is an "early access" release, which means the game is by no means done or perfectly polished. There's lots of features which I'm planning to add in the near future, such as boarding combat, more modules, varied terrain, etc...
25  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-18 20:15:53


I did a blog post on AI programming you might find interesting. Also, the early release version of the game will probably be out this week! (Details also in the post.)  Grin
26  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-10 09:11:44
So I was watching the video,  it seems like the thing is ai controlled maybe make it so that you have to control each ship so to keep it flying you need to get people to shovel fuel into he engine and that if you run out of fuel it splats to the floor(not sure if thats what brought the big one down) . That said there is huge potential in this and I would willingly play this and have a lot of fun. ps love the graphics Smiley

 Grin Pretty much, yeah. Everything on board of an airship is done by the little people, who are needed to do the following:

  • Operate engines
  • Move coal to the engines
  • Fire guns
  • Move ammo to the guns
  • Move water to fires and put them out
  • Move repair tools to damaged places and repair them
  • Heal injured people
  • Move badly injured people to the sickbay
  • etc.

Job allocation and movement is all done automatically, so you just give high-level commands to the ship as a whole.
27  Games Center / WIP games, tools & toy projects / Re: Procedural 2d Pixel Vessels / Space Ships on: 2014-03-10 09:05:19
OK, these look like my fever dreams. In a good way, I think.
28  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-03-08 10:43:17
If you've been following my Twitter, you may have seen a series of increasingly exasperated tweets about my computer. Basically, for work reasons, I had to upgrade my Mac to Mavericks, the newest OS X version. Unfortunately, Mavericks causes my machine to freeze irretrievably after a few days, and only a complete reinstall temporarily fixes the problem.

So now I'm, grumbling, back on Snow Leopard (IMHO the best version of Mac OS X), having lost a lot of time in the process. So yeah, that whole idea about releasing the early access version around now isn't happening, but I hope to get it out there before the end of the month.

I have not been entirely non-busy, though. A week ago, I was afforded the opportunity to do some playtesting. As I wrote before when I did this with Patent Blaster, there is just not substitute for putting down someone in front of your game and wordlessly watching them trying to figure it out.

The day after the playtesting I filed something like sixty new issues on Airships' tracker, ranging from trivial graphical adjustments to "feature X does not work". I selected the ones that I felt were important enough to get fixed before the first early access version, and have been plowing my way through them. (At least when I wasn't trying to fix my computer.)



One big change, visually, is that I adjusted the color of the sky to be less saturated, on the basis of this great article on game visuals and user feedback that the ships didn't visually "pop out" enough.



While doing graphical adjustments, I also took the opportunity to put in an early version of the main menu background, a digital painting of airships that I'm working on. It's by no means done, but I just, er, blurred it enough that you can't really tell. As time goes on, the picture will come into focus more.
29  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-02-28 14:06:37
No quarters?  Sad

So heraldic charges give you in-game bonuses, which means I'm restricted to relatively simple layouts. Still, more layouts is definitely something I want to add soon.
30  Games Center / WIP games, tools & toy projects / Re: Airships, a ship design & fight game on: 2014-02-25 12:08:14
Looks interesting Grin I remember making such drawings in intricate detail during my childhood. This is like these drawings coming alive.

Goog luck with this, I'm curious it will turn out.

Yeah, that's pretty much it. I spent so much time laying out submarines and stuff. In fact, here is the original drawing I made for this:

Pages: [1] 2 3
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (55 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (89 views)
2014-12-09 22:41:13

BurntPizza (111 views)
2014-12-08 04:46:31

JscottyBieshaar (83 views)
2014-12-05 12:39:02

SHC (92 views)
2014-12-03 16:27:13

CopyableCougar4 (99 views)
2014-11-29 21:32:03

toopeicgaming1999 (159 views)
2014-11-26 15:22:04

toopeicgaming1999 (158 views)
2014-11-26 15:20:36
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

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!