Setting up all the shit (MinGW-w64 and libtcod)

The original idea was to document all the steps, from deciding which programming language to use, the books I used to learn, the compiler I decided to use, how to set it up, the editor I would use, its own configuration and so on. There’s quite a lot of stuff and it requires quite a bit of time to examine and figure out.

Since I just went through the process of refreshing a few things, I’ll document at least this transition.

The problem I got was that I was looking for a way to convert hex format color codes, like HTML #FFFFFF, converting it to RGB that I need to use to make colors within libtcod (the roguelike library I use to print stuff on screen).

In the end I came up with something like:

This is supposed to work, but in the standard and most up to date version of MinGW it doesn’t:
error: ‘stoi’ is not a member of ‘std’

And if you look it up on the internet you’ll see it’s a bug in the distribution that has been there from YEARS. On top of that, this standard version of MinGW is lagging behind with updates.

So I started looking again for alternatives and found two:

I went with the second that seemed more widely adopted but, honestly, the documentation sucks.

“Mingw-builds Project” and “Win-builds Project” on the sidebar lead to the same page. And on that page you find again both options:
Mingw-builds project
Win-builds project

Both seem to target Windows, so I don’t know the difference. I decided to go with the second option that more explicitly targeted Windows and that looked like based on a more stable version. So I end up on another different site:

The documentation here is worse than sparse. We get a:
“Installation on Windows can be done for MSYS, Cygwin or without them.”

Initially I tried a barebone install, but eventually I found out there was no “make” in this package, and to compile my own game I normally use a basic form of makefile. MSYS instead is a tool that creates a Linux-like shell under Windows. Normally it is not required, unless you want to compile other stuff that makes also use of Linux commands and the like. This is OFTEN the case when you want to compile other games and libraries.

So I knew that MSYS at least included “make”. But the MinGW package here does not include MSYS. If you follow those instructions on that page you get:
for MSYS: run it from the command-line as: yypkg-1.4.0.exe –deploy –host msys

But if you do this, the program asks WHERE you have installed MSYS. So it’s obvious that first you have to install MSYS, then you install this MinGW on top of it. But, go figure, if you install MSYS it will ask you where you have installed MinGW. So read on and lets figure this out.

Since I needed MSYS, I went looking for a standalone MSYS package, and reached this other page:

Have I already mentioned the documentation sucks? Because that page there gives you three package options, the last of which is said to be more inclusive. So you go grab that one, but when you look in the archive you notice there’s no “sh /postinstall/”, which is exactly the command it tells you do execute to configure the program.

So, instead of downloading that third package, I downloaded the middle one. In this case it had the configuration script. BUT the important point here is that you don’t need to execute that configure command at all. So all those three packages will be fine, and you should just choose them depending on what kind of features you want added (if you are a noob like me you’ll probably use none of them, so you could as well go with the first package. Though, as far this guide is concerned, I personally used the 2nd).

Before starting to install stuff I’ll mention that whereas installing MSYS included with standard MinGW puts MSYS within MinGW itself, instead if you go with the option of installing MSYS, then it’s MinGW that goes into MSYS. So you’ll only interact with MinGW through MSYS itself.

Let’s start installing stuff. Since I work in D:/, I’ll install MSYS in D:/msys.

That second package I downloaded comes in just a “”, so I’ll simply unpack it in the directory, making sure that MSYS bin directory becomes d:/msys/bin

At this point you’d normally execute D:/msys/msys.bat opening a Linux/DOS prompt (right click on the window top to set properties as you like, like buffer size, font type and useful QuickEdit mode), so that you could give it the configuration command. But with MinGW-w64 this step should be skipped.

Then I proceed to install MinGW-w64 itself, downloading the package manager from and launching it through the command line/DOS prompt:
yypkg-1.4.0.exe –deploy –host msys

