Re: Anyone on this list?

[Ingo Ruhnke <grumbel@gmx.de>]

Xarvh Admin <xarvh@lombardiacom.it> writes:

> Yeah, it's hard, but Xarvh has been under developement for 2 years,
> it has a shape, is a real thing, is not blocked in planning
> status...

The problem is that one has to run the game before really seening the
difference between 2 years of work and a weekend spend making a few
nice artworks.

> Please take a look at the site.
> http://freeweb.lombardiacom.it/xarvh/
> There are only two messed up pages, but they contain lots of info.
> Xarvh is at a good developement stage, and has a good graphic.
> I keep the source tarball updated (`relase early, relase often`)

Forget this 'release early, release often', it doesn't work for games.
Instead release something that works and gives a good overview over
the project, something that shows it from its best site. Offer CVS
access to the people and developers who really want early&often and
probally want to get their hands dirty. but the don't really care that
much about early&often for your normal tarballs.

> and i try to constantly add new material... spare time permitting...
> I don't want someone to have the same thought i have about a great
> game, but some feedback, some costructive critics would be
> appreciated...

I tried now to download and compile it, but "it didn't work":

$ ./xarvh 
Xarvh 0.1a, Copyright (C) 2002 by Francesco Orsenigo.
xarvh_init: unable to find any xarvhrc file.
Xarvh Interface starting.
data_open_base: opened `./cursor.mrl`.
data_open_base: opened `./fbig.mrl`.
data_open_base: opened `./font14.mrl`.
data_open_base: opened `./counters.mrl`.
data_open_base: opened `./menu.mrl`.
data_open_base: opened `./pick.mrl`.
data_open_base: opened `./land.mrl`.
mmi_setup: a required file, `overmap.mrl`, was not opened.
$

A few suggestion, just have one tarball with src + data, not two
seperate ones unless it gets huge (>10MB) and you expect to have code
changes much more often than data changes.

Add a few makefiles to the thing, I want to type ./configure && make
and have something I can run, copy&pasting something out of a compile
howto, is not really what I like. Using autoconf can sometimes cause
more throuble than good, so just placing the command from the COMPILE
file into the makefile is perfectly ok. Follow the normal naming
conventions of README, INSTALL and Co, nameing files differently will
just require people to search longer or give up if they can't figure
out how to run it. 
 
Release static-binaries, that I can just unzip and run, without any
compilation. Make sure that they work, which is relativly easy, since
you have to untar and run them once on a computer other than yours. I
consider binaries more important than source, since only very very few
people will ever have a deeper look at the source, but if your game
should go into a distro, make sure that you provide source tarballs,
since most distros won't ship static-binaries.

Pack the news on the homepage on a different page, currently one has
to scroll the page down completly to find some generic game info.

Once everything is nicly packaged and works out-of-the-box for most
people, make an announcement on happypenguin.org and other news sites.
Make sure that you have a good looking screenshot at hand to place it
in the announcment and a clear description.

> Take a look at FreeCiv: it relies on X windowing system, and its
> interface is ugly, hard to use, and has lots of problems (mouse
> wheel is useless, scrollers must be activated with mouse buttons and
> cannot be dragged...)

Civ2 wasn't much different =;)
 
> Xarvh does not rely on any specific library: at the time can work with SDL or 
> ALLEGRO indifferently, and will work with BSD network calls, SDL_net, 
> DIRECTX; i'll make a native Linux port using raw GPM input (like ALLEGRO 
> does) and framebuffer, so that it will use no other libraries other than 
> linux libc, with better control and performance than ALLEGRO or SDL...
> (no framebuffer? use SDL)

I wouldn't waste time making it too abstract and library independed,
pick a library that works for you and provide static-binaries for the
rest of the world. Use a library that is common, but don't fear using
uncommon libraries if they will reduce your workload. Having a game
that is fun is good, having a game that can run with Allegro or SDL is
something the player doesn't care about.

> Try to use a non-US keyboard with SDL! I still have not found a way
> to print in my game accented chars like тащи, while reading directly
> from the terminal i get the right translated char.

Make sure that you game is fun and has a userbase before caring to
much about accented chars and things like that, which people will not
care much about and which they are already used to from quite a lot
commercial games.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
Games:    http://pingus.seul.org/~grumbel/gamedesigns/
JabberID: grumbel@jabber.org 
ICQ:      59461927