Difference between revisions of "JBand"

From RogueBasin
Jump to navigation Jump to search
m
Line 49: Line 49:


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
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 ===
[[JBand/Compiling How to compile JBand]]

Revision as of 13:58, 25 May 2009

JBand
Angband Variant
Developer PaulBlay
Based on Angband 3.1.1 dev
Theme Fantasy
Download Not yet.

[There is no Official site]


I am considering starting work on a Japanese version of Angband. The name JAngband was already taken, so I chose 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 stripped would seem to be sensible).
  3. Freely switchable between Japanese and English during play.
  4. Utilize C++
  5. Code to be easily accessible by programmers.

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. I know even less C++ than I do C.
  4. File size and memory usage will undoubtedly go up a lot.

Progress to date

  • Changed *.c and *.h to Unicode. Still compiles with VC++, no longer compiles with Dev-C++.
  • Minor code changes to remove very many compiler warnings.

Next to do

  • Compile with C++ (and fix errors that arise).
  • See if it compiles in Linux.
  • Code changes to remove compiler warnings in Linux.
  • Code changes to allow the *.txt and *.hlp files to be in 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

JBand/Compiling How to compile JBand