It will ask you to install i686 or x86_64. As far as I know it’s basically 32bit or 64bit. Since I’m on 64 bit I decided to try with 64 by default, and it’s also possible to install both and then switch to the version you want to use through a command given to MSYS. But consider that when I tried to install both, after it finished installing one and started to fetch packages for the other, IT CRASHED. This is not a big deal since you can just relaunch the installer, but it’s a better idea to install 32/64 separately, so running the launcher twice.

After you tell it which version to install, it will ask for MSYS directory, so I give D:/msys which is the root where /bin should be, and press ENTER. Then it will automatically download the packages from the internet and install them.

The whole thing (32+64 bit packages, and MSYS) takes about 1.2Gb on the hard disk.

Now is the time to configure MSYS. Since the package manager seems to install MinGW within MSYS, so that the 32bit and 64bit versions can be freely swapped, there seem to be no need to mess with Windows PATH or MSYS configure scripts.

Instead I used this command (explained here):
echo ‘. /opt/windows_64/bin/win-builds-switch 64’ >> ~/.profile

This essentially switches by default to the 64bit version. Whenever I open msys through the .bat, it will be already set up to work in 64bit toolchain, with all the paths set correctly. If you then type gcc -v it will look up at the right version of gcc it has internally (4.8.2 at this time).

Apparently no other tweak seems needed. I was able to compile my game alright, so the paths should be already set correctly.

In short:
– Install MSYS separately by simply unpacking the archive in a directory you want to use.
– Launch the MinGW package manager through the command: yypkg-1.4.0.exe –deploy –host msys
– Pick either 32bit or 64bit version, or both, and tell it to install into MSYS root directory (where ‘bin’ and other directories are)
– Launch MSYS with the .bat file in its root, and give the command to default to either 32 or 64 version, like: echo ‘. /opt/windows_64/bin/win-builds-switch 64’ >> ~/.profile

Now the problem is that if you want to use 64bit, libtcod library is instead compiled as 32bit version, so if I now try to recompile my game at 64bit it will fail because it says the library is not compatible.

So I went and had to recompile the library itself on 64bit. Yet, this also requires a further step, because the SDL it uses also needs to be in 64bit. Since SDL1 is not available in 64bit, I had to compile it myself. So I downloaded the sources for SDL 1.2.15 (because for some reason SDL2 is INCREDIBLY slow with libtcod), launched through MSYS: configure, and then make.

It compiled alright. Then I only had to move the compiled SDL-1.2.15\build\.libs\libSDL.dll.a to libtcod-svn\dependencies\SDL-1.2.15\lib\mingw

And finally I had to tweak libtcod makefiles, because they use mingw32-gcc and mingw32-g++ that do not exist in this MinGW-w64, so renamed them to just gcc and g++

To compile libtcod I use, from its root: make -f makefiles/makefile-mingw release

Also consider that through my various attempts I was often getting compiler/linker errors. I eventually found out that some data was lingering in C:\Users\username\AppData\Local\Temp\libtcod so make sure the Temp directory is clean if something goes wrong

This should be enough to compile the library fine. The tool to compress the .dll at the end will fail, but the libraries still work well for me.
EDIT: You can obtain here a more recent version of UPX that compresses 64bit files. Just download and move upx.exe to dependencies\upx\win\ in libtcod directory. The makefile will use it automatically, and you can also use it manually to compress SDL dll as well your own game exe, if you want.

So finally, after having both libtcod and SDL compiled in 64bit I could also compile my own game fine. Caveat: it now requires another dll to run: libwinpthread-1.dll, which does not seem to compile statically. So you have to go fish for it in MSYS/MinGW directory and move it to your game dir.

But otherwise it actually runs, and with a nice 8-10% speedup in my case, compared to the usual 32bit version. And std::stoi compiles fine.

Last tweak: D:\msys\etc\profile can be edited so that every time you open msys.bat you are already in the directory you want. At the very bottom there’s a line cd “$HOME”, so I commented that out and edited to what I needed:
cd “D:/foe/foetest”

