Demo Eysir: Return of the Dungeon Emperor (80's style CRPG) [+Devlog]

[nacho_chicken]

I've been bedridden the past couple of days and thus unable to use my computer, but now that I can I want to talk a bit about customization and settings. First, a brief story. I promise it's related to the rest of this post.

I bought a game on Steam, and it looked right up my alley. Fast-paced action with deep mechanics. However, there was a major issue. The game ran far too fast. Everything was in hyper-speed. Movement, timers, gravity, everything. Upon looking it up, I discovered it was due to the game tying logic to the display's refresh rate. The settings menu was barebones, with no options for refresh rate. I could forgive it if this was an older game and the dev was several projects beyond it, but this was their only product and they were otherwise still supporting it. In support forums, the dev would dismiss complaints about this issue with the response "just change your display's refresh rate". To me, that was a slap in the face. I understand untying a game's logic from framerate on a finished product can be more trouble than it's worth, but not even putting in the minimal effort it would take to cap the framerate? Unacceptable, especially when you're charging good money for your game.

It was that experience that steeled my resolve to support players being able to play my game hassle-free regardless of their setup. To accommodate this, I've made plenty of display options available for the end-user to modify. Support for things like:

• Fullscreen mode w/ stretching options (Fullscreen, Aspect ratio matching, Integer scaling)
  
• Arbitrary resolutions and aspect ratios that are not 16:9
• Framerate selection (game logic is separated from framerate)
• High quality text font, for any who may have issues reading the default 4x8 font
  
• Vsync toggle

If you want to mess with some of these things, most of them are already functional in the latest demo release (Alpha 0.1) inside "SETTINGS.INI". With the help of others' fine work writing extensions, I also hope to add borderless windowed support in the future. Whether you have a beaten-up old laptop or a top-of-the-line gaming PC, you will be able to benefit from the breadth of options available.

 

[AegisNinja]

This looks awesome! Good to see people making rpg's like this again.

 

[busterwbond]

great art and aesthetic!
rlly wanna try this

 

[nacho_chicken]

@busterwbond Thank you for the kind words. Hopefully I'm able to get the battle system done soon. I'm sure you'll enjoy the next demo!

After getting (mostly) over my previously mentioned slump, I've gotten some work done on the battle system, by figuring out the best way to load data. Just now, I've finished a script to load enemy stats into memory. I wanted something I could edit easily inside my preferred text editor, notepad++. I decided on JSON, for its flexibility, readability, and because GM has functions for it already. I did a bit of research to learn syntax, did a lot of experimenting with how GM deals with JSON, and out popped something I'm pretty proud of! Here's the process of adding a new simple enemy.

//In "enemyDataInit()":
{
  enum enemy {
    dummy //ADD THIS
  }
}

//In "enemy_data.json":
{
  "dummy": { //ADD THESE
    "name": "DUMMY",
    "namePlural": "DUMMIES",
    "xp": 5,
    "money": 3,
    "hp": 30,
    "ac": 10,
  },
}

Yes, that's really all there is to it. This works because there's a huge "base" enemy stat map in the JSON file that holds default values for every stat. If something doesn't need to be changed, it just takes values from the default. This saves a LOT of space because most enemies don't do things like exude an aura of destruction from their bodies or cause instant death with standard attacks. This means I can set the default values to 0 and ignore anything that doesn't need changing. I'm still hard-coding things like correct enemy sprites and specific enemy flavor text in scripts because they're easier to do that way. Even so, this simple method of dealing with enemy stat data will reduce time spent needlessly fiddling with code by a significant amount.

 

[nacho_chicken]

Battle Screen & Cheating

Recently, I began work on the battle system proper. It took a couple of days to get to the design I think suited the game best, graphically. My first idea was to have a separate isometric battlefield. It was to look similar to the combat screen from Ogre Battle: March of the Black Queen.

Combat screen from Ogre Battle vs. my first battle screen concept​

Player units are displayed on the lower 3x5 section, and enemies on the upper 5x5 section. You'll note the use of placeholder sprites, as this never got to the point in development where I needed to draw enemy/player sprites. I have next to zero experience working with isometric graphics, so I wouldn't be comfortable with all the sprites I'd need to make - especially at such a relatively low resolution for isometric graphics. To illustrate, the size of the character/enemy sprites in Eysir would have to be about as small as the unit icons in the menus from that Ogre Battle screenshot. I eventually settled with a style more typical to the genre I'm working in, and consistent with established visual cues: First Person.

The current battle screen​

This type of display comes with a few caveats. There's a maximum of 4 different groups of enemies in any given battle solely due to screen real estate. 2 groups in the front, and 2 groups in the back. Enemies in the back row appear to be one space ahead of where you're facing, so the maximum groups available while you're facing a wall without the game looking buggy is 2. This actually benefits the game's "realism" a little because I can't stuff an unrealistic amount of enemies in a 1x1 room.

This brings me to my second point of conversation.

Up until this point, I have been extremely strict about use of color. As a general rule, the game display is divided into 8x8 tiles, and any given tile can contain no more than 4 colors including black. Transparency is not allowed. I decided to cheat and loosen these rules for enemy sprites. As is fairly obvious from the above screenshot, enemy sprites have transparent portions. If I didn't allow transparency, I feel it would take away significantly from the graphical presentation. There are also some spots where more than 4 colors are used. This is mostly because I'm reusing an old sprite of mine that didn't have these limits, but if I feel that a sprite will be significantly enhanced visually by breaking the rules, I'm going to do it. I'll only go so far, though. I still have an aesthetic I want to uphold. I plan on sticking to my rules as much as possible.

 

[nacho_chicken]

Hey everyone! Not much interesting to talk about at the moment, but things are getting done. Work on the battle system is progressing smoother than expected. Should be done by next week. Here's a screenshot of my current progress:

One thing you'll likely notice is the new UI. Since I'm sure you care enough about it that you noticed that first and not the bright red debug enemy sprites: no, I'm not changing the way the default menu "square pipes" UI looks. Rather, I'm giving users the option to pick a style from one of several options that are available! If you've played any 2nd generation Pokemon games, it's exactly like the "Frame" options there. I think some newer ones had the option to change styles, but 2nd and maybe 3rd gen changed the entire look of the menus while future games just changed colors. Anyway, no more Pokemon. Back to my game.

Another thing you'll notice is the cursor selecting an enemy. Normally, I'd have the option to select an attack, then you'd select an enemy using a number key. I am making a tiny concession here in order to make any future possible ports to consoles easier. You're also able to select a target and then hit attack. Since "attack" will be a common option, I think things flow far smoother this way. Each option is also mapped to a separate key, as is standard throughout the rest of the game. However, when I port to consoles or if I implement gamepad support, each option will remain mapped to its own button, keeping the game just as simple. Before seeing how Persona 5 handled menuing, I didn't think there was much more you could improve on menus in a turn-based RPG controlled without a keyboard. I hope more RPGs begin to handle controls like this in the future.

Maybe I shouldn't have put this screenshot of a fantastic-looking modern 3D game next to my lowly 2D one​

Next I'll be working on some attack animations and accuracy/damage scripts. See you next time!

 

[nacho_chicken]

Hello everyone!

I've been very busy recently with things in real life, so I haven't had much time to work on Eysir. I have put some work into the optional HQ 8x16 font. It looks pretty good so far. It's not completely done or fully implemented yet, but I like it a lot so far. It's a very clean, thin, sans-serif font.



The reason I'm putting this much work into this is because I know I'll get plenty of people down the line complaining about my 4x8 font. It doesn't hurt to fix it before it's a real problem. It'll also make it easier to add other languages if I ever decide to do that in the future -- especially those with more complex glyphs.

I probably won't be able to update for the next couple of weeks, but hopefully life has settled down a bit by then. Until next time, stay cool!

 

[nacho_chicken]

Good news: I'm back to major development! I really needed a break. I'm currently chipping away at the battle system. Attack animations are implemented. I must admit, I'm a terrible animator. Any battle animations I'll show will be placeholder unless I specifically mention it. I've got accuracy checking, damage calculation, and animation handling scripts all in place! Here's what it looks like at the moment:

Placeholders make substantial work fast​

During the break, I've been thinking about what kinds of things I've talked about previously are feasible. I do still want substantial subquests with varying results, but I doubt they will be as extensive as I may have made them out to be in the past. In-game-calendar exclusive content will also likely be kept to a minimum, as it'll be pretty tough to account for balance. Despite my overreaching by promising things that are beyond my capabilities, I'm still working hard to deliver a great game!

 

[nacho_chicken]

Hi all! First update in a while. Eysir has not been abandoned. Work on the game engine itself is very slow. Typing a lot hurts my hands so my wpm has slowed significantly. The good news there being that I haven't really been focusing on the programming side of things. More so on the story, map design, and polishing underlying game mechanics. Quite frankly, talking about specifics in game mechanics is probably very boring for most of you, so that leaves story and map design to talk about. Those are things I'd rather keep under wraps until the game is done. With that out of the way, that leaves me flat out of things to leave updates about.

As much as I hate to admit it, it's looking less and less like I'll be able to finish this game completely on my own. I'll probably end up having to team up with or hire someone to do coding for menus, the battle system, and the like. For some reason, those things in particular give me a lot of issues programming for them.

I hope to make a few updates in the near future that are less bleak and depressing.

 

[Geoff Jones]

I had a quick play of the demo. The first thing I noticed was that I can't hold the move button down to move, and have to keep tapping it each step... that becomes really tedious after a while.

It's obviously lacking in content at the moment, but the game has a very nice feel to it.

 

[nacho_chicken]

I had a quick play of the demo. The first thing I noticed was that I can't hold the move button down to move, and have to keep tapping it each step... that becomes really tedious after a while.

It's obviously lacking in content at the moment, but the game has a very nice feel to it.

Thank you very much for your feedback! The good news is that I've already fixed that button holding problem a while back. The demo is a bit outdated, but I've not added enough new playable content for me to consider releasing a new demo.

 

[nacho_chicken]

I said something the other day about game mechanics being boring to read about, but I'm going to share the more interesting bits anyway. I'm sure someone will appreciate it. This might even be useful to someone else making their game!

Weapons in Eysir each belong to a specific category with unique strengths. The difference between a Sword and a Gun is more than just attack power and effective range; you also have to consider much more than that. Weapon type will affect aspects such as:

- Damage type
Each weapon will do either Cutting, Stabbing, or Bashing damage. Certain enemies resist specific damage types.

- Attack speed
Something small like a dagger is going to let you attack a lot more often than a giant club.

- Weapon handedness
Weapons like Polearms require two hands to wield and therefore require foregoing the use of a shield.

- Unique abilities
I had a lot of fun coming up with these. Daggers and Thrusting Swords let you Parry, increasing your defense even more while also letting you act sooner afterwards. Hammers can flinch enemies, delaying their attacks. Axes ignore Defending and Parrying enemies. Firearms generally ignore elemental defense.

I also hope to balance out weapons so you're not constantly throwing out old gear for new, 100% statistically better equipment. I would like for as many combinations of party and equipment composition to be viable as possible. Differentiating weapon types to such an extreme degree won't necessarily make in-combat decisions more complicated, but it should make preparation and gearing up more interesting and involved.

 

[nacho_chicken]

A while back, I talked about an optional HQ font. Well, now it's complete! I've hand-crafted an entire 8x16 font -- that's 2x the resolution -- with every character available in code page 437. If you play Dwarf Fortress, you may recognize code page 437 as the default tileset. As that game is very text-based, I often use it to test how legible my fonts are. As it turns out, the font is very nice, and even though it's monospaced, I feel I got the spacing of glyphs like i and l to look good despite that.

Default vs HQ font comparison​

Unless I get a ton of feedback about the original 4x8 font, I'm not going to make the HQ font the default. While it does look very nice™, it also throws off the authenticity of the pixel art a bit. Indie games having pixels be 2 completely different sizes always looked a bit tacky to me. It feels like the artist went with 8-bit because of lack of artistic ability rather than having an aesthetic and trying to adhere to it.

 

[DirectShift]

Yessss, working on the font is so much fun. Did you enjoy it?

What tool did you use? I used online bitfontmaker2, pretty cool.

Keep on it!

 

[nacho_chicken]

Yessss, working on the font is so much fun. Did you enjoy it?

What tool did you use? I used online bitfontmaker2, pretty cool.

Keep on it!

Thanks! Yes, I love working on fonts. It's actually one of my favorite parts of my game projects. I use Paint.NET for all my fonts. No special font program, I just make a spritesheet and load it into GM. One sprite_add_font later and it's ready to go.

 

[nacho_chicken]

I didn't like the old look of the overworld mountain tile so I redid it. Here's a screenshot!

You can see it on the left
​

The old one was far too bright and looked too similar to the tree tile. This looks better, especially with the FOV-blocking qualities of mountain tiles. I also did work on some autotile graphics.

The squirming fleshy fibers look delightfully disgusting​

This turned out absolutely fantastic. Any time you see this in-game, you're in for a rough time.

​

 

[nacho_chicken]

So over the past week and a half or so, I've been cleaning up all the menu code (which is about 90% of the code so far). The old menu and input handling code was such a mess that doing anything with it took 10x as long as it should have. While I was at it I decided to make a few changes to the game's scope; mostly to make it easier on my health.

• Story is basically out the window for now. It's a straight-up no-frills dungeon crawler. The primary reasoning behind this (and most of the decisions on this list) is less typing = better.
• Overworld is gone, at least for now. I still have plans to use it in the future, though.
• Trying to limit use of the word "Force" because Star Wars. It wasn't even a Star Wars reference, it was supposed to be a subtle nod to Phantasy Star and its very "consistent" translation of the name of its primary antagonist. Now it's a blatant reference to Phantasy Star because I renamed it to "Technique".
• Max party size is 6. This makes handling front and rear lines easier. Also, 6-character parties are cool.
  
• Interface is totally overhauled. All menus are controlled by the arrow keys. While I do like my keyboard-only controlled CRPGs, I think it'd be easier to find a needle in a haystack than to find gamers nowadays who prefer typing "F" -> "1" to selecting "Fight" -> "Bubbly Slime" from a cursor-based menu. This also has a nice bonus of being easier to program, since a very large portion of the code is reusable between menus. I would love to have the option of both, but I just can't justify the amount of typing it would take for me to essentially do the interface for every single menu twice.
  
• GUI is greatly enhanced. Working resolution is now 640x360, giving me more space to breathe. The old 4x8 font has been fully replaced with a brand-new 8x16 font, this time not designed by me. Still going with a 16-color DOS-esque palette, though.
  
• Combat is classic turn based as opposed to the hybrid psuedo-ATB it was previously. In its place, there's an initiative meter that gives you a general idea of what order everyone in your party will act in.

Here are some screenshots:

Please ignore the temporary location names

Yes, that is THAC0​

 

[nacho_chicken]

Working on getting the dungeon graphics scaled up. Should be done tomorrow, since all the code is basically done.

Wireframes, ahoy!
​

This time you get a full-screen dungeon display! If you'd like, you can also have the party status screen drawn on top of it. The graphics are so primitive primarily because texturing the walls takes more effort than it's worth for me right now. The wireframe dungeons are going to be the first thing gone once I'm able to get a decent artist, though.

 

[nacho_chicken]

I spent basically all of yesterday wondering why the heck the dungeon wasn't rendering properly. To be honest, I don't even remember what the issue was. Doesn't matter though; it works.

Today I decided to pull the trigger and add an automap for the "casuals" who don't have reams of graph paper just lying around. It's fully functional, but isn't polished yet.

Only tiles you have walked on will be revealed
​

The good news is it was done fast and so I added quite a few new features to the dungeon engine! One-way doors are in. That wouldn't have been so hard if I didn't spend like 3 hours debugging a stupid mistake. Also got wrapping around the dungeon done. That doesn't seem like too difficult of a thing, except now I'm having to treat walls on the opposite side of the map like they're right in front of you. Works great, though. I remembered GMS2 added the ternary operator while I was working on it, so now the wrapping code is full of trash like this

playerX = (playerX >= dungeonW) ? 0 : ((playerX < 0) ? dungeonW-1 : playerX);

I mean, the look of it bothers me less than nested if statements so of course I'm gonna do it.

I might add an Etrian Odyssey-style in-game map editor at some point, but that's pretty far down on the priority list.

 

[BlackCoatDalov]

This is looking great! I love the art style, and it seems like you're hitting your CRPG style with...well, style! I can't wait to see where this goes!

 

[nacho_chicken]

@BlackCoatDalov Thank you very much! I look forward to letting everyone be able to play it.

Rewrote the map editor. The old one was written in GMS1 which was being awful about letting me change the game framerate. It kept capping at 50FPS for some reason. It was a pretty simple transfer to GMS2. Not much code needed to be changed. I took the time to add some graphical themes, like graph paper and parchment. Here's a screenshot of it:

​

It's not quite finished; I want to be able to add events/special tiles through this editor.

Also added a dithering-based fadeout/fadein effect. It's not worth making a GIF for, so until I put enough together to get out a new video, enjoy this screenshot:

 

[nacho_chicken]

Got done re-implementing the party system and added a bunch of other stuff I can't really post about here because they're all menus and it's very same-y. Took the time to add multiple-party support. You can have up to 6* different parties out adventuring at the same time! Here's a screenshot of the party setup menu.
*Number subject to change

aaaaa
​

The maximum amount of characters you can create at one time is 50, so I added a scrollbar for clarity.

 

[nacho_chicken]

Got tons of stuff done on the map editor. Added support for things that aren't walls. This is going to be the main debug map I'm using:

Once every kind of special tile on this map functions properly in-game, I'll be basically done with programming for the dungeon portion of the game.

...which is about 50% of the game. Crazy how things are shaping up!
Map files are relatively small. A reasonably-packed 16x16 map like the one above is about 600 bytes. It could potentially be reduced much further - but if I want to keep it easy to work with, it'll have to stay as is. No sense in any further compression, anyway.

 

[nacho_chicken]

Progress over the past couple of days:

• Spinner tiles completed
• Conveyor tiles (force player to move in a particular direction) completed
• Pitch-black darkness areas completed

Also, a slightly modified player status UI!

I named this font "Commode 32" because I am both creative and mature​

I felt like it needed to be smaller since in its original size, it took up an excessively large portion of the screen when in dungeons. This made it rather uncomfortable to look at. The new font there is one I made and it's based off of the default Commodore 64 font. It gives the game a bit more character than the font that was previously there.

 

[nacho_chicken]

Teleporter tiles have been added. At first I wasn't the happiest with how it was programmed, but it's not the biggest mess ever and it's done so I never have to worry about it again. Actually stepping through the teleporter wasn't an issue; it probably took me 30 minutes to add. The hard part was being able to look through them. Here's a screenshot of what I'm talking about:

Teleporters will project walls around the exit to the entrance
​

It's very difficult to tell when you're looking at a teleporter. You usually can't even tell you walked through one until it's too late. This "projection" of walls increases the wall check code by several hundred lines of code. The way I previously handled drawing walls is as follows:

1. Check for wall data in all possible positions and return it into an array
2. Draw walls to a surface, in order of furthest-to-nearest to create "depth"
3. Draw surface to another surface (this is for the turning animation)
4. Draw second surface to screen

With dark zones and being able to see through teleporters,

1. Check for teleporter location
2. Based on how close teleporter is to the player, set certain walls as being viewed through a teleporter
3. Set wall offset location of teleporter exit
4. Check for wall data in all possible positions (any walls through teleporters are offset by location in 3) and return it into an array
5. Check for dark zone location
6. Any empty walls are now "darkness" walls
7. Draw walls to a surface
8. Draw surface to another surface
9. Draw second surface to screen

And don't worry: despite all the disorienting traps, I'm not going to be too sadistic with the map design

 

[nacho_chicken]

Finished up textboxes! Doesn't sound like a lot but it's based off of my Textbox Engine v6. I'm real proud of that one. It eventually got used in at least one high-profile game.

I love random test dialogue
​

Switched up the dialogue font as well. This one feels a bit less whimsical, which fits the tone of the game better. All this textbox stuff was sort of a side-track from the dungeon portion since dungeon features like stairs, events, and elevators all require the textbox in some form. Progress is palpable!

 

[nacho_chicken]

Added inventory and equipment systems. Originally, it was a straight port of the previous engine's inventory system. However, the way it was set up was... not the best, to say the least. All item properties were in individual scripts. Adding new items was a hassle. I went with a more standard 2D-array-based inventory system with enums. A new item can be added like so:

var _item = item.dummy;
itemAddBasic(_item, itemType.mainWeapon, "Dummy Weapon");
itemAddEquipment(_item);
itemAddWeapon(_item, weaponRange.short, ailment.none);

And any kind of data can be obtained like so:

itemNameString = inventoryItem[item.dummy, itemData.name];

Simple, does what it needs to, and works great. Inventory screen is looking smooth:

Decked out
​

I'm not totally tied to the 80's aesthetic. I went with a more 90's RPG style here with the equipment menu. You have a basic representation of your character and which item is equipped in which slot. Much less boring than a simple text-based inventory screen.

 

[nacho_chicken]

Been writing music for the game for the past few days. Here's one of the dungeon themes:

I've finished writing 3 songs, including the one up there. Will probably do one or two more and then get back to programming.

 

[DirectShift]

Been writing music for the game for the past few days. Here's one of the dungeon themes:

I've finished writing 3 songs, including the one up there. Will probably do one or two more and then get back to programming.

aw, always nice to hear other people music =)

