Messages

I can see the difference between a perfect game and an imperfect game. With a game, you enter a new world (quite literally in an adventure game), and you have to find out what the rules are, how things work around here.
That discovery process can be an interesting part of a game. You stumble around, observe how things react, and learn from it. You build yourself a mental picture of the rules. That's how an imperfect game works, you try to find order in the apparent chaos even if that order doesn't match with reality.

In a perfect game however, you know all the start-values, you know all the rules, and the little edge-cases of the rules. In other words, in theory, you have sufficient information to play the game for maximum profit/points, minimal time, or whatever.
I say "in theory", because knowing the rules and the start-value doesn't mean you can achieve the maximum solution.

For 'simple' games, you can of course. The card game with your children is such an example. I don't know the game, but I guess you can easily win all the time. By systematically applying a few rules, you can perhaps even win at maximum profit. (For your children however, it's an imperfect game, they don't have all information, and are trying to discover the rule of how dads face relates to the chaos of cards.)

For less simple perfect games, you may have the start values and the rules, but you cannot oversee the consequences of applying rules. The problem then becomes which rule to apply in which order, ie you're trying to invent a strategy for applying the known rules in a known world to get maximum profit. Think of a sudoku. The rules are known, all the given numbers are in plain sight, yet zillions of people play these things. I believe they do it because they want to see the answer, they want to find out if they can 'see' each number. 'See' is a here a sequence of logical reasoning steps that they must do. The question is not what the rules are, it is what to check in which order to make solving the puzzle more simple/manageable.

The game Go is one of the more complicated perfect games. The rules are extremely simple (it takes about 5 minutes to explain them), yet the number of moves you can make is so large, you have no hope for playing it optimally, even if you start at the age of 3-4 and do nothing else for your entire life. The result is that people concentrate on strategy, and a huge number of books about good forms and bad forms in Go, how to play the first moves, how to play the end-game, etc is the result.


Urgency:
I don't see urgency at all. For me, a game is about finding out the rules first, and a strategy second. I see playing a game as an experiment to learn about the rules or the strategy. If it fails, I can always try again.

[Edit:]

Well, yeah, but tex2rtf fails to build at my system as I pointed out at item 2 in my first post, due to a too new g++ or a too new wxwidgets probably. Fedora typically picks very new versions of the software.

Are you saying you want to stick with tex2rtf?

Edit: I made a quick and dirty partial conversion of the manual to Sphinx: https://github.com/Alberth289346/ags/commit/f44fc381b7c1d54653ab6493f93cbb295b81fe4a

Files that I touched:

Code: ags

other-features.rst
 credits.rst
tutorial.rst
runtime-engine.rst
introduction.rst
copyright.rst
ags.rst

Note that github also knows restructured text, so it can display the files somewhat nicely. It doesn't do the Sphinx extensions, so you'll at least miss the cross-document references.
If you checkout the commit, there are also generated html files, _build/html/ags.html is the starting point.
I'd be happy to do the entire conversion if that is desired.

Hello,

I downloaded the source, and am trying to build the manual at my Fedora system, and ran into a little trouble. This seems the least wrong forum to ask about it.

- My first attempt was to run "pdflatex" on it, as it was a .tex file. My compiler complains it's old (2.09 source, rather than the 2e variant, which exists for around a decade already or so). Also, it's not compilable, A number of small edits brought me to page 81, where I ran into a bigger problem with a "description" list. I can probably fix that too, but I need to check with the book. Quickly looking at the result showed at least one table that was waaaaay too wide, at which point I decided this would be more work.

- My second attempt today was to use the official way, as listed in "ccompile_documentation_unix.sh". I installed the various wx* packages, and ran the script, which results in a long list of compile errors while building tex2rtf

Code: cpp

g++ -c `wx-config --cxxflags`  -o rtfutils.o rtfutils.cpp
tex2any.cpp: In function 'bool read_a_line(wxChar*)':
tex2any.cpp:454:39: error: invalid cast from type 'wxCStrData' to type 'wxChar* {aka wchar_t*}'
        OnError((wxChar *)errBuf.c_str());
                                       ^

(omitted a lot of similar errors) and

Code: cpp

rtfutils.cpp: In function 'bool WriteHPJ(const wxString&)':
rtfutils.cpp:541:19: warning: deprecated conversion from string constant to 'wxChar* {aka wchar_t*}' [-Wwrite-strings]
         helpTitle = _T("Untitled");

(also omitted a lot of similar warnings).
These problems happen in a number of variations.

While it looks solvable (now idea how currently, never done anything with wxwidgets), the end-goal seems to be html pages.
This brings me to the 3rd option.

- Convert the .tex file to .rst (restructured text). http://docutils.sourceforge.net/rst.html or for multi-file documents/sites perhaps even Sphinx http://sphinx-doc.org/tutorial.html this is a layer on top of rst, with additional goodies, and cross-document references.

I can do any of the above three, but I don't know what is actually wanted.