To update this distribution of MinGW-w64, when new packages are released, go into /msys/opt here there should be one or two directories, for 32 or 64 bits, pick the one you want to update, navigate into, for example, /opt/windows_64/bin and (hopefully) just double click on yypkg.exe it should check the repository for updated stuff and install everything automatically.

Posted in: Uncategorized | Tagged:

Dragon Quest 1

I’ve taken a break from programming activities while also contemplating a possible split. The roguelike game on one side, and a reworked program that I could use simply to draw maps (even to use with old-school games that need mapping). Both of these need a programming component I still have zero knowledge about: how to read/write stuff to a file, so that I can save/reload (including the possibility to draw a dungeon instead of simply generating it randomly). I’ll get to it, eventually.

In the meantime I made a scheme of popular/classic JRPGs. Leaving aside the most recent entries on consoles. All the stuff in the chart can be emulated well on PC, so this is a list done for long-term preservation of these games, even if their respective hardware goes obsolete. The first number is the vote the game has on Gamefaqs (the site with enough votes to make them relevant), the next two numbers represent “hours of gameplay”, giving an idea about how long on average each game requires to complete (goes from main story to main story + some extras), and the last number is the number of votes, useful to consider how popular the game is.

Then I considered the mad plan of playing all Dragon Quest games in their order. I like setting up similar Epic tasks. They can range across all media. Like burning through the Battlestar series (I did this in December) or all five seasons + movies of Babylon 5, reading the whole Solar Cycle by Gene Wolfe, or all the ten Thomas Covenant by Donaldson, or the Dune cycle by Herbert (or Malazan, obviously), play the whole Shin Megami Tensei series across the various titles, read the HUGE, continuous storyline that unified all Marvel comics from 2004 to 2010 (starts with Avengers Disassembled), read the DC-side of Epic task, all the Crisis starting from the first, including all tie-ins (like 52), or reading the Morrison epic long cycle on Batman, play the Amberstar/Ambermoon epic duology of games on the Amiga (or the insane “Fate: Gates of Dawn”), or play World of Xeen, or Wizardry VII on PC, read Infinite Jest or Gravity’s Rainbow, watch all movies by Charlie Kaufman, study the Kabbalah (without spending one dollar), read the Chinese Epics like Three Kingdoms, or the five-volumes set of Dream of the Red Chamber (or the Japanese The Tale of Genji, or the Chinese erotic Jin Ping Mei, also in five volumes), or the historical 14 book cycle by Dorothy Dunnett, watch the critically acclaimed samurai trilogy of movies by Yoji Yamada (The Twilight Samurai, The Hidden Blade, Love and Honor, for a total of 6 hours and 20 minutes), watch or read all Once Piece, read Berserk, Eden, watch all Gundam and Macross series, or all Evangelion, watch all Haruhi Suzumiya in chronological order, learn to play the most hardcore wargames, watch all Kamen Rider series, watch in order the whole mytharc of X-files, or rewatch all Twin Peaks, or watch all Buffy, or Frasier, play/read the Nasuverse (includes Kara No Kyoukai series of seven animated movies), or the Muv-Luv series, or all of Umineko (80+ hours of “reading” on average), or better, first Higurashi and then Umineko, read all Sandman, play the Arkania trilogy of RPGs. And do not think this is even close to a complete list, I just got tired of adding stuff as I remember it.

Or study a programming language from zero and write a roguelike that consolidates 20 years of gaming in one game… All this just to say I enjoy setting up gargantuan, long-term tasks, and that’s way it’s absolutely required that I’m granted more than one life in order to do all I’ve planned. Just a reminder.

So last added to the list is playing these Dragon Quest games in sequence. The first three can be played on a SNES emulator and available in English thanks to some fan translations. The following three (4-5-6) make their own trilogy and re-released on the Nintendo DS, the 7th (probably the longest JRPG in existence) is on Playstation 1, the 8th on the PS2, and the 9th back on DS.