loving the map thingies

 

[nacho_chicken]

Some of you may be wondering what's been going on with this project, and the answer is that I've been working on it the entire time. I've mostly stopped doing minor updates (E.G. "What I did today") since it doesn't look like they do much. Been saving that kind of stuff for Twitter.

Be sure to follow me at @nacho_chicken for more frequent updates!

One thing I do want to talk about here is the main draw of the game. The question everybody will ask is "why would I want to play this instead of [x]," where X is Ultima, Wizardry, Might and Magic, etc. The fact that it's a throwback RPG isn't really enough to be a draw of it's own. So I'm cannibalizing a past idea for a game into this one to create something truly unique:

The whole game takes place in one city.

Most RPGs have an overworld with many towns, villages, and dungeons to explore; Eysir will have a huge, sprawling city with many abandoned houses, buildings, and locations to explore. Places like hospitals and an industrial machinery yard are dungeons seamlessly integrated into the game world. This also helps make the story a bit unique since there doesn't need to be a cataclysmic, world-altering event occurring to justify a globe-trotting adventure. I hope to bring something interesting to the table with this!

 

[nacho_chicken]

New graphical update!

This was a result from myself making a choice between what I could prioritize. I don't think I would be able to handle doing so much pixel art texture work for such a high resolution. I had to decide: Higher resolution walls vs. textured walls. I ended up reducing the resolution of the dungeon display by a fair amount. The result, I think, is something the average gamer would find much more pleasant to look at.

 

