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.

Plans for Expedition

The noble history of Expedition goes way back into the past as far as 2009. I invested around 300 development hours on it, and many times I’ve sit to plan its future… now that Ananias is released it’s time to finish it for good.

Expedition was the original Slashware Interactive project (I abandoned my day-job to work on it). I was going to be a great indie developer, but then many things happened when I tried to scale the work I had already made into a bigger product with features to appeal more people (I lacked the experience to create a fully working 2D game engine with Java, and back then there were little options). Simple things such as adding tile animations turned into a hell dealing with threading stuff and trying to make Swing behave, and performance was subpar.

There’s been a public version at the website for some years; it is completely playable but doesn’t include all that I had planned for it. Now I’m wondering again what would be the better approach to finish it, for which I have two main issues:

Issue # 1 – What technology to use

Option 1 – Finish the development from the current codebase in Java

Pros Cons
  • Quicker time to market.
  • No animations AT ALL.
  • No scrolling possible ever.
  • No 2D graphic effects.
  • Not very fun to work in (may cause frustration)
  • Not available for mobile devices.
  • Support for music / SFX is limited.

Option 2 – Remake in JS using Phaser

Pro Cons
  • Can use animations and graphic effects
  • Scrolling is possible
  • Rewriting is always fun and adding the new stuff.
  • Available for more platforms.
  • Start from scratch, may take around 80 hours to get to the current point.
  • JS weakly typed nature may make maintenance harder.

Issue # 2 – What features to include / How to roll them out

There’s a huge roadmap with lots of features I’ve dreamed. But what will be the best approach to release them as a product?

Option 1 – Release a first edition with minimum features.

Reduce the feature set to include mainly exploration focused stuff, leaving aside other stuff for the future.

This first interaction cycle could be summarized as follows:

  • Assemble your Expedition in Spain making the best use of limited resources.
  • Survive transatlantic journey to America braving storms and handling your crew.
  • Establish towns to serve as safe places for your Expedition.
  • Explore the new world looking for native civilizations, ruins, natural wonders, exotic plants and animals, obtaining fame to be rewarded on Spain.
  • Trade with natives or conquer them, obtaining goods to sell on Spain.
  • Survive transatlantic journey to Europe.
  • Be rewarded for your journey, prepare for next voyage.

Having in mind the previous issue, an attractive option would be doing a first release using the current Java codebase, which already covers most of this cycle (I would still need to invest some time on the exploration and trading parts tho)

Option 2 – Go a little further

