Difference between revisions of "JBand"

From RogueBasin
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 6: Line 6:
| site = http://sourceforge.jp/projects/jband/
| site = http://sourceforge.jp/projects/jband/
}}
}}
I am considering starting work on a Japanese version of Angband.  The name [[JAngband]] was already taken, so I chose JBand.
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.
Comments, questions and suggestions welcome in the talk page.
Line 13: Line 13:


# Gameplay unchanged from 3.1.1 dev (and keep up with updates) (See [http://trac.rephial.org/browser/trunk Angband SVN])
# Gameplay unchanged from 3.1.1 dev (and keep up with updates) (See [http://trac.rephial.org/browser/trunk Angband SVN])
# Source files in Unicode (UTF-8 with BOM stripped would seem to be sensible).
# Source files in Unicode (UTF-8 with BOM).
# Freely switchable between Japanese and English during play.
# Freely switchable between Japanese and English during play.
# Utilize C++
# Utilize C++ (?)
# Code to be easily accessible by programmers.
# 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.
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.  <!-- Does that sound cool or what? :-P --> 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 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.
Line 30: Line 30:
# Many compilers will not work with Unicode source files. (Dev-C++, for example).
# Many compilers will not work with Unicode source files. (Dev-C++, for example).
# Unicode file format differs slightly between Windows and other platforms.
# Unicode file format differs slightly between Windows and other platforms.
# Unicode support is implemented differently on different platforms.
# I know even less C++ than I do C.
# I know even less C++ than I do C.
# File size and memory usage will undoubtedly go up a lot.
# File size and memory usage will undoubtedly go up a lot.
Line 37: Line 38:
* Changed *.c and *.h to Unicode (UTF-8).  Still compiles with VC++, no longer compiles with Dev-C++.
* 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.
* Minor code changes to remove very many compiler warnings.
* Remove BOM from source code files.
* Now compiles as a Unicode program and can be played (just).
* Now compiles as a Unicode program. Can't actually play it yet though.
* Code changes allow *.txt files to be in Unicode.


=== Next to do ===
=== Next to do ===


* Compile with C++ (and fix errors that arise).
* Remove bugs! (Assistance would be welcome ;-)
* See if it compiles in Linux.
* Code changes to allow *.hlp files to be in Unicode.
* Code changes to remove compiler warnings in Linux.
* Convert, and check, remaining *.txt files to Unicode.
* 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.)
* Code changes to support both Japanese and English text in data files (monster.txt, etc.)


Line 59: Line 59:


== AngEdit ==
== 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.)
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.)
Line 70: Line 72:
=== Platforms ===
=== 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 wxWidgets and SDL.  Which (if any) I use in the end will depend on my experiences in working with them.
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.
 
Initial impressions are that SDL is the easiest to add to the compile environment, but wxWidgets has much superior functionality (if I can get it to work).
 
=== Compiling ===
 
Currently there is "main-win.cpp" and "main-sdl.cpp". 
 
main-win.cpp : Compiles with VC++.  Need to set /D_WINDOWS C++ compiler command line option.
 
main-sdl.cpp : Need to set "/D_SDL".  Currently tested with VC++ but not yet with other compilers / platforms.  Need to add SDL include libraries (with VC++, in Project->Properties->C/C++->Command line
add "C:\RL\SDL\SDL-devel-1.2.13-VC8\SDL-1.2.13\include" to the include directories).
 
main-wx.cpp : Not ready for testing yet.  Need to set /D_WX.

Latest revision as of 10:26, 27 June 2009

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.

Retrieved from "http://roguebasin.com/index.php?title=JBand&oldid=18337"