[Joe Ellis]

It seems weird how you've managed to not make it look pixelated as fook. Whatever you've done is certainly very cool and eye pleasing

 

[nacho_chicken]

It seems weird how you've managed to not make it look pixelated as fook. Whatever you've done is certainly very cool and eye pleasing

Thanks! I'm very surprised it turned out looking as good as it did considering the dungeon display is at a resolution of 160x90.

 

[Joe Ellis]

Thanks! I'm very surprised it turned out looking as good as it did considering the dungeon display is at a resolution of 160x90.

It's like a graphical gem!
I like how the floorboard nails show up so well

 

[Zizka]

I find this very interesting. Maybe a few icons here and there in the menus to diversify from the text?

Seeing A.C. and the game in general reminds me of ad&d games of old like eyes of the beholder. It looks like a very vast project however. Maybe only do dungeon crawl like Eye of the Beholder would make the scope less daring?

Either way, looks interesting!

 

[nacho_chicken]

I find this very interesting. Maybe a few icons here and there in the menus to diversify from the text?

Seeing A.C. and the game in general reminds me of ad&d games of old like eyes of the beholder. It looks like a very vast project however. Maybe only do dungeon crawl like Eye of the Beholder would make the scope less daring?

Either way, looks interesting!

Thank you for taking a look at my project! I'm actually going through a bit of a rework at the moment, and replacing a lot of menu text with icons is a huge part of that. Yes, the gameplay is greatly inspired by dungeon crawling classics like Wizardry and Ultima, as well as the D&D Gold Box games like Pool of Radiance and Eye of the Beholder! Scope isn't really an issue for me at the moment. It's moreso the fact that I need all the mechanics finished up and laid out before I start working on adding actual content. I've been updating on Twitter far more frequently than here as of late, but most of my work since October has been on the battle system. It's part of that previously mentioned rework. It's changed from a standard turn-based affair to a more tabletop-inspired strategic combat system. Now is as good a time as any to go ahead and share some screenshots: