Escape from Krakatoa Remake

I've been working on my remake of the classic game Escape from Krakatoa for a few weeks now.  I'm already the top Google result for "Escape from Krakatoa remake" (about the top 5 results actually) which says more about the fact that no-one has attempted a remake of this game rather than my internet omnipresence.

The game "components" that I've managed to create using JBox2D is the helicopter, a rope, the landscape, water, the tanker and the rocks thrown from the volcano.

Here's a video of a few of them combined.




They are all basic polygons at the moment (with the exception of the water), but it shouldn't be too difficult to replace them with proper graphics once everything has come together.

At the back of my mind is what new aspects I can add to the gameplay.  I was thinking of something like, the player can (must?) transport crates to the islanders or the tanker to keep them supplied, whilst also defending them against rocket attacks.  And, unlike the original, maybe the player can actually help the islanders escape from Krakatoa?

Just discovered JBox2D

I think I'm pretty late to the 2D physics library game; I've just discovered Jbox2D and I can't believe what I've been missing.  Apart from anything, it handles all the collision detection for you, which saves tons of coding straight away.  But not only that, it also handles them in realistic ways.  As a game developer, you just create all the physics objects and then let the physics engine do everything else.  All you need to do is draw the graphics and handle user input.  It's so good, I'm surprised at the lack of example code on the internet.

Here's a small vid one of my first experiments - water and getting something to float in it.

It's pretty simple, but what's even simpler is the code required to do this.  I've just created the particles and the rectangle, and then the rest is automatic.  The main bit of code I had to write was drawing it all.

I've been messing about with it for a few weeks now, and my first "big" project with ti is going to be a remake the classic Escape from Krakatoa using JBox2d.  It's a game that lends itself to a physics enghine; the player flies a helicopter, must avoid rocks being thrown from a volcano and rescue people from the island.  I'm going to check I can recreate each aspect using the physics engine, and then put it all together.  Next up is flying a helicopter.

Easy Network Programming For Games

When you start developing your latest multiplayer game, and get onto the networking aspect, do you wish there was a way to avoid having to re-write the same code over and over again?  All the handling of sockets, multiple network threads, keeping track of clients etc...?  Me too, so that's why I wrote the Generic Multiplayer Connector.

The Generic Multiplayer Connector (GMC) is a library to help turn any single-player game into a multi-player game by allowing clients to easily connect to a shared server and pass data to each other without having to worry about all the usual networking complications. It uses a client/server model, and when a client sends out any data, it is automatically received by all other clients in the same game. Clients also receive notifications of when a game has been won and who the winner was.

GMC is also completely open source and can be downloaded here: https://bitbucket.org/SteveSmith16384/genericmultiplayerconnector 

Why should I use GMC?

That's a very good question. There are lots of other networking libraries out there. However, the real advantage of GMC is that it requires minimal setup, configuration and handling:

• Running the server is simple a case of running a jar. Because the server is generic, a single server can be used for any number of different games.
• Once a client is connected, it can send data, and will automatically receive data, from all the other clients playing in the same game. All you need to do is decide when to send data, what data to send, and what to do with the data when it's received.
• You don't need to worry about handling network connections, multithreading, keeping track of other players etc.. Just send and receive data.
• There are built-in methods for accessing the current status of the game (waiting for players, started, finished), notification when a player has joined/left, and who the winner of the game was.
• There is a free publicly-accessible server waiting for you to use.

 

Example Code

Running the server:-

    // Run this in a command prompt
    java -jar GMCServer.jar 

All the following code is run on the clients.

Connecting to the server:-

    // This will bring up a form for the user to enter an IP address etc..
    ConnectorMain connector = StartGameOptions.ShowOptionsAndConnect(this);

    // Alternatively, if you have your own method of getting the 

    // connection details:
    ConnectorMain connector = new ConnectorMain(this, "127.0.0.1", 

        9996, "Steve", "MyGame", 2, 99);
    connector.connect(); 

Joining a game:-

    connector.joinGame(); 

Sending data to all other clients:-

    // There are other ways, this sends a key/value pair by TCP.
    connector.sendKeyValueDataByTCP(code, score); 

Receving data

    // 'game' is your class that implements the IGameClient interface.
    game.dataReceivedByTCP(int fromplayerid, int code, int value);

Damn, I've been killed in the game

    connector.sendOutOfGame(); 

I've got to the end! Was I the first?

    connector.sendIAmTheWinner(); 

But who has the server confirmed as the winner?

    System.out.println("The winner was " + connector.getWinnersName() + "!");

 

 Quickstart Guide