Putting some hours into Dragon Quest 1 has been quite interesting, and rather useful in the perspective of my roguelike. Playing old western RPGs is usually more annoying due to technical problems, glitches and general lack of ease of play, whereas the old JRPGs are technically “flawless” and essentially impossible to improve. The only difference with the modern ones is that their design is “scaled down”. And this makes them extremely interesting because it’s like seeing the building blocks directly. All following generations of JRPGs are simply about dressing up and adding parts.

Dragon Quest 1 plays flawlessly and is at the same time elegant and simplistic. There’s no party, just a single character to manage, you are given a bland mission, exit the first castle made of an handful of rooms, and are already on your own. The basic formula of the game is built as an economic system. Most of the game is played right on the world map, divided into zones, where you fight random encounters while you gravitate around towns. The most important “currency” the economic system is based on is the Hit Points. The more random encounters you go through, the more HPs go down, obviously. If you have Magic Points and an Heal spell then you can restore the HPs, but they are just two layers of the same thing, since sooner or later you’ll be out of MPs as well. The only way to restore both is to sleep at an Inn, and so go back to a village. During the fights on the world map you gain Gold, and with Gold you buy better equipment, pay the Inn, buy health potions. The difficulty and gameplay rises from the tension that is created by the need to be able to backtrack to a village (where you can restock), and the need to explore the world, so reach the next village, or go through a dungeon.

It’s actually extremely easy to find oneself in a bad situation because those random encounters are extremely frequent and in order to reach the places you are meant to reach you have to travel far away from the safety of a town. This means you could frequently realize you’re deep in a dungeon, lost (because dungeons are hard to navigate and the visibility extremely limited) and not likely to be able to backtrack quickly enough to a village. This economic system based on dwindling resources and the need to push further to reach a goal or find a new town instead of going all the way back comprises all gameplay the game offers. In villages you find a number of NPCs you can talk to, but they mostly offer a couple of lines of “flavor text”, or some bland lore, or tips. But you don’t have choices or quests being offered. The story doesn’t go beyond the classic “save the princess, kill the bad guy”. So what remains is going through the virtual tiers, leveling up to increase the HPs and MPs, gain enough gold to improve the equipment, which means being able to travel further away, so entering more dangerous areas that obviously scale along the player’s own progress. Eventually you’ll find a village where you can get special keys that open special doors in some dungeons. This is Dragon Quest 1.

What’s interesting for me is that I could implement all of this, almost an exact copy, with my current programming skills in my roguelike. I could make an exact copy of this game because the mechanics are straightforward and easy to grasp. This is already a skeleton of a game. When it works you have a structure and the rest of the work is about adding detail and depth. Seeing it work as a simple economic system reveals what truly makes the totality of the game. What you play with. The rest is flavor and dressing up.

When you plan and write a roguelike you have millions of ideas and complex things you want to do. But planning this from the top down makes it look utterly IMPOSSIBLE to achieve, and discouraging. Instead if you look at it from the bottom up, then it will be revealed as simple and linear. You need to know where things are coming from, dig in the archaeology of games to understand how things worked, and then you can quickly ascend to reach those places that are in your goals.

I’m only a few hours into Dragon Quest but it was a revelatory and constructive experience. At some point I couldn’t believe what I was seeing on screen:

I mean, finding a girl at a public bath that offers a “puff puff” for 20 gold? I had to search online to confirm my suspicion… And yeah, it’s more or less how it looks. This thankfully preserved by the fan patch, since the original Dragon Warrior games in the west had that dialogue cut. You don’t want kids asking their parents what’s a “puff puff”. I would have missed one famous and recurring gag of the Dragon Quest games ;)

By the way, I choose “Yes”. I got a puff puff, and wasted my 20 gold. Then I did it again.

Posted in: Uncategorized | Tagged:

(Mis)adventures in roguelike development: why old-school RPG rules

I’ll briefly explain here why the roguelikes are the occasion for the renaissance of old-school pen&paper ruleset. Why I believe this match is perfect.

The fact is that with the latest generation of games we moved toward the “analog”. The evolution of the Elder Scrolls games makes this fairly obvious to notice. The biggest failure of Morrowind’s combat (as well as Daggerfall) was that there were to-hit rolls. You swung your weapon and the game would roll to figure out if you hit your target or not.

This way of resolving combat is an heritage of classic pen&paper RPG rules, but the problem is that they do not make sense in a game like Morrowind. Those rules were made to simulate the entirety of combat. AD&D rules, for example, were abstracted to simulate an entire minute of combat with just one die roll:

Advanced Dungeons & Dragons 2nd Edition
A round is approximately one minute long. Ten combat rounds equal a turn (or, put another way, a turn equals 10 minutes of game time).

But these are just approximations–precise time measurements are impossible to make in combat. An action that might be ridiculously easy under normal circumstances could become an undertaking of truly heroic scale when attempted in the middle of a furious, chaotic battle.

When making an attack, a character is likely to close with his opponent, circle for an opening, feint here, jab there, block a thrust, leap back, and perhaps finally make a telling blow. A spellcaster may fumble for his components, dodge an attacker, mentally review the steps of the spell, intone the spell, and then move to safety when it is all done. It has already been shown what drinking a potion might entail. All of these things might happen in a bit less than a minute or a bit more, but the standard is one minute and one action to the round.

So during one minute a lot could happen, many attacks, feints and moves. But you can’t simulate all that, so you abstract it and concentrate it in one to-hit roll, leaving aside the details.

But in a game where you control your character in first person and decide how to move, circle the enemy and swing your weapon, then all those details ARE PART OF gameplay. It’s not anymore an abstraction of combat as if you controlled your character from a overhead perspective and moved in combat turns. The in-combat time is analog. Finely grained. And so it’s not a good idea, design-wise, to mix abstract combat rules with analog combat gameplay.

That’s why in Oblivion and Skyrim the to-hit roll was discarded. If you are in range and swing you weapon, your weapon always hits. And then think that if technology was advanced enough that it could simulate a full body, with internal organs and everything, then it would render the abstraction of “hit points” also unnecessary.

A roguelike is a different type of game, almost entirely “digital” and abstracted. The game-world is made of discrete cells, space and time are stricter. Your character is just a single letter printed on screen. All this makes abstraction required. You can’t manually swing your weapon, dodge and parry with precise timing as in Skyrim or Dark Souls, so you need game rules that simulate all of this internally. You need statistics that define your character and what it can do, options as decision at a higher level.

That means that a roguelike is much closer to the nature of old-school RPGs than how modern, “analog” games can be. It’s not an issue of “new VS old”. The old-school way is not surpassed. It’s just that we deal with two different genres, kinds of games. Cultural trends simply made one more popular because abstraction is always a barrier to accessibility (and that’s why first person shooters are popular too: as little abstraction as possible, no layers between you and the simulated world).

And that’s why I believe that rediscovering those old-school rule systems is the interesting thing to do, for roguelikes, instead of writing roguelikes that also hide mechanics behind layers of complex math.

If you STILL think this only applies to old games, then I point you to Project Eternity. At this moment they are right about to hit $3,500k. That’s a lot of money and people involved. One of the ideas sitting at the foundation of this project is to go back at party-based, top-down fixed camera of Baldur’s Gate. The consequence of that choice is making all I wrote here relevant for that game too. We’ll see if their game design is savvy enough to properly deal with it.

Even the just released XCOM has overhead perspective and to-hit rolls.

(since you can’t post comments on this blog, use this just in case)

Posted in: Uncategorized | Tagged:

(Mis)adventures in roguelike development: Rule System

I’ve been silent here because I actually spent time doing stuff. I’ll eventually recuperate the “diary” but for now it already exists in a form: here.

That became a long thread.

In the meantime I wrote down some first high level design consideration that will direct toward the “system” I’ll use for the ruleset governing the game.

Following are a number of RPG classic systems that I consider interesting and whole mechanics I’m planning to integrate into my roguelike. So before moving on, I wanted to compile a simplified list of a standard type of attack in each of these systems. Just one attack, so not a whole combat turn.

