JBand

From RogueBasin
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
JBand
Angband Variant
Developer PaulBlay
Based on Angband 3.1.1 dev
Theme Fantasy
Download Not yet.

Official site


This is going to be a Japanese version of Angband. Unfortunately the name JAngband was already taken hence JBand.

Comments, questions and suggestions welcome in the talk page.

Planned Features

  1. Gameplay unchanged from 3.1.1 dev (and keep up with updates) (See Angband SVN)
  2. Source files in Unicode (UTF-8 with BOM).
  3. Freely switchable between Japanese and English during play.
  4. Utilize C++ (?)
  5. Code to be easily accessible by programmers and translators.

So why Unicode? While nasty things(tm) can happen whether you are using Unicode or not Unicode is the future, and Shift-JIS or EUC-JP is definitely the past. So the the reward in the long term for learning how to overcome Unicode related problems should be greater than that for Shift-JIS or EUC-JP.

Why freely switchable? From my experience with other multi-language games bugs creep in because it is awkward to do proper testing in both languages. This should be alleviated by allowing switching between languages while the game is still running.

Why C++? For the purely selfish reason that I would like to learn the language. I am also hopeful that C++ features should (when I'm familiar with them) make multi-language support more transparent.

What do I mean by "easily accessible"? Well, I don't want to put off people from developing games based on this or borrowing code. If all the text in the code is replaced with stuff like _TXTSTR123456 I suspect people won't want to know about it. So I think having both languages in the source code would be best (even if it's not good practice). Also it should "fail safe" when one language is missing - instead of grinding to a halt with an error message (e.g. Show text from language version that is present).

Problematic Points

  1. Many compilers will not work with Unicode source files. (Dev-C++, for example).
  2. Unicode file format differs slightly between Windows and other platforms.
  3. Unicode support is implemented differently on different platforms.
  4. I know even less C++ than I do C.
  5. File size and memory usage will undoubtedly go up a lot.

Progress to date

  • Changed *.c and *.h to Unicode (UTF-8). Still compiles with VC++, no longer compiles with Dev-C++.
  • Minor code changes to remove very many compiler warnings.
  • Now compiles as a Unicode program and can be played (just).
  • Code changes allow *.txt files to be in Unicode.

Next to do

  • Remove bugs! (Assistance would be welcome ;-)
  • Code changes to allow *.hlp files to be in Unicode.
  • Convert, and check, remaining *.txt files to Unicode.
  • Code changes to support both Japanese and English text in data files (monster.txt, etc.)

The Impossible Dream

I think it would be neat if the trunk of Vanilla Angband was used my work to better support multiple languages. I don't think that will ever happen, though. :-P

See also

How to compile JBand

Angband SVN

AngEdit

AngEdit is currently on hiatus until (unless) JBand development crawls to a halt.

As a side project I am attempting to develop a utility to load/save and edit the text files found in lib/edit. Could be used to add new objects, edit monsters, etc. (You can edit the text files directly but, in theory, this way should allow more safety checks, etc.)

SQLite

AngEdit makes use of SQLite 3 for the database functions. SQLite is public domain and is used as a plain .c and .h file included in the project itself, so there are no external libraries, .dlls or separate distribution / installation to worry about.

I will be using AngEdit to get used to SQLite with a view to making use of it in JBand (or not).

Platforms

Unlike JBand I intend to have AngEdit support multiple platforms from the start. As such I am looking into various multi-platform libraries like SDL. Which (if any) I use in the end will depend on my experiences in working with them.