Voyage – Better forests and rivers, darker land

Toned down the palette a bit on the ocean and grass tiles.

Also added forest and “plains” variations, replacing the fixed tropical palm trees and brown patches of land, also put some trees in front of them mountains to make them blend a bit better.

Started working on the rivers, gotta do some big changes on the model to pick the tiles based on the world model instead of the player’s perception (since the field of view can greatly affect it). That is, there may be a river tile you are not seeing to the east of the one you are seeing, the game should be able to pick a river fragment expansing eastwards, but right now it relies on perception data so it cannot know.

Another things to work in related to rivers:

  • Linking together patches of river so they flow continuously
  • Adding support for lagoons which will be a mix between the beaches and river models.
  • Differentiating shallow ocean water to rivers.

As I feared, I’m ending up investing more time on the Java version of Expedition/Voyage than I anticipated, I just cannot release something half-baked… I’m even considering completing a bigger scope for it and releasing it as Expedition… my mind just keeps spinning and spinning.

Voyage: Full Screen mode in Java, extended FOV

Was able to get full screen working using the good old Full Screen Exclusive Mode API, at first tried to accommodate the game to 640×480 but found out the dialogs for buying on stores and transferring equipment wouldn’t work in this resolution unless I invested some heavy work on them.

So in the end rolled back the work I had done for both compacting the UI and scaling the graphics layer manually… now using the original 1024×768 design for the DenziUI, with a small but important twist…

Running full screen at 1024×768 with extended FOV

I duplicated the depth of the field of view, which I think makes the game look much better in my opinion!

Some upcoming interesting things (besides the already mentioned “macro” goals in the previous post):

  • Enhance forests and mountains by using different graphics variations
  • Pick forest/jungle type based on latitude

“Voyage” is born, and how it handles land border tiles

Thank you all for your feedback regarding my last post, after much debating here’s my current mindset:

  • Current version of Expedition, while not covering the whole planned scope, is already a playable and potentially enjoyable game which requires some UX fixes to be shipped.
  • The gameplay ideas which composed the original scope for Expedition are worth implementing in a different format which can be appreciated by a broader audience.
  • I won’t be able to work extensively in the full version of expedition in the following months, thus it will likely be released in 2018.
  • The current version of Expedition can be released soon, freeing myself of the burden of having wasted trillions of dev time milliseconds.

That brings two games I’ll be playing in the following months…

Game 1: Release “Voyage”, the current version of Expedition

First thing I did was rolling back a lot of the changes made in the last months of development on 2012 for both Expedition and SERF when trying to modify the engine to run continuously and show animated sprites, thanks to the power of git (and a well done migration from SVN), I was able to roll back to about the status of the last public version (0.5)

Then after giving the game some playthroughs, I defined 3 macro areas to work in:

  • Minor and effective UX changes: Remove redundant data and interaction steps that were in place to allow future functionalities which will no longer be. Polish appearance without investing a lot of time on it.
  • Polish mini colonization facet: Remove clutter, simplifying the way settlements work while at the same time integrating them with the game winning conditions.
  • Balance game: Experiment with data to ensure the game can be won in around 5 voyages.

Upon examining the Java code I found out it isn’t THAT bad. There’s a nice structure, an engine which was unfortunately not meant to support animation from its onset.

engine

One of the things people suggested and I thought would have a strong impact was adding the “beaches” or land borders to the overworld. I toyed around with many ideas while I familiarized myself again with the code, and in the end decided to include it as part of the “rendering” process instead of it being part of the map model itself. At first I tried to do something similar to what I had done with Ananias walltops: Analyzing different scenarios and deriving rules based on them.

walltops

However, I thought that approach may not be needed in this case since this was simpler… doing that “2.5D” appearance for Ananias was sure a lot of work, but here it is an overhead view so I figured there may be a simpler solution. After some googling I found an old article which was pretty useful and in which I based my approach.

cleanerUI

What I’m doing is, for every visible water map cell I’m checking the surrounding cells to see if there’s land around. Each one of the 8 directions has a weight assigned as a power of 2 (with some additional tweaks for the ordinal directions), the sum of these weighted values determines what tile to draw over the ocean.

boolean[] mask = new boolean[]{
    upLand || leftLand || upLeftLand,
    upLand,
    upLand || rightLand || upRightLand,
    leftLand,
    rightLand,
    downLand || leftLand || downLeftLand,
    downLand,
    downLand || rightLand || downRightLand
};
int sum = 0;
for (int i = 0; i < mask.length; i++){
    if (mask[i])
        sum += POW_2[i];
}

There’s a map which maps values for this sum with base indexes on the tileset as follows:

POWER_MAP.put(128, 1);
POWER_MAP.put(224, 2);
POWER_MAP.put(32, 3);
POWER_MAP.put(148, 4);
POWER_MAP.put(41, 5);
POWER_MAP.put(4, 6);
POWER_MAP.put(7, 7);
POWER_MAP.put(1, 8);
POWER_MAP.put(47, 9);
POWER_MAP.put(151, 10);
POWER_MAP.put(233, 11);
POWER_MAP.put(244, 12);
POWER_MAP.put(239, 13);
POWER_MAP.put(191, 14);
POWER_MAP.put(247, 15);
POWER_MAP.put(253, 16);
POWER_MAP.put(255, 17);
POWER_MAP.put(5, 18);
POWER_MAP.put(132, 19);
POWER_MAP.put(160, 20);
POWER_MAP.put(33, 21);

 

beaches

Additionally, there are three variations for the beachfronts, what set to use is determined by using a hash function over the location of the cell on the world.

I also cleaned up the UI removing redundant info, changing the font for something more readable and relaying out everything to avoid wasted screen space. In the end I decided to support only the “Denzi” 32×32 tileset, which looked pretty good when I added the “beaches” and resized the viewport to 600×450.

I also worked on trying to add a full screen mode to the game. So far I have had partial success on this, I was able to scale part of the game but the engine works by having two layers: one where graphics are drawn (which I could successfully scale) and another one with UI components based on Swing which I think will be too hard to work with. I also found out the current way of finding the screen dimensions is troublesome on dual screens or scenarios where there are system menus taking part of the screen (although I think this could be fixed by using actual window measures instead of display size)

scaling

This is a hard one… I’m thinking on ditching fullscreen and make it work just windowed, although I recall some experiments on CastlevaniaRL back on… 2004-2005? which made full screen work without manually scaling (and which scaled Swing components as well)… I’ll have to dig a bit on it and see how it works in modern machines.

I’m planning for a release of this in around 2 weeks.

Game 2: Restarting work on the full version of Expedition

Expedition will play and look a little bit like a RTS, with miniature AI-controller units (and probably lots of them in some scenarios), following the player around an infinitely large world where Exploration is the main concern. It will NOT be a RTS, you will have direct control only over a single unit, and the game won’t focus on finding and exploiting resources on the world, nor placing building strategically or even tactical battles. In a sense it will be more of a toy, a miniature world you can explore with your miniature explorers.

expeditionMockup
Some initial ideas for the game, although my current vision would be a bit different with smaller looking units and a different art style.

Player created content will be a huge part of it, it will include an editor where players can build their own scenarios and worlds, themed in their favorite series or historical events.

It will feature seedable procedural world generation and most of the features defined in the current roadmap (which will soon be updated to remove some things that defintively won’t go)

Given these requirements, I am still not sure if Phaser is the way to go… I’m considering using Unity for it, but that’s a choice that may still wait for a bit.