(surprise roll d100)
– Initiative 1D10, subtract related speed component, add speed of action
– TO HIT: skill %. Succeeds if less than skill level. If lower than 10% of the skill -> critical. (plus modifiers due to cover/movement)
– (target can parry by spending one attack)
– Check for location. Roll another %. If under 40% multipliers to damage apply.
– Roll damage dice dependent on weapon. If critical, it does max damage the weapon can do, without rolling.
– Armor value is subtracted from damage (armor is locational and has values for different types of attack: cut, blunt, pierce, fire, chemical, stunning, electrical).
Note: if total damage exceeds a certain Wound Level (75% of total hit points), the target is dazed.

Considerations: two weak points. The first is I don’t like parry using attacks, since if you fight to win you’d rather try to kill the enemy as fast as possible instead of wasting attacks to parry. The other weak point is that location is random and can push damage quite a bit, so a bit too driven by chance.

(surprise, DM decides)
– Initiative 1D10 + agility bonus. Initiative is rolled only once for whole combat, same order for every round.
– Can set a “stance”, like all out attack, or defensive stance, that affect hit rolls.
– TO HIT: skill %. Succeeds if less than skill level. (some environmental variables may apply)
– (target has one “reaction” slot to use to parry or dodge)
– Check for location. This uses the same to hit roll, but with reversed order. so a 15 to hit, becomes 51 for location. Location is just location, doesn’t affect damage.
– Roll damage dice. If roll a 10, roll to-hit again, if successful, roll a 10 to add to damage. If you keep rolling 10s, they all add up to damage.
– Armor value is subtracted from damage.
Note: if damage surpassed a certain level, it’s a critical with consequences.

Considerations: it’s more streamlined and has a free slot to use to parry or dodge, instead of wasting attacks. Has the nice trick to use only one dice for both to-hit and location, though it won’t matter in a computer implementation.

(surprise happens after initiative, may need perception rolls)
– Initiative 1D20? + dex bonus. Initiative is rolled only once for whole combat, same order for every round.
– TO HIT: 1D20. Succeeds if above armor class of target. Base 10 + armor + other bonuses.
– Roll damage dice. Armor only counts for to-hit and doesn’t absorb damage.
Note: a to-hit of 20 is critical if another to-hit roll is successful. Weapon type says how many times to reroll damage, usually 2x.

Considerations: it’s fairly simple. It has the usual realism issues of D&D. There’s no “skill” since you only get bonuses through stats and new levels. Armor doesn’t absorb damage, which means that if you fight a guy in full platemail with a knife and hit, you do as much damage as if the guy was naked. If you fight the same guy with a knife or a long sword, there’s also no difference in being able to hit him. There are a few combat maneuvers, but parry doesn’t seem to exist.

– Initiative is fixed. No dices being rolled. It depends on various bonuses and conditions.
– TO HIT: % dice + attacker Offensive Bonus – defender Defensive Bonus. You check the value you get on a table with the defender armor value. Rolls are open-ended, so you keep rerolling and adding, as long you go above 95.

Considerations: that’s it basically. It all depends on HUGE weapon-specific tables that tell you if the attack fumbled, was critical, and how much damage it dealt. The good aspect is that attacks consider the defensive bonus of who is attacked, and before a turn you decide how to redistribute your Offensive Bonus to the Defensive. So there’s a granular type of defense where you decide how much to focus on defense and how much on offense. So “parrying” is just about relocating your bonus from offensive to defensive, and is not an active “action”.

(surprise, the DM decides)
– Initiative is a skill value. No dice rolls required.
– Attacker declares: target, weapon, (optionally) aiming (high, mid, low, -10 penalty), weapon aspect (if you want to exploit an armor weakness).
– Defender declares: Block, Counterstrike, Dodge, Nothing.
– TO HIT: BOTH parties have to roll % dice, and result is mapped on a simple chart. Simultaneous strikes are possible.
– Roll % dice for specific location (this can be slightly rigged by declaring a general aim above).
– For damage you usually roll 1D6 (regardless of weapon), add result to the fixed weapon damage, subtract armor absorption, and, if result is still positive, see on the Injury Table what kind of injury you get matching the value for the location.
– Injuries directly and immediately apply penalties to stats and skill checks.
– Death essentially comes from the target getting disabled or fainting.
– Healing, after successful treatment, is dealt for every single wound. Every wound has a chance of going down one level every five days.

Considerations: This is an odd beast. Armor not only just absorbs damage, but also makes one easier to hit. There are no hit points, and only wounds treated separately. Weapons can be used for different types of attacks, blunt/edge/point, and armor has different protection values against each. Which also opens the possibility to “Compound Layers”, meaning that you wear armor in overlapping layers and they all add up to the protection of that specific location. You could even attempt wearing a DOUBLE PLATE, this has some diminish returns, but would also give pretty huge penalties to attacks and defense. Classes are not restricted to certain weapon types. No levels. So it does a lot of things I like as a system.

After all that I’ll probably go with an hybrid system. I actually like Dangerous Journey general system as it seems well organized. For example every skill falls under some attribute. The attribute not only provides some basic value for the skill, or eventual bonuses to skill checks, but it also sets a maximum of expertise in that skill. So for example if you have Strength of 60 and use an attack based on strength, your skill won’t exceed 60. You can’t get better than that, if Strength is not improved first.

The hybrid I could make would be the character system of Dangerous Journey plus the combat system of Harnmaster. Since they both use % skill they integrate smoothly. I’d then have to simplify a lot the wound/healing system, since I can’t make a player wait idly for days for every small wound.

I was also considering a party system. Initially the idea was to have it abstracted. So you’d still only see one “@” on screen representing the whole party. Instead I thought that a real party isn’t much harder to do. The idea is: you still control one “@” normally, but as a monster is sighted you enter a combat phase. As the combat phase starts you get to “deploy” all your party characters in a small area around your main character. And during the whole combat you move the party members individually. Optionally, you can initiate combat even if no monster is around, and so you could split your party and move party members individually. So it’s a rather flexible system. I’m aiming to have up to four party members in total, including the main character.

I also started to deal with how progress happens. No levels. The characters earns XP points for successful actions like dispatching monsters, finding loot, completing quests, the usual. But there’s no level and XP points are used as “currency” (this is just one of the many mechanics I’ll borrow from Dark Souls). By spending these XP points you get chances to improve various aspects of your character (stats, skills). If the dice roll used to improve a stat is unsuccessful, you get no improvement but XP is still used up. If the dice roll is successful you get the improvement BUT the XP requirements across the board for further improvement go up. Still undecided about how to handle death, no permdeath, but there will be probably a way to lose XP, Dark Souls-like.

Only stats and skills that the character actively used can be improved, but you only need to use a skill once to be able to improve it (so you get enough flexibility to improve whatever you want, without having to “grind” skills).

In order to prevent save cheat mechanics, to avoid that one could reload the game if an improvement roll is unsuccessful, the game already rolls these improvements when an action is first made. And when the player decides to use the XP the game only “reveals” the dice roll it made long before. That way, reloading a game would only produce the same result. :)

(and there would be some time limits so that you need to wait at least a day before spending XP again to improve the same skill. Which means that the fasted path is to play the game normally instead of saving/reload scumming)

On iterative design development it is very likely, essentially guaranteed, that “wasting” XP on unsuccessful improvements is a frustrating rule that would be erased and the process streamlined. But we’ll see.

(since you can’t post comments on this blog, use this just in case)

Posted in: Uncategorized | Tagged:

(Mis)adventures in roguelike development: Why now?

If you don’t know what’s a roguelike you can start here, or even go straight to play one of the most sleek and recent games in the genre: Brogue.

The definition usually covers a wide range of games but usually a roguelike is associated with the idea of an ASCII RPG where you generate a character and then go exploring randomly generated dungeons. Why should you care, tho? What is that is good and unique in these prehistoric-looking games? Is it just nostalgia?

