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
Things are developing fast on my end. These specs can change over time.
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.
- 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
- Because of Fractals, support for int-only archs will be dropped. We need floats.
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. :-)
The most important reason to use C, or any language, is because of legacy. If the code is written in C, then the path of least resistance is to continue the trend. In the case of Vanilla Angband 3.0.5, there are over 180,000 lines of code, including the info files and lua bindings. It will simply be too much work to move over. Furthermore, many variants are also written in C. If I wanted to share my developments, then it would be best to use C also.
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.
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.