Paladin’s Quest LCD

20180509_183241

An entry for the LCD Jam, about 8 hours dev.

JavaScript + Phaser as usual for great quickness. Pretty happy with results, nice feedback received, may develop further afterwards.

Play online here (Source code here)

Screen Shot 2018-05-07 at 7.51.39 AM

The game is a simplified dungeon crawler, classic style roguelike, which emulates (loosely) a LCD game display.

There are 4 different enemies: Headless, Floating Skull, and Phantom. Scattered in the dungeon you will find strong weapons and replacements for your shield, you will need these to survive!

Each level is 3×3 rooms, you must find the exit which is located in the middle of one of the 9 rooms.

Screen Shot 2018-05-07 at 7.51.11 AM

The LCD shapes (i.e. the different parts of the paladin) were made by Giovanny Ramirez, the wiggly dungeon room and the “brick game” frame I made myself.

1884 – Golf over Africa, LudumDare 41

The theme for the Ludum Dare 41 was “Combine 2 Incompatible Genres”. I’m pretty familiar with genre mashup, and I accepted Jim Shepard‘s challenge to jump in.

As usual for the LudumDare, I wanted to do something different than what I always do. That usually means doing something more accessible to the casual public, as well as ditching pixel art, and including real-time stuff and animations.

Here’s what I came up with: (Play online!)

golf

1884, the European superpowers have met to decide the future of the African continent… now their leaders face each other in an Open golf tournament to divide the land between themselves!

Screen Shot 2018-04-24 at 7.01.56 PM
Title Screen

I went for a combination of a Golf game with territory based war game (think Crusader Kings / Europa Universalis, or maybe RISK). It’s made for 2 to 4 players who take turns to play, the first country to occupy 10 territories wins the match.

In order to try to occupy a territory, you must land your ball on it, every turn the player decides the direction and power of his shot. The outcome depends on the stats of his country.

You can also invade other player’s territories, where the success of the invasion depends on the Military stat of each country. Countries also have other 2 stats: Logistics affects how far your shots will fly (with Great Britain being the best on this) and Leadership affects how accurate your shots are.

Game Screenshot
In-Game

Since I knew in advance my time would be extremely limited during the span of the compo, I went for my usual toolkit: Phaser2 + ES6. All art was done on GIMP, basically a lot of repetitive work extracting the different countries from a colonial map of Africa, and some flags and UI stuff.

Africa-colonial1
Colonial Africa

Due to the “weird” square and “high” resolution of the game (as in being about 800x800px, high for browser games standards) ended up doing a lot of work to make sure it would display fine on browsers with a smaller window height (you’d be surprised this is still very common in 2018) as well as the fancy retina displays which always mess up with scaling calculations.

This one went from ideation to fully complete product in less than 12 hours. I’m really happy how it turned out. Here are some areas where this could be expanded in case I work back on it ion the future:

  • Adding a “zoomed” version of the territory the player is doing his shot from. And an animation of the country leader shooting-
  • Making the viewport landscape and adding scrolling (and maybe a scaled map)
  • Enhancing the appearance in general.

Rogue Program – Github GameOff

(I must have posted this some weeks ago, but I’ve been a bit busy!)

Some months ago, a conversation on twitter inspired me to make a game inside a character based UI from the 80’s…. for some reason.

twitterChallenge

I decided to go ahead and try to implement the idea as an entry for the Github Game Off, whose theme for this year was “retro” (very fitting). Since github provided the location for the Roguelike Celebration (and was publicizing the jam at the event), I felt more encouraged to participate.

TitleScreen

In Rogue Program, you are a character living inside the Alameda Video Rental System. The Rogue Program has activated and is turning the characters of the system into vicious monsters. Adventure through the different modules and menus of the system looking for clues and tools, while learning what has happened to the outside world.

rp1

I went for a P1 phosphor green monochrome 80×25 CP437 characters appearance, using a fixedsys font and unicodetiles.js. I used my JSRL boilerplate as a foundation but despite looking as a traditional roguelike, the game is more of a simple cRPG with fixed locations and plot (REXPaint by GridSageGames was a hugely helpful tool to draw the maps). I think however that it should provide a fun time and a decent challenge.

rogueProgram

Source code is available at Github. Play now at itch.io and don’t forget to report thy feat if you manage to win 🙂

JSRL – JavaScript boilerplate roguelike released

Well, I decided to release this based on my work this year on Monster Trainer Roguelike; one of my first mistakes was spending time during the 7DRL to build a simple generic roguelike engine as a basis for the game… the question is, I never released it in such simple form! I decided to release it as I think it may be helpful for devs to use as a starting point for their roguelike or character based games!

