LeonTorres

Introduction

Hey folks, this will be one of my methods of communicating with the community.

I am a longtime Angband player. Recently, I have developed an interest in creating my own variant. The main drive is a desire to explore computing topics, such as fractals, advanced C programming, refactoring techniques, and so on. Because I am a document-everything-first kind of person and also an open source developer, I have decided to share interesting topics with the wider community by writing articles here.

Articles and Contributions

• Fractals

Quenta

This will be the name of my variant. Ideally, I'd like to start with ToME 3 and its engine, but I can't wait. So I will start with Vanilla Angband 3.0.5 and start refactoring nasty old code into a new future-friendly format. This is partly as an exercise to know the code and also as a wway to resolve the license issues surrounding Angband. All new code will be GPL'd with perhaps an LGPL exception for other roguelikes that have open code.

Features

• Generalized dungeons: Sets of dungeons are called Areas which link to each other in a many-to-many fashion. This allows for any kind of world model, including overland maps with multiple dungeons.
• Fractal patterns: The feel of the game will be enhanced by fractal patterns to make natural looking terrains, monster AI, treasure drops, etc.
• XML config: replace the *_info with xml using expat.
• Text-mode only: graphics can be added easily, but Quenta is a RL game where the most sacred cow is the text-mode nature. This is good for blind people too, let's not forget them. :-)
• Large dungeon sizes: Since fractals need processing power, Quenta is not for old systems. This lets us have large and varied dungeon sizes.
• Unicode support: A rich RL needs a rich set of characters to represent objects. Thus, unicode support.
• Generalized Bindings: I would prefer to avoid the pitfall of using Lua only as a binding. Bindings should be pluggable, just like Terminals are pluggable depending on architecture. However, this won't be implemented anytime soon.
• Out with the old, in with the new: As a rule, Quenta will be abandoning legacy cruft that hinders development

For now, the code is pre-alpha as I work in the framework for development, namely the refactoring to allow orthogonal development so we can have new files that are (L)GPL only. Once the ball is rolling, I'll set up a project using subversion (or perhaps git) somewhere and open up development.

C vs Everything Else

I've previously written an entire game, including artistic content, in the programming language Ruby. It never got past alpha due to problems I discuss later. You can see some screenshots at Botfrenzy. Now I am developing a roguelike variant in C. My perspective of the merits of using C vs some other language is constantly evolving. At this juncture, I must say that C is still a fine language despite its annoyances, and there are so many tools to help make development less painful. For instance, learning gdb is essential for debugging. It's actually somewhat more useful than Java's stacktraces. I also use vim with ctags on multiple terminals, which is essentially a poor-man's IDE. :-)

C is here to stay. It has quite a steep learning curve, but for those who know how to program, it is a very good language to use. However, the barrier for entry is kind of high and it isn't always the best tool for the job. For RL development, it is my opinion that the core of the engine should be written in C, but all content and modules in a scripting language of choice. Writing an entire game in Ruby was a pleasure and very easy due to its interpreted nature. However, the flexibility lends to sloppy design. After awhile, I had so much poorly designed code that it became necessary to rewrite everything. That's when I gave up. This is one of the main drawbacks of interpreted languages: The ease of use is not something that necessarily leads to better programming practices. However, it's a wonderful way to prototype things.

With C, you are forced to think your model through before implementing, because bug hunting will take up most of your time. (Of course, not everyone does.) Thus, I am developing Quenta in C, to force it to have a good system underneath, while keeping scripting languages in mind. Because I prefer Ruby over Lua, mainly because I know Ruby better, I have reservations about the lua-only system. I will make the bindings language agnostic.

Sometimes the solution is to mix things up. We can put the argument over language to rest by allowing anything; It is so much better to have several approaches to solving a problem than only one. My experiences will help make Quenta a developer's paradise. It will take time to get the framework up, but I am determined to do it. Ruby and Lua will be the first bindings, and probably the only ones.