My interest in this is because I don’t believe that it’s just about nostalgia. This interest was sparked a few months ago, when I spent several weeks going through old and magnificent Amiga games, and then more weeks on roguelikes. It was almost a frantic search. I do believe that something of value is lost and that those games had aplenty, and a roguelike is an opportunity to mess with that stuff directly. Mixing old sensibilities with the new. But nowadays roguelikes are a lot more than that. The lack of graphic let these games focus on very deep and complex mechanics that you simply cannot find in other genres. So roguelikes aren’t just old looking games with unintuitive interfaces, but also offer a kind of gameplay and complex interaction that is extinct in other games. These games are pioneers, not rearguard.

The other side of the medal is that you can mess with this stuff. Some 14 or so years ago I started in C and under ancient MSDOS an attempt to write a RPG from scratch, using the Allegro library (that is still around) and DJGPP (the Gnu compiler for dos). I wanted to build a simple foundation like the first Final Fantasy games, and then roll into that kind of engine a more deep interaction with NPCs and environments. Without the internet to look stuff up it was an incredibly hard task, even setting up the environment with the IDE, compiler and all the rest. After messing with this for a while and creating a rudimentary skeleton of a game that showed a sprite moving on a tile map (and then getting completely stuck when I tried to convert it to interrupt-based timing so that it wouldn’t run at different speeds on different hardware), I figured it would take me more than a year JUST to write the engine, and then I could have started, maybe, actually making the game, design and content, the stuff that I actually considered interesting. I realized that you either dedicate yourself fully to such a project, in a totalizing way, or it’s just impossible to make something even barely worthwhile. That’s where I stopped. I just couldn’t afford to plan things so long term and sink into that all my time. It just couldn’t be realistically done, even if I only wanted to make my own project without any intention of selling it or whatever.

If I’m back attempting a similar project is because I see in roguelikes (and in the different context, because of the internet offering so much material you can look up) the possibility to quickly get to the “meat” of the game. All the standard roguelikes build the whole game by reusing a few output functions, so the “engine” is almost directly covered. It’s like the possibility to quickly write prototypes the way you want, without the baggage of graphic. So a possibility to remove as much as possible the overhead and busywork of engine programming, and do instead game programming, design, content.

Programming is actually one of the most addicting experiences you can have. More than playing a good game, once you are in the groove. But it is also immensely frustrating if you hit a roadblock and have no way to get over it. That’s when projects usually fail. This time I’ve got the illusion that the path is viable. Because there are good libraries that cover most of the stuff I need, specifically for what I need, because the internet overflows with documentation that you can use, because I can purchase good books on programming, and game programming, and because there are plenty of roguelikes out there that are open source, so you can go into them and see how they work. Pilfer hundreds of games of their good ideas, and put them in your game. The accretion of these parts, and the original, odd mix I want to make is what I’m looking for. I will go back playing those Amiga games and classic RPGs, parse their game design, as well as taking stuff from modern, perfectly designed games like Dark Souls, and then cross-breeding all that with pen&paper RPG rule systems and classic modules. I have already a feature list planned that will take me several centuries to implement, but that’s what makes it fun ;)

I can’t say how far I’ll go, or if I’ll be even able to start. I’m essentially learning programming from zero, starting from the very bottom. My mathematical skills are also abysmal, so the perspectives are bleak. But whatever. The intention is to keep some sort of diary to document my (lack of) progress. An anti-tutorial on top of a tutorial. Whatever I make, in the short or long term, will be open source. Though it will likely take me years before my source is of any interest to someone beside me. But again, I’ll write even the diary for myself, so I can see what I’m doing and all the stuff I get wrong. The thing I hate the most is when I bump into a problem I already solved before, but can’t remember how I did it.

Obviously it all depends on how much time I can allocate to this, and with how much continuity. That’s not entirely in my control, but given the chance I’m extremely stubborn and so I’ll keep going at it.

(since you can’t post comments on this blog, use this just in case)

Posted in: Uncategorized | Tagged: