viernes, 28 de agosto de 2015

Multiplayer modes in CaboTrafalgar

Multiplayer modes in CaboTrafalgar

Commands and Generators

Some common vocabulary needed for understanding following text.

Commands are the smaller representation of an action that a user can do, and it´s declared and generated by each Ship individually. Some ships will offer "rudder left", "right", "mainsail in", "out", while other can offer the same four plus "move weight right", "left". Commands are, therefore, up to the Ship creator and this game takes them and tries to find who can implement them.

Generators come into play then, once we have some commands, we ask the Generator Manager (or similar) how many generators we have available for each one.
There are some generic Generators like Keyboard, able to map all Commands, also Remote is able to map everything, but we might find other Generators restricted about the type of commands able to deal with.

Once we have Commands and the possible Generators, it´s up to the user map each command with the desired generator (they could be keyboard, remote, and also wiifit, joystick, or mouse, just as example).

Finally, each Command is mapped to the chosen generator through a finest specification, in case of keyboard, associating a key.

Multiplayer Mode 0, Offline competition (DONE)

This was the first multiplayer mode done in CaboTrafalgar, for which I have "recordserver". It stores all verified user´s games and best are shared so other users can see, learn and compete against them.

It offers a ranking with times and users to enhance competition.
Information uploaded comprises position, rotation and commands executed per frame, this would be later (not yet) validated by recordserver, who shares back positions per frame, but erases commands.

This way, another player can´t simply take other person´s record as his, commands are needed and game reexecuted to validate authenticity (not yet again).

In order to make this mode, I needed to introduce a Ghost class able to reposition a Ship every frame, which gave me the idea of the current class atlas (to be explained in other post).

Multiplayer Mode 1, Shared controls on a local game (DONE)

We now offer the option of sharing an arbitrary number of Commands to another player, but all calculations are still made locally (your computer, not any of CaboTrafalgar servers) and the rendering is also local to your sole screen. This is, you must be sharing with somebody in your room.

The transfer is made through a barcode able to be read by any SmartPhone that can open a web application with those shared controls on it (this uses our servers), or you could use our app for that (in progress).

As a result, commands travel from your guest´s device to our servers, only to be transfered back with no alteration to your computer, where they´re interpreted just like your own input. As much this is a local collaboration that these results would be uploadable to RecordServer as they were yours alone.

 

Multiplayer Mode 2, Multiplayer game

Little explanation here, who doesn´t know what´s this about? Game doesn´t happen in your computer anymore, you´re just rendering the movements our server will tell you, like they were Mode0 ghosts, and your input will travel far from your computer like it was a Mode1 SmartPhone.

Of course, not everything is always so simple, and some calculation could be done at your computer for fluidity´s and optimization´s sake, but the principles are the same, we need a server online where the calculations are done, and new speeds and positions are redistributed for clients to render.

 

Multiplayer Mode 3, Shared multiplayer game

This is the goal I aim from the first day, this game was always defined as a collaborative multiplayer naval battle simulator. A captain that delegates functions in other players inside the ship, and with help of other ships, fights another number of players collaborating in other ships.

Game again happens remotely, but controls can be shared remotelly as roles, or locally as controls, as a mix of Mode 1 and 2.



miércoles, 8 de julio de 2015

Nifty-flow code released

I finally managed to separate my nifty-flow from cabotrafalgar, and it's started to be ready to open to other users.

What's nifty-flow?
  • A library that helps you to create series of screens to be played in order.
  • A library that helps you to share screens, as they won't need to know where to point next, screens are no longer pointing to other screens.
  • A library that helps you to reuse the same screen, accesible from different screens, allowing decoupling content and routing.
  • A library that (will) help you to apply template technologies to save time creating dynamic screens avoiding java builders.
  • If you're using Spring or Guice for wiring your instances, we won't complain, it's generic enough to accept instances from any system (as long as you build the bridge wink)
It's build on the top of nifty 1.3.3, and fully compatible with jme3 AFAIK.
Code and example here: https://github.com/albertonavarro/nifty-flow
Feedback is welcome, the project works for me though smile

http://hub.jmonkeyengine.org/t/nifty-meets-flow/33139

domingo, 3 de mayo de 2015