It’s now in github at https://github.com/slashman/jsrl, you can also check the online demo here

If you are curious what kind of games can be created from it, check Monster Trainer Roguelike

boiler3

What is this about

A very bare bones roguelike with a character based display

Features

  • Player can walk around
  • Raycasting Field of View algorithm
  • Player can move between persistent levels
  • Enemies move around chasing the player
  • Player can pick up, drop and use items (including using items on a given direction)
  • Player remembers visited maps
  • A simple Being class based on Races definitions, with “random” and “follow player” intents
  • A simple Item class based on Item Type definitions
  • Infrastructure for Level Generation
  • Line wrap text boxes

How to use

  • Clone the repo
  • Delete .git
  • Create awesoem gaem

Credits

Uses unicodetiles for IO – http://tapiov.net/unicodetiles.js/

OpenArthurianX6 dev update

Forgot to post here about the latest development of OpenArthurian which actually happened around a month ago 🙂

After that first dev stream I mentioned on the last entry, I did 5 more

Combat is almost done now, pending only adding some projectile effects for ranged combat. Next up is working on level transitions and the chunked world model.

Exodus Destiny also did some work on the game, finishing a first iteration of the Talk module as well as the Pick up / Drop functions (along with the Inventory)

Unfortunately I won’t be able to work a lot in the project for the next couple of weeks since I’ll be flying to San Francisco for the Roguelike Celebration and there’s another private game dev project I’m working on, but I’ll come back strong after that, I promise!

OpenArthurianX6 – Dev news

After all the craze that was 2017 js13k, I went back to my duties with OpenArthurianX6.

So far I’ve been working on the combat system mostly. The game features an hybrid action mode, the “mobs” move around the grid based map, deciding what to do every x millisecond (at first restricted to moving around or sitting idle). First task I took was allowing the transition to combat mode, in which the mobs take turns to act.

To achieve this, I added a synchronization phase where all mobs finish their moves before the actual combat state is established.

Next up was adding the “attack” action, but in order to make it work, a major refactor on how the actions flowed was done. Everything was changed to use promises instead of timers. This will allow to more easily add other actions in the future as well as parallel input modes (keyboard/mouse)

Also implemented some damage calculations based roughly on Ultima 6, and added the corpses to the ground when killed.

Finally, added some simple AI for mobs to seek enemies based on their alignment, for now they just seek the player and attack him. The actual attack action was pretty straightforward to implement for the mobs since they are the same as the player 🙂

I streamed the development of this latter part, you can check it in Slashware’s youtube channel here!

Lost in Asterion – js13k 2017 – v0.2 released – final compo update

This is the final update of the development of Lost in Asterion for the 2017 js13kgames contest. I managed to create an interesting exploration game, and I’m pretty happy with the results (check it out here). Giovanny Ramirez created a cover art for it and it’s amazing

Following is the journey thru the last 10 days of development. You can see the previous days here and here.

lostInAsterion2

September 2 – Added enemy support with a single kind of enemy.

Enemies (actually, general “entities”) are updated once on each iteration of the game loop, they have their speed affected by gravity, are checked vs collisions with the world objects (in which case they are completely halted).

Enemies have a simple AI where they check if player is close enough. If that’s so they’ll calculate the direction to the player (in simple manhattan terms, not degrees) and then propel towards the player using they acceleration in x and y.

They are also drawn on each iteration of the game loop, scaling simple geometrical operations based on their size, around a central point.

September 3

Attack enemies using bubble beams: Every time the player presses ‘z’, a bubble beam is created in the direction he is facing. The bubble beam is a group of bubble created in sequence within milliseconds between each one, all originating from the same spot and in the same direction (with slightly different speed).

On each update cycle, entities are checked for collisions with these bubbles, in which case their health is diminished and they are drawn in white for some millis to show they have been hit.

Added sound effects using the jsfxr library. At this point I wasn’t still worried about size. I just added it and used it for movement. The way it works is providing the library with a set of parameters mirroring the configuration of the asfxr player, and they are played using the web audio API.

Also added support for plot messages tied to positions within the world fragments

September 4: Designed and added more plot. Designed the overall world map too.

September 6: After wondering how I’d tackle some variety on the maps, I decided to try to generate then procedurally with a simple “rogue” like 9 interconnected rooms algorithm.

The way it works is a random size is defined for each of these rooms, and some of them may be discarded. Connections are then defined, and then it’s drawn.

While it’s a simple generator, in the middle of implementation I noticed: a.) it was taking too much time to implement, b.) it was eating quite a bit of source code and c.) it wasn’t really worth implementing it since I wanted to have fixed maps in the end (I intended to seed the map generators)

So, I discarded the initial idea and went instead for something completely different. I rendered the maps in a spreadsheet and encoded them as bytes. The map is represented as a bitmask of open/closed spaces, I chunked it in 8 spaces long fragments, and encoded them as an hexadecimal byte representation.

Screen Shot 2017-09-16 at 4.29.19 PM

This allowed me to represent a 24 spaces segment in 6 bytes. The full map for the first temple section, which is 18×24 sectors big, is represented by this string: FFEFFF398FC1018781011C800185C1458DEFFFFDEFFF8187FFE184000084000080FF0184FF0184FF01ECFF03EEFFFF87FF0780FF87FF

When the map generator is creating a fixed map sector, it decodes the String into a boolean mask, and generated solid blocks based on the desired scale.

I used this technique to create the map for the Temple.

September 7

I had a corporate leadership training during the morning. I designed some creatures while waiting for it to develop. All of them using basic shapes.

I was running out of time and the world was not yet ready, so I focused on trying to complete it.

I added some sections requiring the player to have a given orb to pass thru, else player’s speed was drastically affected. This acted as a simple “plot device”, making players have to transverse the map in 3 different “segments”, giving the player a sense of non-linearity while still having some strict control of the game flow.

Added more world content by configuring the map generator for Volcanic Rift (simply using fiery colors for the background) and creating another fixed map for the City Ruins (thus capitalizing on the code added to handle it on the temple ruins).

Having the world definition in a good shape, I continued by adding enemies generation on demand. As the player moves around a sector enemies will be constantly generated off screen up to a given limit.

Finally, I added Game Over flow, the game loop will check if player is dead and render a different screen instead.

September 8

One remaining piece to make the game playable was having a better victory condition, so I worked on adding an end boss. Also started working on support for different kind of enemies.

September 9: Rendered different creatures types based on the designs I had made. Used simple canvas 2d content drawing directives such as fillArc, as well as paths being stroked and filled.

September 10: Assigned enemy level / difficulty based on sector (harder ones as the player progresses).

Also made some missing powerups work: Made the bubble beam work only if the player had the Orb of Verra Kera, and hull recovery only happening if he had the Orb of Gabrielle.

Also added the “title screen” of sorts, and continued polishing the “plot”.

September 11 – Begun the quest to reduce space. Started by questioning myself whether I wanted to keep (and may be even extend) the plot and content OR if I’d rather work towards keeping sound support. I decided for the latter. Started having 2.76 KB of compressed code to take away.

This was extremely painful, some of the things I did were:

  • Ditched the original minified version of the Voronoi library. Instead included the original source code into the minification flow, and removed some parts which were not being used.
  • Move code into data, placing redundant code sections into methods executing batches of operation based on arrays of parameters.
  • Change formatting of definition of function prototypes using Class.prototype = { fn: {} } instead of Class.prototype.fn = function(){}. *
  • Replace all const with var*
  • Reduce HTML infrastructure to a bare minimum, no css nor styles, very plain index.html with no HEAD section or encoding declaration, etc.
  • Remove “use strict” from all modules
  • Shorten plot and ending messages.
  • Move “private” functions outside the functions prototype (effectively allowing uglify to mangle their names)

For the things marked with *, I found of they didn’t really help much in the end since zip compression took care of repeating Strings pretty well. The only thing that helps is actually removing content.

Additionally, I adding the knock back mechanics to make “combat” more interesting (and making the game less hard by allowing player to tackle enemies away). I also added the drill as a default “melee” weapon before acquiring the sonic beam.

September 12 – I was running out of time and hadn’t done proper testing so I released a first version for public testing.

I worked hard to reduce the package size more and more, doing the following:

  • Use the same SFX for the movement fans and for the drill
  • Modularize the Voronoi library. Extracted the different classes used by it on different modules, hoping to refactor them to move private functions from the prototypes into module scope functions. I actually had to roll this back afterwards since the additional module management increased size, but it was helpful to simplify the modules individually and prevent introducing bugs into an unknown code base.
  • Configure uglify to mangle properties starting with underscore (both functions and attributes). This was extremely helpful! I proceeded to use it mainly on the Voronoi library.
  • Cut more plot.
  • Remove unused error message Strings.
  • Ditch the minified jsfxr file and include the already minified source into my own minification process.
  • Merge modules into single files, making the code less readable for now.

Went to bed with 50 bytes left and the plans to finish thru next morning as well as doing some testing…

Then, while already on bed around 1AM, decided to check the deadline and found out it was 13:00 CEST, not Central American Time as I initially thought. That meant it was happening in less than 5 hours. The panic.

There was no way I was going to lose all the time I had invested, so I got up and finished the adventure by completely removing two kind of enemies and cutting the plot text even more.