These are step-by-step instructions on how to incorporate it into your project:-

• Run the server GMCServer.jar, or decide to use the public server described below.
• Add the GMCClient.jar to your project.
• implement the IGameClient interface in a class in your game.
• Create instance of ConnectorMain().
• Call ConnectorMain.connect() to connect to the server
• Call ConnectorMain.joinGame() to join a game.
• Wait until all players have connected ("ConnectorMain.getGameStage() == GameStage.IN_PROGRESS") and then start your main game loop.
• Send data to other clients with any of the ConnectorMain.sendKeyValue..., ConnectorMain.sendString... or ConnectorMain.sendByteArray... methods. All the other clients will receive any data sent.
• Receive data using any of the IGameClient.dataReceived... interface methods.
• Call ConnectorMain.sendIAmTheWinner() if your client won the game, or call ConnectorMain,sendOutOfGame() if your client is out of the game.
• End your game when "ConnectorMain.getGameStage() == GameStage.FINISHED", or if your client has finished (i.e. the player has died), call ConnectorMain.waitForGameToFinish().
• Once the game has finished, you can get the winner's name with ConnectorMain.GetWinnersName().
• You can then call ConnectorMain.joinGame() to join/start another game, or ConnectorMain.disconnect() to close all network connections.

 

Public Server

I run a server at 178.62.91.22 that can be used by anyone.  As stated above, any GMC server can be used for any game or any number of games.  (See the source file Statics.java for the port). Note that this server is not guaranteed to be available 24/7 forever though, and should not be used for anything mission-critical.

Ares:Dogfighter now Open Source

Due to lack of popular demand, and the fact that I've slowly stopped developing it, the source code and assets of Ares:Dogfighter are now available on BitBucket here.  It should be pretty useful to Java programmers looking to get started with 3D.

Here's a video showing its current state:-

Stuck in a Loop

I'm at that juncture again where I ponder the question to myself "Why am I writing games?"  I've been working on a game called "Ares:Dogfighter" for a few months now, but I'm slowly getting bored with it and there's a chance it will get slowly abandoned.

I always start with the best of intentions, and starting on a new game is great and exciting: the idea is epic in scale, the possibilities are endless, the screenshots in my head look great, and I know how I'm going to write all the code.  However, fast-forward a few months and I'm stuck debugging a small but frustrating problem that's taking up a lot of my time, and nobody has played it (or at least, no-one has told me they've played it).  So why am I spending the time writing it? 

Part of the problem is the time that marketing a game now requires, but without marketing, no-one will see the game among the other trillion games out there.  Setting up the blog/website/twitter account and regularly posting to it takes time, and my time is already limited as it is.

I'll probably stop developing games for a few months and start playing them again.  Or I could jump onto an open-source game and contribute to that, but I find it very hard to find semi-decent Java open-source games.  Eventually I'll have an amazing idea for a game, start work on it, and the process will start again.

My take on No Man's Sky missing multiplayer feature

IMHO, what has happened to No Man's Sky's "missing" multiplayer feature is a no-brainer.  I think they originally planned to have it in, but eventually came late to the decision that it was not going to be completed in time for the release date, which couldn't be put back again.  However, Sean will have been under immense pressure to never actually say "NMS will *not* have multiplayer", since sales would have been adversely affected.  His hope was that no-one would manage to meet up until they had added the multiplayer feature in an update (and also try and discourage people from even trying to meet up due to the immense odds of that happening), but unfortunately, they did.

So Sean did the only thing he could: avoided directly answering any questions (since to say anything other than "multiplayer doesn't exist" would be an outright lie) and is now hoping that the multiplayer feature could be completed ASAP and added as a "multiplayer fix", since the feature was already there, just wasn't working properly.  Right?

Use InputStream.available() with caution

You might assume that InputStream.available() returns how many bytes are available to be read from your stream. And you'd be almost right; it's really how many bytes are guaranteed to be available, not how many are actually available. 

Okay, to get to specifics, my problem occurred when I used a ZipInputStream wrapped around a file. I (stupidly) assumed that all the bytes must be available, since it's a file sat on my computer. However, since ZipInputStream reads a compressed file, the number of bytes available isn't the same as the original file size. (I should mention that at this point I didn't actually know I was reading a zipped file, as the whole point of streams is that you don't normally need to bother yourself with the implementation).

In addition, ZipInputStream.available() only returns either 1 or 0, so it would be unwise to use that size as the basis for an array to ready the data in.