Understanding CaboTrafalgar Physics 1 - Tidal forces in shipModelZ

Index:

(To come)


This is the first entry of a series to explain where we are now with physics in the game, and where we want to be.

Most of the entries will refer this "dinghy", ShipModelZ, in regards of movement and commands.

This post is actually an easy win, and that's the best way to start a path, with a victory in an apparently difficult topic as "Tidal movement".

During the hundredths of seconds a frame lasts, several calculations are made to try to simulate movement realistically, considering real or apparent wind, boat position, sail position, rudder position and weight location. In this calculation, tide is not considered, as we're calculating movement OVER the tide (same way, we don't consider the movement of the earth around the Sun for highway speed calculation).

Once we know what's the tri-dimensional distance we want to move over the sea, we need to add the absolute movement of the water, giving as the final distance we have moved.

Code explanation:

private void updatePosition(float tpf) {
        Vector3f shipOrientation3f = this.getGlobalDirection();
        this.move(shipOrientation3f.x * localSpeed * tpf, 0, shipOrientation3f.z * localSpeed * tpf);
        this.move(getContext().getWater().getMovement(this.getGlobalDirection()).mult(-30 * tpf));
        shipDirection.setValue(shipOrientation3f);
    }

For this model, all movement is calculated in the direction of the keel, no lateral movement has been modelled yet. Direction of the keel is "this.getGlobalDirection()"

Local speed is the speed "ahead", direction defined by the keel, it acts as the modulus of a vector, while the keel is the direction of the vector.

As we're just interested in horizontal movement, we take first and third elements in the vector, times the speed, times tpf (time per frame) to get the final distance we've moved over the sea.
On top of this, we apply the movement of the tide for that particular location (this is a bug, we should be passing position, not orientation, but it doesn't matter, the implementation of water context is not as complex yet for it to matter), times some handy constant times time per framework.

So magic is done, on top of the ship movement, we have tide speed complicating everything.

That's it for today.. :)

jueves, 2 de abril de 2015

domingo, 25 de enero de 2015

LazyLogin 1.4, what's coming


Maybe because I'm a software engineer, maybe because I'm not good with words, this is my preferred way of explaining what's coming with next version of LazyLogin.

I'm quite happy with current status of 1.3, simple protocol and execution, simple service, and it was enough for the main public release so far for Cabo Trafalgar (0.9).

Now it's time for preparing it for the upcoming developments, and finishing the original ideas that were just half done, promising myself I'd finish them when I saw the concept working.

First, I need to decouple the embedded AMQ, and maybe replacing it with another MQ system. Once done this, LL will publish user information (properly protected, but bearing in mind that this system is meant to be closed and some information can be shared among systems). By all means, I'll try to keep email absolutely enclosed to LL, but I'll need some replacement for private key in the meantime for unverified users.

To these changes, we need to add a proper way to measure performance, securing endpoints with some SSL protection, a better coverage of test across component, integration, sanity and unit, and adding performance testing for first time.

Finally, a notification service integrated in LL would allow our services to send notification emails to users without knowing their address, keeping it safe forever.

I plan to spend some months with this, then, much more to come..

martes, 13 de enero de 2015

Cabo Trafalgar v0.9 Released!

Big one!

Changes:
Connected with LazyLogin and RecordServer services to provide online services.
Profile manager screen.
Control selection to be ready for more than keyboard, and key selection screens.
New Ship introduced, with weight balance control apart from MainSail and Rudder.
Map selection screen now with descriptions and graphic maps for a better understanding.
Introduced tidal sea movement (sea currents) as a possible element in the maps.
Win installer.
Enhanced dynamics, more realistic.
A thousand bugs and aesthetical details fixed. Probably another two thousands created.
And an exit button!!

Tickets:
https://github.com/albertonavarro/cabotrafalgar/issues?q=milestone%3A0.9+

Windows users: Download caboTrafalgar.exe
Linux users: Download JMonkeyClient-0.9.jar and execute it with java -jar JMonkeyClient-0.9.jar

Required: Oracle Java 1.7, Openjdk 1.7 or Oracle Java 1.8, as well as a good graphic card.

Download from: https://github.com/albertonavarro/cabotrafalgar/releases/tag/v0.9