Expedition won’t be a graphics intensive game (See issue #3 below). This means it has to be good in other aspects in order to be attractive for people.  Releasing an early version without all the features may just not be appealing enough and make Slashware look bad.

Here’s a summary of some prioritized features from the roadmap that could be added:

  • Autosailing: Follow a direction for a given time or until an event happens.
  • Colonies production: Make towns produce goods
  • Colonies growth: Make colonies grow on size on themselves
  • Military buildings: Allow building barracks to train colonists into soldiers, walled fortresses and towers.
  • Road making: Allow creating roads of different quality. Units can move faster over them, mounted units and vehicles get an additional bonus.
  • Mines: Allow finding veins and creating mines, linking them to colonies.
  • Camping: Add expedition fatigue, allow to make camp for the night, and sleep on the ships.
  • Land Vehicles: Add land vehicles you can use to carry more, restricting movement to some terrain types.
  • River Exploration: Add rowboats to explore shallow waters.
  • Zoomed in areas: Generate zoomed in areas for mountain passes, caverns and towns, allow zooming into them.

Also not included in the roadmap but definitively interesting to pursue:

  • More random events that could happen both in the sea or during land expeditions.
  • Personalized profiles per expedition member and relationships between them

Option 3 – Aim for something even grander

There are many other things from the original roadmap which I consider just don’t fit a concise vision for the game: To make the player experience being in one of the first European expeditions into the new world, that feeling of being tracing new lines into the world map. This is due to an initial biggest statement of Expedition being a “detailed sandbox of the XV century world”, that’s just too big and may be very hard to turn into a fun experience.

These include things like interacting with other European expeditions, traveling to other parts of the world (including visiting mediterranean cities), simulating relationship between the different nations, laying siege to cities (but then expeditions become armies), trading all around the world

There are however some facets that I still consider interesting exploring, may be as add-ons to the original since they’d require more populated territories to work:

  • Piracy: Be a pirate captain, recruit rogues, steal ships, look for buried treasures, attack cities.
  • Religion: Spread your faith in the land, combat infidels.

Issue # 3 – Graphics Style

The game currently supports 5 different graphic styles, where the player is left with the choice of which one to use. Should I instead impose a single choice to give the game an unique character and make development easier?

SwingBox and Curses are ASCII modes where all output is represented with characters, I think only an extremely minor portion of the players will enjoy and understand it which makes it hard to consider a default choice… but interesting enough, if I were to use them then continuing using Java would be a perfectly valid option. (this was the original output mode, and all complications began when I added graphics over it). They work using libjcsi, a java ascii display lib I did years ago.

Then we have the modes with actual graphics, there are currently two tilesets for Expedition, a 32×32 tileset made by Denzi and an 8×8 tileset made by Oryx. Denzi tileset is shown 1x in “Denzi” mode and 2x on “Big Denzi” mode (with tiles being distorted as rectangles in order to fit the screen). Oryx tileset is shown 3x.

The Oryx tileset should have a familiar style. It’s very iconic and does a great job of providing a graphics representation while not requiring a great production effort for new tiles. I’ve thought on using a slightly modified version of it in order to make it feel a bit more unique.

Of course, Denzi tileset is more detailed (specially for the units), however due to the nature of the game engine, the map model and the turn based interaction, the world looks a bit weird on it. May be it would look a bit better with some post processing for the “beaches” to use the corner tiles supplied. May be it’s the color of the sea, I don’t know.

I am not sure about the “BigDenzi” mode… On one hand I think the perspective fits more the higher resolution of the characters, but some people have complained about the distortion on the map. I also dislike having two different scales of pixel art shown at the same time (one for the UI, another one for the map). In any case, the font choice for the Denzi modes is absolutely horrible.

Of all the graphics mode I think I prefer the Oryx one for it’s symbolic potential and ease of extension in case newer features are added.


That’s the current status of things with Expedition… I’m in a bit of a development paralysis pondering these things… if you have any thoughts please let me know, all input is very helpful! Would you play a game with NO ANIMATIONS AT ALL? do you find the basic interaction/gameplay cycle interesting enough?

Ananias 2.3 released, challenges and steam achievements


A lot of work went into adding support for Steam achievements using the excellent Greenworks library. This version includes 37 achievements and there are 10 additional ones I couldn’t add due to the API for progressive achievements not being available on Greenworks; the addition doesn’t look overly complex, however I would need to set up a complete dev env for it (right now I’m using their precompiled binaries).

The challenges are not steam exclusive, but they are only tracked right now on Steam (that means you’ll still see when you complete them on any other version, but they won’t be added to your profile).

I also bumped the version of nw.js to 0.20.3 (I think I had to do it in order for greenworks to work). This increased the size of the downloadable packages for desktop quite a bit.

I think I’ve ran out of Steam to work on Ananias for the moment… it’s been such a long time, and I’ve got a couple of projects to work in (for $$$) and also the rebirth of Expedition keeps haunting me day and night. Although the backlog is filled with feedback from players, I don’t think I’ll be able to tackle their suggestion for some months, so it’s now on maintenance mode where I’ll only be fixing critical issues.

This version also includes some small but important gameplay changes, see below for complete info.

Check out version 2.3.0!

Achievements

  • Add support for Steam achievements via Greenworks
  • Add 19 challenges (all linked to Steam achievements but also tracked on the other versions)
    • Assault, Flintstone, Brave Chamo, “That comes handy…”, Caretaker, Shepherd, Die Hard, Dungeon Explorer, Breaking stereotypes, Burning stereotypes, “I gotta be the very best”, Dungeon diver, Sword collector, Super Shepherd, Die Hard II, Massacre, Legendary Shepherd, Genocide, “Was this supposed to be hard?”
  • Add 16 “marks” as Steam achievements
    • Discover the ruins of Ananias, Discover the Caverns of Chaos, Discover the Underground Lagoon, Discover the Crystal Caverns, Hero of Alchemy, Hero of Wizardry, Hero of Chivalry, Hero of Archery, Hero of Hack’n Slash, Hero of Soul, Hero of the Elements, Hero of the Mind, Hero of Humility, Discover the Lair of the Ancients, Discover the Darkness Abyss, Back to the roots
  • Add 2 steam unachievements
    • “Are you there?”, “Oh well…”

Gameplay

  • Allow shooting over friendlies
  • Show health description for enemies on inspector
  • Prevent levels with far too many “big rooms”
  • Increase max carry capacity to 30
  • Drastically reduce chances for boosted Combat and Strength when fully exploring levels.

User Experience

  • Add intro track to intro

Still pending…

  • Complete support for Steam overlay
  • Keyboard support for:
    • Using multiple selection dialogs
    • Checking player and pet stats
    • Navigating thru menus
  • Additional Steam Achievements for Marks
  • Detailed GFX for weapons and armor.
  • Adding more plot and may be even random stories.

Ananias introspection: Content Creation and Balance

This new series of blog posts will be based on /r/roguelikedev FAQ Fridays, a long standing series of discussions where roguelike developers share their techniques and experiences around a single topic.

FAQ Fridays Revisited # 6 Content Creation and Balance (original)

How do you decide what mobs/items/abilities/terrain/etc to add to your game? In any good roguelike content creation is inseparable from the concept of balance, so your methods of balancing content are certainly within the scope of this discussion.

Ananias has a fairly static collections of monster races. They were first added based on the original rogue monsters and with a single criteria on mind: each race should have an unique feature or ability.

Sometimes implementing an ability is costly and there’s the temptation of parameterizing it so it can be reused with slight variations, but I think it gives more character to the monsters having their distinctive skills. This means Ananias doesn’t have Ice, Fire, Water, Earth and Thunder dragons whose only distinction is the “type” of their attacks, I’d rather have a single Dragon monster distinguished by a strong ranged attack.

The uniqueness of an enemy race is not defined only by their active skills, their stats are also put in consideration. In this case they are assigned relative values first (i.e. orcs have high attack and medium hp, Lizardmen have extreme high attack and low hp). This is balanced so that races without cool active skills get some advantage stats-wise.

The dungeon is then split into 5 areas with increasing difficulty. Mob races are grouped thematically on these areas and then assigned final values for their stats by scaling their relative values to the difficulty level of the group they are in. In order to do this, I do a projection of the average stats for the player on each one of these areas and then I apply some simple general rules (for example, a strong monster may kill the player in 5 hits, a monster with low HP should be killed by the player in a single attack). These define ranges within which the stats of the final monster will be placed.

Items follow a similar model. For weapons and armor I started with a list of preexisting graphics (the artist made them on advance for a different game using his own creative criteria) then based on they appearance I assigned them relative values (high/mid/low) for damage and integrity (how likely they are to break), and then I grouped them on power tiers to define their final stats. They also get assigned a generation weight representing how likely they are to be added to the levels, this value is used in level generation along with the power tier to select the items to be added.

Player abilities are guided by the same principles of uniqueness. Ananias is strongly classed, and each class has unique passive skills that guide players into adapting different playstyles for each one. The process for player classes is similar as with the monster races, they are balanced based on their skills and relative values for their stats. (Except for the shepherd ;)).

