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.

Morgaelin – Updated to latest libgdx, HTML5 version

Thanks to the efforts of Exodus Destiny, and after some always needed tweaking, Morgaelin has been updated to libgdx 1.9.5 from a veeery old version from around 2013.

One of the thing this allows is having a working HTML5 version, you can check the current, very early version HERE. (GIANT WARNING: DON’T BUMP INTO PEOPLE.. leaving the combat area may cause the process to hang!)

morgaelinweb

So far the experience with libgdx, at least for web, is not as straightforward as doing JS (thank you, Captain obvious). It uses GWT underneath so it’s compiling Java into JS (teh magic, after all these years still!). OTOH it generates native android programs and multiplatform Java desktop as well. May be after I sink more time into it I’ll be able to do a side by side comparison of it vs Ananias’ stack.

Rise of Kramora, now available for Android (phone)

Well,  I just felt like I had to make the game available for phones as well because:

  • … not many people has Android Wear smartwatches these days
  • … specially, wanted the 7DRL jurors to be able to play.
  • … wanted to create a native android app
  • … wanted to test how hard it’d be to create an app to run in both type of devices.

This mean you can play the game now in your Android Phone! have in mind that this is STILL the original 7DRL edition. I haven’t made any enhancements to it! You can find more info about the 7DRL release here. Basically, don’t expect a revolutionary game, but I hope you can find it entertaining: The main goal (game-design-wise) was making something you could play any time, without any commitment, but still find challenging.

Play now for free!

onphne

In order to make it happen I had to move some things around, creating an Android Library module on Android Studio, moving all the generic code and resources into it and linking the wear and mobile modules with it. This module contains the game classes (the “model”), the sprite “engine” (i.e. the library for sprite management and tweens) and the generic view (based on an android.graphics.Canvas, and thus compatible with both the wear and mobile modules) and controller.

Screen Shot 2016-03-21 at 7.53.42 PM

The wear module was then left with just the WatchfaceService (wired to the Game, View and Controller); since it has built-in messaging-based timing functionality, it could easily be wired to the sprite engine, to provide animations at a given frame rate (24FPS).

The mobile module, on the other hand, had none of this…. Fortunately I stumbled upon this tutorial, which was very helpful on creating a simple rendering engine backed by a SurfaceView, which in turn was wired to the game, view and controller. Lastly, there was a simple Activity which set the SurfaceView as its ContentView.

The hardest part however was memory management… because of its 7DRL nature I was pretty sloppy, loading all bitmaps (AND their scaled version) into memory. For some reason it went well on the initial Android Wear version, but the bitmaps on memory were just too big for the phone.

The first change I had to make was no longer storing the scaled versions, but rather using methods to scale them on the fly while drawing. It’s a balance of processing power vs. memory, but it seems to be able to handle it pretty well. However there’s still room for improvement, I may revisit this if I find out it’s a big problem.

After this, and adding a “wristwatch” border, the phone version  was almost working, then I wanted to double check the watch version and, weirdly, tons of memory errors happened.

Oddly, I spent lots of time just trying to get the Wear version working back again…  I did lots of changes, including loading bitmaps on request instead of caching them, but I did it on the main thread because I needed them available immediately (bad idea). It worked, but was pretty choppy so in the end I discarded that, and settled for manually downscaling all the game graphics from a 512×512 base to a 320×320 one, which made sense since in any case that’s what most Android Wear watches are up to now. (and in any case it should upscale for newer devices).

In any case, I hope you enjoy it! Please let me know if you run into any issues running it!

Rise of Kramora, day 3 7DRL 2016

Well, this is getting interesting 🙂

Looking forward to add simple animation, I am creating a simple sprite management engine for Android wear. I refactored the code and also changed the interaction model to be able to handle up to three actions per state.

image

Giovanny has been hard at work too illustrating the enemies (so far we have 4). They are looking great.

image

As you can see, I’ve also redesigned the game so there are more interactions now; in battle you will be able to use mind and elemental magic as well as doing basic attacks. The engine is flexible enough to add new actions as needed.

Things are looking for the release. This is a rough plan:
– Implement magic spells
– implement tweens for damage values, combat and movements.
– Add balanced content.
– Add pending graphics.

2016 7DRL – Rise of Kramora, Day 2

We have a new name and a new theme:

After much pondering you have come to a conclusion… there’s only one solution to save this decadent world: Summoning the Great Serpent Kramora to exterminate all life on the planet, and let new life arise…

Decades of studying scrolls of magic and history point you towards the path of your fate: You must climb the Tower of Sephira, battling the holy knights guarding the Ancient Tome of Kramora Summoning. Will you be able to overcome the defenders of Order?

12776866_10153205474312563_606495102_o

In the small amount of time I managed to scrap today, I added support for graphics. It’s almost working.