So, my point is, available() should really be [treated as] a boolean.  If it's > 0, great, you can read something.  Just don't put any reasoning behind the actual number.

Zero-Time Programming

Welcome to a description of my new programming paradigm: zero-time programming.  Being a busy family dad, I've got no time for programming.  I've got no time for even reading blogs, never mind actually writing one.  Or that's what I thought until I developed zero-time-programming, for people who have zero spare time but still want to create and release something.

The principle behind zero-time programming is to write code, run it yourself (if you've got time) and then release it.  The main requirement is that you have the facility in your released software to inform you immediately if there's a problem; my usual choice is by email, so I get an email every time there is an error.

"But this is crazy" I hear you say.  Sorry, I've got no time to discuss it.  I will concede that this is not the best method for writing mission-critical code for NASA, but if you're a hobby programmer like me who just wants to get games out there while also having family life and full-time job, there's no better choice.

Here's the main bullet points to help you out though:-
 
* Wrap all your new code in a try/catch, and in the catch, send yourself the error.  That way, the whole program won't grind to a halt.
* Throw exceptions wherever something happens that shouldn't, i.e. at the end of switch statements.
* Make a note of any thoughts you have about what to code, immediately.  Whether in the shower, on the toilet etc.., your subconscious will do a lot of the thinking for you, so don't ignore it or forget what it's telling you.  I've "found" plenty of bugs whilst sitting on the toilet.
* Use your own code, and make other code your own.  Avoid moving ground.  Who's got time to refactor code when your favourite library decides to change their method signatures?
* Send yourself a message from your software when something you need to check for happens, so you know it is happening (or not).
* Sanity checks - for example check variables aren't null.
* Ensure your error messages state which version has the error, so you can ignore old errors that have already been fixed.
* As you code, if you think of an extra bit of code that needs to be written in addition to the bit you're currently writing, e.g. a null-check that needs to be made, quickly write a todo, e.g. "// todo - nullcheck socket".  Otherwise it will fall out of your head and bite you later.  Once you've written the bit you're writing, do a search for all the "todo's" in your code and addess them.
* Never start a new project from scratch.  If you can, copy an existing project and refactor it towards your new ideas.

All this will save you loads of time.  How long does it take to go through a testing plan?  Too long.  Of course, this method of programming may mean you get a stream of messages informing you of bugs, but that just means you can fix them as soon as you have a spare couple of minutes, and then upload the next version.

Announcing Ares:Dogfighter

My "very early space game demo" has transmogrified into a game!  Although still very early in development, there is now something to download and play.  It's called Ares: Dogfighter, and you take control of a spaceship and can fight enemy ships using lasers and missiles.

Here's a brief gameplay video:-

The game is uses the excellent JMonkeyEngine for the 3D, and lots of complicated Java code for the rest of it.  Getting the AI to fly realistically was a challenge; the standard response for a pilot, whether AI or human, is to try and point their ship at the enemy ship in order to shoot them.  However, this has a tendency to result in both ships flying around in circles until someone dies of boredom.  I've made the AI check for this, and if things aren't happening then the AI will react with some random evasive manoeuvres.

The game is free to download and there are versions for Windows and Linux.  Please let me know what you think!  (Or at least whether it works).

Very early space game demo

It will probably turn into some kind of Elite-style game.

Loading a texture from a file in JMonkeyEngine

It's taken me over an hour to work out how to load a simple .png file and use it as a texture on a box.  To help prevent anyone else who might be having the same problem from tearing all their hair out, you need to ensure two things:-

* Your files must be in a directory off your main directory called "assets/Textures/[png file]".  You must conform!

* Add the line "assetManager.registerLocator("assets/", FileLocator.class);".  Despite what the documentation says, this isn't added internally by default!

Also, when adding the texture to the material, the String parameter isn't your own name as you might first assume, but must be the text "ColorMap".

Java Voxel Engines with Source

I recently carried out a trawl of the internet to find all the open-source Java Voxel Engines I could.  My intention is to use one of them as a foundation to write my own voxel-based game (which is still a long way off).  I didn't spend too long on each one; I simply checked that they worked and that they included all relevant code.  Here are my results which others may find useful.

Firstly, the best ones I found.  (As an aside, one of my general requirement is that an open-source project should work, once all dependencies have been resolved, and these should be resolvable easily.  What's the point of releasing source code that doesn't work?)  These all worked:-

* https://github.com/MovingBlocks/Terasology - You could say this was the best of the lot.  It worked first time and looks amazing.  The only drawback is its complexity; there's loads of code and loads of dependencies and libraries.

* https://github.com/mk12/mycraft - This is a great simple engine.  It's only about 8 classes big but provides a nice simple voxel engine in Java.

* http://borderterrierart.weebly.com/programming.html (BlockWorld) - This one seemed to fit my requirements best.  It's got lots of features including .obj model loading, and worked first time.  The only drawback is that the source is a bit messy (formatting, unused vars etc..)

* https://github.com/Zaneris/Tranquil - This worked well, and since it uses LibGDX could work on mobile devices as well as PCs.


Other Mentions:-

* https://github.com/aaasen/voxel-party - This worked, although it didn't have any textures.


* https://github.com/matortheeternal/JVoxelEngine - This uses raycasting.  Seemed very slow and simple, and although it worked, it was very bare-bones.


I couldn't get these to work:-

* https://github.com/SpoutDev/Spout - Seems very worthy, but I couldn't get it to work as the Maven build fails.

* https://github.com/afaulconbridge/ArdorCraft - Couldn't get this to work due to missing source.


The following use JMonkeyEngine which I haven't tried:-

* https://github.com/Sleaker/Cubed
* https://github.com/TheWiseLion/VoxelTerrain
* https://github.com/jMonkeyEngine-Contributions/voxel
* https://github.com/melsov/JMonkeyVoxel
* https://github.com/boogie666/Blocky
* https://github.com/roboleary/GreedyMesh
* https://github.com/francois5/voxelengine


And I also found these two projects which are not voxels, but rather "traditional" 3D but still worked very well:-

https://www.youtube.com/watch?v=kBcGrLGAbQ0
https://www.youtube.com/watch?v=7IXFUflNZJs


That's pretty much all I could find. I hope you find it useful.  I'd be interested to know if anyone has found any more, and which one's they found the best?

Team Tactics

Team Tactics is a new realtime action multiplayer tactical strategy game that I'm currently developing.  You could probably label it as a MOBA or an ARTS.  Whatever the label, the game works like this: each player controls a single unit, which is on one of two sides (although in the future I might expand this to 3 or 4).  Depending on the mission (or "game mode"), each side has an objective, and the winner is the first to complete this is the winner.


ANOTHER MOBA-STYLE GAME?

Technically yes, but you could probably say something similar about any game since the 1980's.  This is how games progress; almost all games are very similar to what came out before.  But hey, let's not argue about that here - I'm developing this game for several reasons:-

* I like multiplayer games more than single player games.  It's far more fun to play against someone else where you can see their reaction and gain pleasure from their pain (and vice versa of course).

* I like to add new features to games, and this game will have features that no other MOBA has.  Whenever I'm playing a game I always wish I could tweak this or that.  If I have my own MOBA, I can do that.  In addition, if any players request a feature, it's always a pleasure to be able to do that.

* I think true "tactical" MOBA's are a bit thin.  I'm not a gamer, but I can't actually think of another multiplayer tactical game where working as a team is paramount.

* I like developing games, and the best way for me to maintain interest in whatever game I'm currently developing is to have something to aim for, i.e. similar game(s) that I want to reproduce and hopefully improve upon.


WHAT FEATURES WILL IT HAVE?

This is just a brief summary of the main features.  I'll blog about new ideas as I have them:-

* Multiple unit types - this is a no-brainer of course.  They will be different in that some move faster than others or shoot more accurately, but some will have specific skills required for missions.

* Multiple missions - There are currently two missions, The Assassins and Moonbase Assault, more about which I'll do another post.  I might also transpose some of the more interesting missions from Stellar Forces.

* Map editor and easy customisation - I want people to be able to easily customize this game (in so far without affecting balance), e.g. adding their own graphics and sounds, maps etc...

* Different weapons and equipment as well as the usual guns - smoke grenades, nerve gas, ammo packs, gas masks, incendiary grenades.  Grenades mean destructable maps!

* All the usual features like fog of war, line of sight, unit stats, chat, voting etc...


SUMMARY

I'm really excited about this, and really looking forward to playing it.  I enjoy a game of TF2 as much as the next person, but sometimes it lacks enough depth for me.  This should address that, and also be fun to write.  I've never written a realtime multiplayer game before (more than 2 players, anyway), so looking into all the technical aspects will be very interesting.

UPDATE:

Wiki: http://team-tactics.wikia.com/
Blog: http://team-tactics.blogspot.co.uk
Download:  http://teamtactics.penultimateapps.com/teamtactics.zip