On a final note, I’d like to say that while seeking to balance the different stats is worthwhile (to prevent your game from being utterly broken), it’s also to some point a futile exercise, since the variability of the game and the player’s choices create a lot of unpredictability, specially as journeys progress in games which provide long and open experiences. This is not necessarily a bad thing, and a little bit of unbalance is not always harmless since it allows the players to find strategies and challenges within the game.

 

Ananias on IndieGala’s Hump Day Bundle

Ananias has been included on IndieGala’s hump day bundle #36 which runs until April 12! If you still don’t have Ananias it’s your chance to get it along with a mix of other nive interesting Indie games you can play on Steam. Click here for more info.

Even if you already have the game, I recommend you check the bundle and get it if you want, some nice games there 🙂

indiegala

Ananias2600? – Setting up a simple Atari 2600 dev environment on 2017

So, I got my retro gaming setup at the office, and a friend suggested if I was porting Ananias to the Atari 2600. I promptly replied I had no time for such thing.

Atari 2600 at work

But then, the project picker spoke. And the project picker is wise and fair, and we must obey his bidding.

I started following the instructions here, but they are super old and mostly for windowzer, so I had to dig around a little bit. Here are some instructions which can be helpful if you want to start your career on Atari 2600 game development (who knows, may be Atari will hire you…)

Before proceeding I should mention that this is just one shortcut for real hardcore Atari 2600 development. It’s definitively not the most optimal way to create your games (in terms of resources handling and exploiting the limited power of the device), but it’s enough to give you a sample on what it entails (then you’ll jump ahead and become an elite ASM coder).

Install dasm

The assembler takes ASM source code and transforms it into BIN files which can be read by an emulator or loaded into a cartridge and a real Atari 2600.

For mac it’s available via homebrew so just…

 brew install dasm

Get an emulator or something to test the games

You need to run the games, right? Stella works perfectly for starters if you can’t afford to get a Harmony cartridge or you don’t have an Atari 2600. Once your game is gold, you can have AtariAge create a custom cartridge for you.

Get a working build of Batari Basic for your modern OS.

That one was tricky to find, I got mine from here and it works perfect on macOS Sierra.

Run the install_ux.sh script, note that PATH modification may fail for some reason on macOS so you may need to fix it manually (since the script is meant for linux).

Verify your build pipeline

Use the batariBasic compiler with one of the included samples (say ../2600basic.sh zombie_chase.bas) it will generate .asm and .bin files

Open the .bin file on Stella

Mess around a bit

Take one of the .BAS examples and try to understand what the heck is going on. Move things around, recompile and check


That’s just the beginning

batariBasic makes things much simpler than doing straight assembler, but that doesn’t mean it’s going to be a walk in the park. There’s some reference material online and even a very handy tutorial for the kernel included with bB which is what simplifies development so much. The other great challenge is working with the limitations of the 2600 which is actually what makes it fun:

[…] As if all this weren’t enough, the VCS could only display five interactive objects at any one time: two “player” sprites, two “missile” sprites, and one “ball.” This was more than enough for replicating Pong and Tank, the popular arcade games of 1977. It was useless for anything even slightly more complicated, such as Space Invaders.

Of course, software developers later found tricks to overcome these limitations allowing the machine to do things it was never meant to be able to do, but my goal will be to work within the original constraints without pushing it too much.