The graphics are being drawn by Giovanny Ramirez, my cousin, who’s also done some quality Ananias work in the past. I hope we manage to have all required assets on time!

2016 7DRL, Relojiah Day 1

Legend of Relojiah is a lightweight roguelike designed to be played on smart watches. Explore the labyrinthine Tower of  Time, battling monsters and finding powerful artifacts.

Today I managed to implement all basic interactions for the first iteration of the game, there’s a playable game already!

20160308_175057

You play by tapping on the screen, depending on your current mode you’ll either continue exploring the current level (looking for more powerful weapons and armor), or attack the enemy you are fighting. Once you find the stairs to the next floor you can decide if you continue exploring the current level, or climb to the next one. The design is based on the roguelike in a tweet I made some months ago.

2016-01-16 18.57.13

There are no graphics yet. I’ll get to that tomorrow with my provisional art, but I’m also looking for an artist to work with. What would be required would be some low resolution illustrations for the background, items, monsters and the player.

2016-01-16 18.58.26

After graphics are implemented I’ll play a bit with the content to make it balanced. In the unlikely event I’ve got more time to work on it, I may add some simple tactical options for battles.

I also plan to make it available for other devices; I’m still wondering whether doing it on JavaScript so it can be played anywhere, or creating a native Android app (the watchface would come bundled with it)

PixelWorld watch 0.2 released

I had been toying around with this idea in my head for a while…

Aeons ago, while developing the world browser for Pixal, I thought on adding a graphical indicator of the current time of the day inside the game world. Denzi then sent me something some pretty cool art, but since Pixal never saw the light of the day… that art was never used.

Some months ago I got my Moto360 smartwatch and as expected the first thing I thought of was, what can I develop for this? I did some tests and created a sample watch (Which I may eventually polish a bit more and release). But then I thought… I really need to use the sun-and-moon scenery from Pixal for a watchface!

The idea was simple, basically to show the sun and the moon cross through the sky as the day and night went by.

watches

Since we already had the animations, I thought on having a minstrel playing music on the ceiling of a tower while the days passed. I was inspired by this animation Denzi had

minstrel091107-1

I shared my idea with Denzi, and he actually had something slightly different in mind, blending the initial idea with a standard analog watch.

Denzi150913-4

The current result is a bit different than what was planned, but I decided to jump on it and create something simpler; I required some additional art assets from Denzi which I could never get, and I also thought this simpler design without animation works better for battery consumption.

pixelworld3

pixelworld2

pixelworldicon2

I actually had some features in mind that didn’t make it to the initial version (And probably won’t go in, since I think it’s good enough as it is):

  • Showing the phases of the moon in the moon icon
  • Checking weather and using it to draw rain, snow or cloudy days.

So, if you have an Android Wear Smartwatch, what are you waiting for, check it out at the Play Store, and share with your friends 🙂

(One annoying thing I haven’t been able to get rid of so far is the app asking for the “Account” permission set.)

 

Savage Empire SNES – Approaching the Urali – the translation tools are now open source

The tools are now open source, you can find them here, they contain an automation of all the findings so far, taking mostly Vehek’s and DDS input along with a lot of experimentation and fiddling.

Unlike most SNES RPGs (?), dialog in the game is a bit complex because the options the player can choose depends on things he has done in the game or things he has already talked about with someone. This is all represented with a set of flags. I have been trying to complete the list as well as adding comments to the disassembled code in order to have a complete understanding of all of the conversations’ flow.

There seems to be a total of 36 “dialogs” into the game (either that or there’s a different set of rules for other dialogs).

  • Dialogs 11 and 35 seems to have a lot of blank space in the end
  • Dialogs 20, 23, 27 and 36 generate errors when loading the dialog options
  • Dialogs 22, 23, 24, 25 and 26 seems to be loading dialog options from other place since I’m unable to read them

These dialogs have been analyzed for flags completely:

  • 15, Inara Chief of the Pindiro
  • 16, Inatnya from the Kurak
  • 21, Mosagan from the Yolaru

Topics

  • Still not sure if the text extraction is 100% accurate; specially on the final lines on each conversation things starts going a bit crazy. Can only confirm this by inspecting the dialogs inside the ROM. DDS already pointed out a possible inaccuracy, I may have to check if our assumptions about the ShiftJIS encoding and the charset loading are correct all the times.
  • Need to find an way to hack the ROM to test the dialogs quickly, somehow pointing Intanya to any dialog I need.
  • Still not sure about the termination sequence I’m using for each dialog;  basically I’m assuming a 0xB8 (LOAD_DIALOG_OPTIONS) means the current dialog has ended and the next one has begun. The thing is not all dialogs ends the same but that might be ok.
  • Gotta solve the issue of dialog options loading for dialogs 20+

There’s still a long way ahead, but at least we are doing some progress 🙂