PHP for Roguelikes?
iLive
A few days ago I starting writing a roguelike named jRogue on a very,
very long road trip. I wrote it in PHP, planning to only prototype it
and move on to a language like C++ later. However, by the end of the
trip I already had most of the skeleton of a playable roguelike in
place. Today, I have a (albeit horrible) FOV algorithm in place,
saving and loading of games and maps, and the beginning of many other
features.
My question, would it be worth the effort to port it from PHP to C++?
I certainly know PHP better than C++ as far as things like string
functions and arrays go, but C++ seems like a better language (and I
know it is) for programming in general. I am using PHP in a way it was
never designed, using a largely undocumented port of the ncurses
library to PHP.
On the other hand, one can write PHP code much faster than C++ code,
and since this is a turn based game, is the performance gain worth the
loss in throughput?
Filip Dreger
Looking at this newsgroup, I think the amount of people who have a problem like: "I have written all the features I wanted in my roguelike and now my real problem is performance" is small when compared to the number of us struggling to implement all the features we envisioned.
Filip Dreger
Gerry Quinn
ad98b5...@glegroupsg2000goo.googlegroups.com>, fdr...@gmail.com
says...
> If I were you I would stick with PHP. There's nothing about C++ that would make your job easier (strings and arrays will be harder to deal with) and making use of C++ specific language features would probably require you not to port, but rather to redesign your code.
>
> Looking at this newsgroup, I think the amount of people who have a problem like: "I have written all the features I wanted in my roguelike and now my real problem is performance" is small when compared to the number of us struggling to implement all the features we envisioned.
It does happen, often with Python. But it may be that Pythonistas are
a little more prone to drink the kool-aid and not realise that their
favourite language can be much slower than they think. That mistake is
probably less common with languages like PHP.
People have done roguelikes in Javascript. Really the OP will just
have to make a judgement call as to whether his design is feasible in
PHP or not. If it's not he will have to either compromise on design
(e.g. drop shadowcasting) or switch languages.
There's nothing intrinsic in a roguelike that requires computational
efficiency. Rogue was written in C, but it ran on machines a thousand
times less powerful than we have now.
- Gerry Quinn
Paul J Gans
That thousand is a serious number. I played rogue on a 4 Mhz
machine back a few decades ago.
--
--- Paul J. Gans
Gerry Quinn
I played it on a 7 MHz Amiga... running a PC emulator!
There was a version for the 4 MHz 8-bit Sinclair Spectrum too. It
didn't procedurally generate maps, but that was probably down to
laziness on the developers' part. Graphically it was far superior to
the original Rogue.
- Gerry Quinn
Kenneth 'Bessarion' Boyd
> Hello all!
>
> A few days ago I starting writing a roguelike named jRogue on a very,
> very long road trip. I wrote it in PHP, planning to only prototype it
> and move on to a language like C++ later. However, by the end of the
> trip I already had most of the skeleton of a playable roguelike in
> place. Today, I have a (albeit horrible) FOV algorithm in place,
> saving and loading of games and maps, and the beginning of many other
> features.
>
> My question, would it be worth the effort to port it from PHP to C++?
I cannot imagine under what circumstances it would be. The port would
be easier for a command-line PHP roguelike, but still not worth it.
> I certainly know PHP better than C++ as far as things like string
> functions and arrays go, but C++ seems like a better language (and I
> know it is) for programming in general.
1) Even in the absence of a pre-existing source code base, go with
what you're familiar with.
2) C++ (and C) are not ideal languages for roguelikes. Their main
advantage is raw portability (you do have to commit to a cross-
platform library such as SDL, *curses, or [barely cross-platform]
*conio).
> On the other hand, one can write PHP code much faster than C++ code,
> and since this is a turn based game, is the performance gain worth the
> loss in throughput?
Programmer time is far more important than machine time. Also, PHP
doesn't have any truly bizarre restrictions on what kinds of data
design are efficient (unlike, say, JavaScript or Python).
Martin Read
[Rogue]
>There was a version for the 4 MHz 8-bit Sinclair Spectrum too. It
>didn't procedurally generate maps, but that was probably down to
>laziness on the developers' part. Graphically it was far superior to
>the original Rogue.
And the 1 MHz 8-bit Commodore 64.
Of course, the 6502 cranked out about three times as many computrons
per clock as the Z80.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
iLive
for the first time. The simplicity, its rejuvenating.
Another question, not technically language specific, is it worthwhile
to make Roguelikes graphical, e.g. tiles or otherwise (Although I
personally don't like the idea, 3D graphics comes to mind)? On the one
hand, I see that it might make the game a bit more appealing to new
players of the genre. On the other, I tend to dislike the complex
graphics that other people would like. The less detail, the better.
When playing a game like Rogue, Nethack, ADOM, Angband, ToME, et al.
without complex tiles the game seems to come alive in my mind, and I
can imagine everything going on in the wonderful fantastical world of
Roguelikes.
And then again, that was a language specific question, because I can't
get SDL to work with PHP. Which means that, I'm probably going to stay
an ascii guy anyway, unless someone has a compelling reason to use
tiles (or I manage to compile phpsdl).
James Meickle
as SDL but it's dead simple to use.
Though, it won't work if you are running it from the command line - it
would only be relevant if you do it in a browser. And there you could
also be using JS, CSS, etc. so GD might not be the best option.
iLive
Ah, but I am using the CLI version of PHP. If it were on the web, I
wouldn't have any issues, because I've written lots of complex GD code
(isometric multiplayer roleplaying game? Not a roguelike mind you.).
Ah the memories. The only two CLI graphics libraries I'm aware of for
PHP are PHP Gtk and phpsdl. And for all I know, OpenGL has a library.
But somehow, I don't think OpenGL will help much.
Filip Dreger
Actually, I would gladly help with this or even take the whole job, as I always wanted to use Quercus for something interesting and never got a chance to go beyond simple tests (and running off-the-shelf applications).
Even if you never do it, the thought of having such option may be comforting.
Filip Dreger
iLive
of all of you, and, after more closely examining the internal workings
of my game, discovering than no other language (except, perhaps,
Python) could implement the current state of the program, which
hereafter I will describe :-)
As of now, all objects in the game (items, player and non player
characters, walls, etc.) are based on a hierarchy, with all objects
inheriting nine values, id, name, ascii, x, y, type, r, g, b.
The identifier number does not actually describe the item holding it.
When the game is loaded, it loads a XML-like file and creates a master
array, each entry in the array containing a proof copy of an object,
or a type of object, in the game. An objects ID is in fact the key to
the entry of the master array which contains the skeleton of the
object. Thus, any object could be cloned by $new_object = clone
$master_array[$object->id]. It is worth noting that this only clones
the skeleton of an item, not certain properties like x and y, which
need to be initialized.
The game has only one true room, that is, only one map with its
associated items can be in memory at a time. This one map is
represented by the array $room, which contains all of the objects in
the room. A new object, such as a wall, is created by cloning the
skeleton of an item to the array, i.e. $room[] = clone
$master_array[$key], then initializing the newly creating object using
the function end(), which points to the last entry in an array.
No system of time has yet been implemented, at the moment my code
simply iterates through the array $room, calling a member function
called turn, passing the the room, command (key code), and item map
(multi-dimensional coordinate-mapped array containing pointers to
objects in the room array).
The map is rendered by iterating through the room array, mapping the
ascii values of the items to the square they are contained on. This
array is then, along with the item map and player coordiantes, run
through a field of view algorithm, which reduces the content of the
array based on the current field of view. The array is copied over a
persistent map, replacing any old values and creating new ones if the
FOV includes a new area. The persistent map is then rendered onto the
screen.
All of this, except the field of view algorithm (and a unmentioned,
but important, subroutine for saving and loading rooms), was developed
in about five hours. In the long run, as has been mentioned, I have a
feeling that the speed at which I have been developing new features
will pay off.
gabriel arthur petrie
>
> On the other hand, one can write PHP code much faster than C++ code,
> and since this is a turn based game, is the performance gain worth the
> loss in throughput?
>
I don't believe there are any advantages to C++ over C that apply to
most simple compilable programs. I'd recommend C-99, but you're
currently using PHP and that seems way more interesting. Why not stick
with that? PHP is portable, I have a PHP enabled Apache server on my USB
thumb drive.
Martin Read
>discovering than no other language (except, perhaps, Python) could implement
>the current state of the program,
If it can be implemented on your computer in a high-level language, it
can be implemented on your computer in C, C++, or assembly language :)
The only questions are whether it's within the programmer's ability to
do so, and whether the experience will be pleasant.
iLive
Ah yes. Truer words were never spoken, so to speak. I suppose better
phrasing would have been, impossible to implement using single
language features, for ease of design and ease of readability (rather
than write support functions and use extra variables to do with C what
PHP could do with one keyword). Of course, if you added enough data
structures, indexes, etc. you could implement all of the higher level
features of PHP, particularly arrays. Some things, like PHPs weak and
loose typed structure, couldn't be implemented with C/++, but with
assembly... with labels and stuff, you know, there really aren't any
"language" restrictions with assembly.
Kenneth 'Bessarion' Boyd
> says...
>
> > If I were you I would stick with PHP. There's nothing about C++ that would make your job easier (strings and arrays will be harder to deal with) and making use of C++ specific language features would probably require you not to port, but rather to redesign your code.
>
> > Looking at this newsgroup, I think the amount of people who have a problem like: "I have written all the features I wanted in my roguelike and now my real problem is performance" is small when compared to the number of us struggling to implement all the features we envisioned.
>
> It does happen, often with Python.
The only reports of this happening on vaguely modern machines is with
graphical roguelikes in Python. This is fully predictable from the
intentional design decisions of Python's implementors. See below.
> But it may be that Pythonistas are
> a little more prone to drink the kool-aid and not realise that their
> favourite language can be much slower than they think. That mistake is
> probably less common with languages like PHP.
Python has this little issue that the only proper mutable data types
it has are lists and dictionaries. [Improperly, I think both files
and Python2 xrange/Python3 range are also mutable.] As long as you
aren't thrashing the garbage collector, Python does approach C
execution speed, especially as Python makes value copy painful and
forces all function parameters to be passed by non-const reference in C
++ terms. [PHP defaults to value copy for both assignment and
function parameter passing, but does allow overriding each of these
defaults when the performance vs. safety tradeoff makes sense.]
But even updating what would be a scalar in a normal language (C, C++,
Ruby, PHP, Perl) can trigger garbage collection because integers,
floats, and string literals are all immutable; when their reference
count drops to zero, splat. Likewise for tuples (updating a single
coordinate can trigger garbage collection on the whole tuple). Lists
and dictionaries only put the updated entry up for garbage collection.
And image processing has an easy time thrashing the garbage
collector. [Right now, I'm using Python to compensate for the fact
that I don't have a proper image processor that has a clue what "area
averaging" means. The load time for the 7410 x 3026 pixel *.bmp was
about 15 minutes (compared to < 2 seconds for MS Paint). Runtime to
smash the image down to 120px width was slightly over 5 minutes. Both
of these are decent speeds for a task that thrashes the garbage
collector incessantly, even after obfuscating the Python source to
intentionally] minimize immutable object creation (tuples for the Tk
interface).]
Krice
wrote:
> 2) C++ (and C) are not ideal languages for roguelikes.
Actually C++ is THE ideal language for roguelikes. How many times
we have seen people desperately trying their luck with python
(or php) and then painfully re-writing the game to C++?
Patric Mueller
Zero times?
Bye
Patric
--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/
UnNetHack: http://apps.sf.net/trac/unnethack/
Krice
> Zero times?
More like all the time. It's like people KNOW it's going to fail
with python and php, but they still want to try.
Patric Mueller
Links or it didn't happen.
And no, porting parts of your program to C/C++ to speed up your code
is not "re-writing your game" but "optimizing bottlenecks".
I prefer a developer that uses the right abstraction layer for his
program to one that thinks that he needs to reinvent the wheel and
only does it badly.
Krice
> I prefer a developer that uses the right abstraction layer for his
> program to one that thinks that he needs to reinvent the wheel and
> only does it badly.
One of the common misconceptions is that with "better" programming
languages you can make programs easier. It's not that simple. Once
you get low level stuff working in C++ the actual development
is pretty much the same. That's why people who try it with python
will find out how it actually works. It doesn't really help that
much to have a short syntax or easier way to do something simple.
It's not those simple parts that are important, it's the whole
program and you can't fake it. There is no other way than implement
all the complex features of a roguelike. There is no easy way to
do that.
Patric Mueller
> On 7 touko, 12:51, Patric Mueller <bh...@bigfoot.com> wrote:
>> I prefer a developer that uses the right abstraction layer for his
>> program to one that thinks that he needs to reinvent the wheel and
>> only does it badly.
>
> One of the common misconceptions is that with "better" programming
> languages you can make programs easier. It's not that simple. Once
> you get low level stuff working in C++ the actual development
> is pretty much the same.
Exactly. *If* you get the low level stuff working.
Of course there is no silver bullet but with languages like Python you
don't have to bother with the low level stuff and have more time to
concentrate on the real game play code.
> That's why people who try it with python
> will find out how it actually works. It doesn't really help that
> much to have a short syntax or easier way to do something simple.
> It's not those simple parts that are important, it's the whole
> program and you can't fake it. There is no other way than implement
> all the complex features of a roguelike. There is no easy way to
> do that.
Even with C++ you don't need to bother with the low level stuff if
you're using a library like libtcod.
Roguelikes don't have particular complex features and saying that one
or the other language is the best language suitable for roguelikes is
a ludicrous statement.
Languages have an edge on other languages in particular areas but for
most roguelikes this doesn't matter. It's more important if the
developer feels comfortable in the chosen language and finally that he
releases the game (if that is what he wants and not just a little
programming practice).
Somebody hacking away in C++ but never getting his game to point of
releasing is as bad as somebody hacking away in Python and never
releasing the game but the guy using Python has probably used more
time on the actual game compared to the C++ guy.
Kenneth 'Bessarion' Boyd
No reports here. Also, using the C extension facility doesn't count
as rewriting for any of Python, PHP, Perl, or Ruby.
That said, an easy trap (in both Python and Ruby) is to assume a
feature-complete curses module is available on all platforms the
language exists on. (Ruby does have curses on Windows, but it has a
bad reputation for reasons I have not investigated carefully.
Obscuring the documentation on how to use the curses support does come
to mind, but that describes *all* official documentation about Ruby so
nothing special there; you have to use unofficial documentation
because it's the only usable documentation.
Both Python 2.x and Python 3.x do not have curses on Windows at all.
Theoretically, it might be practical to port a Python/curses or Ruby/
curses to C/curses or C++/curses. [Starship 7DRL, this means *you*!
If ditching your off-the-wall ncurses module for Ruby-standard curses
fails.])
Filip Dreger
I do not remember anyone trying to achieve something in Python, failing and then rewriting in C++ with some success. The closest thing was, I think, Mark Damon Hughes and his Umbra, a 3d fpp roguelike written in Python. After finishing the game the author said some harsh words about Python's performance, but he compared it to Java, not to C++. The game did not get rewritten and was quite playable in Python version (it was Python 2.1 in those days). It was long ago and I think Umbra would play great on of today's machines (I am sorry if I made some huge mistake concerning the history of Umbra or Mark, or the game's history).
Filip Dreger
Filip Dreger
> program and you can't fake it. There is no other way than implement
> all the complex features of a roguelike. There is no easy way to
> do that.
I agree.
> One of the common misconceptions is that with "better" programming
> languages you can make programs easier.
I do not agree and I do not think you really believe it. For example managing memory in C++ is hard and makes certain features much harder to implement. If you seriously suggest that there is no difference in difficulty between different languages, consider writing a roguelike in assembler. Are you sure it would be about the same difficulty as C++?
> It doesn't really help that
> much to have a short syntax or easier way to do something simple.
I get the impression that you either try to have fun at our expense or do not really know many languages aside from C++. Are you claiming, that transforming XML is done equally easy with C and with XSLT? That writing a driver that uses unsigned shorts would be as easy in Javascript as in C++? That parallel programming with Erlang is about the same as in ActionScript?
Filip Dreger
Filip Dreger
> function parameter passing, but does allow overriding each of these
> defaults when the performance vs. safety tradeoff makes sense.]
AFAIK, in PHP objects are always passed and assigned by reference and arrays by value. But under the hood, everything is passed by reference, even arrays. Each array tracks the number of references that point to it and a copy is made only if someone tries to modify an array that is referenced from more than one place.
This way you get both the safety of copying and - unless the array is really modified - speed of passing by reference.
Filip Dreger
Kenneth 'Bessarion' Boyd
> > ++ terms. [PHP defaults to value copy for both assignment and
> > function parameter passing, but does allow overriding each of these
> > defaults when the performance vs. safety tradeoff makes sense.]
>
> AFAIK, in PHP objects are always passed and assigned by reference and arrays by value.
Right. I haven't needed to use objects in PHP in so long it isn't
funny. At least PHP makes it easy to value-copy an object when
necessary.
Which makes the function parameter passing asymmetric: it is possible
to explicitly force a parameter to be passed by reference (foo(&$x)
rather than foo($x) when declaring), and likewise force an assignment
to be by reference. The corresponding "force an object to be passed
by value" can't be done in the function declaration; it's a
proofreading problem at the function call sites.
> But under the hood, everything is passed by reference, even arrays. Each array tracks the number of references that point to it and a copy is made only if someone tries to modify an array that is referenced from more than one
> place.
Copy-on-write: Ok. Eliminates an entire category of micro-
optimizations, at the price of risking massive contentions in a multi-
threaded setting. [The upcoming C++0X standard implicitly bans copy-on-
write implementations of std::string, by using complexity requirements
on the std::string operations that are analytically violated by copy-
on-write implementations.]
Filip Dreger
> optimizations, at the price of risking massive contentions in a multi-
> threaded setting.
This is the nice thing about domain-specific languages: PHP, being by design a single-threaded language, can offer features that would be hard to achieve on a more generic platform.
btw: a lot of tasks in roguelikes are quite cpu intensive and might benefit from parallelization. Has anyone made a multi-threaded roguelike?
paul-d...@sbcglobal.net
> On 3 touko, 14:32, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
> wrote:
>> 2) C++ (and C) are not ideal languages for roguelikes.
>
> Actually C++ is THE ideal language for roguelikes. How many times we
> have seen people ... painfully re-writing the game to C++?
You certainly make it sound ideal.
Kenneth 'Bessarion' Boyd
ToME 4 is multi-threaded in all vaguely recent releases, yes. The
extra threads are to keep the sounds and tile visual effects from
locking up the keyboard.
Jeff Lait
> > Copy-on-write: Ok. Eliminates an entire category of micro-
> > optimizations, at the price of risking massive contentions in a multi-
> > threaded setting.
>
> benefit from parallelization. Has anyone made a multi-threaded roguelike?
All of my 7DRLs since Jacob's Matrix are multi-threaded. POWDER on
the iPhone is multithreaded.
In C++, by the way :>
These all just multithread to decouple the UI from the engine,
however, rather than improve the performance of the engine.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
> Out of 46 7drls this year less than half (21) were written using C or C++.
> The first place is taken by a Java roguelike,
The first place was a technically a tie this year. (Though I would
agree that Man in the Mirror was the better game - the roguelike
category is where it lost points) The other first place was a C++
roguelike.
OTOH, last years first place was C#, which I think fits in with your
claims.
And, of course, include the obvious caveat that the table is meant to
be general guideline rather than an absolute ranking.
Krice
> I do not agree and I do not think you really believe it. For example managing memory in C++ is hard and makes certain features much harder to implement.
It's not hard at all. It's just that some people don't use memory
management in C++ and that leads to those hard to detect bugs.
Kenneth 'Bessarion' Boyd
> For example managing memory in C++ is hard and makes certain features much harder to implement.
Memory management in C++ is only hard if you are not using RAII
(Resource Allocation Is Initialization). Which is what PHP, Python,
Perl, Ruby, Lua, etc. morally *force* on the programmer (it's that
good), and is simply impossible in C.
That is: writing C code in C++ (i.e., "safer C") is a sure way to get
*none* of the advantages of C++ relative to C. In contrast, writing C
in PHP or Lua actually is a net win (RAII), and doesn't involve eating
learning curve either for writing idiomatic PHP or Lua, or for writing
C in PHP or Lua. (The syntactical differences between C and Python,
Perl, or Ruby, are greater, but it is is still possible to write C in
those languages. It's just not trivial.)
What makes features hard to implement in C++ [as opposed to C written
in C++], is lines of code. Compared to idiomatic PHP/Python/Perl/Ruby/
etc., idiomatic C++ generally takes about 4x lines of code to in C++
to do the same thing when in-domain. The availability of asserts,
static assertions and their workarounds, and moving about half of the
run-time errors to compile-time predominantly helps when *maintaining*
source code, not when writing it.
(Of course, if you write C in PHP, Python, Perl, Ruby, Lua, etc. then
you don't get the lines of code advantage.)
alex23
> Both Python 2.x and Python 3.x do not have curses on Windows at all.
Nonsense: http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses
32 & 64 bit extensions for all versions of Python from 2.5 to 3.1.
Works wonderfully with urwid.
If you mean as part of the standard library, sure. But if you're
restricting your application deployment to what is in the stdlib,
you're making the job way too hard.
alex23
> How many times
> we have seen people desperately trying their luck with python
> (or php) and then painfully re-writing the game to C++?
Anyone who translated their entire codebase from Python to C++ -
rather than rewrite the performance bottlenecks in C/Cython or C++/
Shedskin to take advantage of Python's ease at wrapping external
libraries - has way too much time on their hands.