Re: [Help-liquidwar6] Four levels and some talk

[Christian Mauduit]

Hi,

On Sat, September 19, 2009 5:59 pm, Kasper Hviid wrote:
> Here's a few levels, mostly to show what those layers can do. Some of
> them might be updated later, but I felt like uploading something.
>
>
> https://www.yousendit.com/download/ZW9COGNTTk13TGp2Wmc9PQ
OK, I unstuff this and try them out. Thanks!

> I consider making some short youtube-video, to be uploaded when LW6 is
> playable enough to go public.
Yeah. I think I might update my road map and target a "full single player
game" (which will still be labeled beta) before hacking serious stuff on
the network side. The program is really network ready in the sense that it
already operates on a very simple message/text-based protocol at a low
level. So well, hacking it later will always be feasible and it happens
things are moving on the GUI and level front so well, I'll just follow the
movement and offer want people seem to want ;)


> I have tried playing some more with rules.xml and hints.xml. I think
> the levels generally needs to be VERY fast, since the mouse curser is
> pretty quick, compared to the keyboard-movement of LW5.
Yeah. LW has IMHO always been a game that required speed, it's really an
arcade-spirited game.

> I'm a bit unsure about what is the right values rounds-per-seconds and
> moves-per-round. I know that rounds-per-second is akin to
> drawings-per-second in classic animation - a value of 1 is equal of a
> slideshow. And moves-per-sec is the movement between the two drawings.
> But what is the right values for the two, in relation to each other?
Huh huh. There's no "moves-per-sec". Only moves-per-round and
rounds-per-sec. The idea is that, as you point it, the game might be happy
with high values such as 200 moves per second. That is to say : fighters
move 1 step 200 times per second. The problem is that at an internal
level, it might be unfit, performance speaking, to interrupt a thread 200
times per second. So we let the computer move fighters 5 step in a row,
then be ready for thread/context switching, then come back to hard work
and compute the next 5 moves. It's just a performance hack, rounds per sec
need not be two low for in many cases, it will condition how fast stuff
are refreshed on the screen. 25 is not that bad, 50 is better, 100 is
probably way too much. The moves-per-round allows you to increase the
global speed of the game, choking your CPU to death. I think in the
0.0.6beta already, the interface shows this when you tweak the parameter.
You see 25x2=50 (25 rounds, 2 moves per round, that's to way 50 moves per
sec).

> If I understand things correctly, the horse-power requirement of a
> level is a result of:
>  - The users screen resolution
>  - fighter-scale (in hints.xml)
>  - rounds-per-sec
>  - single-army-size or total-armies-size
>  - Amount of white in map.png
>  - Amounts of branching in map.png
>  - Number of layer png's.
>  - Some of them wacky gradient settings
Yep, that's it.

> I find it a bit frustrating the way changing the resolution also
> changes the gameplay. A fast paced level designed at a 800x600 is far
> less fast-paced when played at 1600x1200. (but VERY fast-paced at
> 160x120 windowed) I think I would prefer if the game used the same
> size of logical map, regardless of resolution or if it tuned
> moves-per-round to make the level keep the same speed.
I understand what you mean, in fact the moves per sec could be replaced by
something like "the whole level should be walkable in X seconds",
regardless of how fighters are small or big. I'll think about it, that
would typically be a loading hint (hints.xml).

> I don't know much about how vector art work together with LW6, but I
> think it could look cool if the pre-defined colors were used to
> colorize different parts of the vector.
It will, don't worry. It's mandatory, I just won't implement anything that
does not use the colors picked from the map (the ones used by the menu).

> It might be cool if a graph showed how the game had progressed at the
> winning screen:
>
> http://img200.imageshack.us/img200/1795/winningscreen.jpg
That's a hell of a good idea! And not so hard to implement, I "just" have
to keep a record of teams repartition on a regular basis, and voila!

I'll try and manage to make a video capture of current code, scrolling and
zooming look nice ;)

Have a nice cay,

Christian.

-- 
Christian Mauduit <address@hidden> - http://www.ufoot.org/ ___ __/\__
Liquid War 6 - http://www.gnu.org/software/liquidwar6/     / _")\~ \~/
"Les amis de la vérité sont ceux qui la cherchent et non _/ /   /_ o_\
ceux qui se vantent de l'avoir trouvée" - Condorcet     (__/      \/