Archive for November, 2004

Webdesign Issues

Thursday, November 11th, 2004

Problems and Workarounds concerning Webdesign

Abstract

The Tao of Webdesign. Well, it’s there, its XHTML strict with
CSS. Sad that some browsers just can’t work with it or have
severe bugs. So I asked myself the question, what public do I have,
and which browsers do I have to support? Support, in a sense of
“it has to be reasonably useable an readable”. Specifically, one
Question was whether enough (more than 1 percent) of people will
be using very old (and broken) browsers like Netscape 4.x or MSIE 4.x

The Browsers

For determining the capabilites of browsers, it was necessary to decide
what browsers would have to be looked at. So I assembled some data
from October 2004 on swiss Webpages.

A statistic from a high-traffic sports-tournament page. This gives us a
hint on what the majority of unsuspecting users will use. Note that this,
as a sports-event, will necessarily not be a representative sample of the
whole population, as it is to expect that a whole lot of people are not
interested in sports at all, or not interested in that specific sport;
thus probably under-representing certain groups of people (thought to
be the technical and the scientific community, for instance).

MSIE 6.x	84.23%
MSIE 5.x	 8.25%
Mozilla		 5.37%
Opera 		 1.37%
Netscape 3/4	 0.31%
MSIE 4.x	 0.10%

And one from a medium-traffic tech-news site. The Site is moderately
technical and covers also socio-technical problems or politics related
to technology. The sample is thus heavily skewed towards technically
proficient people and early adopters. But having the early adopters
in there makes it very interesting as a foreshadow of future development.

Mozilla		39.67%
MSIE 6.x	30.41%
kHTML		 3.99%
Opera		 3.49%
MSIE 5.x	 2.01%

We thus conclude that Netscape 4.x and MSIE 4.x are practically dead,
and given the brokenness of those browsers, not worth the effort of
supporting at all.

As general trends we can thus conclude that MSIE 5.x will fall below
one percent in maybe a year or two, getting replaced by more modern
browsers. Support for MSIE 5.x should only be done if its a small
effort and does not interfere with other browsers. On a small rise
seem to be Opera and kHTML (the latter a library used by Konqueror
and Safari), definitly worth some support. The big hunk of people
right now is using MSIE 6.x, so that is the main target, along with
its contender Mozilla which might well surpass MSIE in the future.

Another point is the relative standard-adherence of the browsers.
While Mozilla, Opera and kHTML strife for maximal W3C-compliance
(and are sometimes very close to achieve it), this cannot be said
for MSIE. Since the future of MSIE is largely unknown (Microsoft
talk about a new version some time in 2007); the only sane choice
is to adhere to the standards as much as possible. Specifically
writing web-pages for MSIE 6.x seems short-sightened in this light.
Due to the large installed base however, MSIE 6.x justifies for
specific adjustments and bug-workarounds.

Standards

Given that there not only are standards, but those standards are
evolving and mostly implemented in the browsers, it makes sense to
adhere to the standards; and to adhere to the most strict version
of it (the transitional-versions are, well, for the transition of
pages from an earlier standard in order to simplify work). Well,
but there is not only one standard, but many.

There is, for instance,
the old HTML 4.0 which was surpassed by XHTML 1.0 (essentially this
would be HTML 5.0). And there is not only XHTML 1.0 but 1.1 and now
2.0. According to the recommendations of the W3C
XHTML 1.1 is a modularized version of XHTML 1.0; and XHTML 2.0 is
something completely new and incompatible to anything else. Given
that browsers don’t understand XHTML 2.0; I can’t discern the differences
between XHTML 1.1 and 1.0 and given that the W3C itself uses mostly
XHTML 1.0/strict, XHTML 1.1 and 2.0 can only be viewed as work-in-progress
or proof-of-concept which right now aren’t worth the trouble to implement.

When using XHTML 1.0/strict, we’re bound to only make layout-changes
through a Cascading Style Sheet (CSS). Now, there are different versions
of those as well. There’s level 1 and 2.1; and level 3 in development,
and not all browsers support all elements of level 2.1. Luckily all
relevant browsers support level 1. The choice making sense is to use
CSS level 1, with selected elements of level 2, and to ignore that some
features like :after and :before do not exist on MSIE 6.x; they aren’t
really of big importance, the layout will look a bit different, but so
what.

Bugs

This is a bit MSIE 6.x-heavy, but what do you expect? Pretty much
all of those are documented on
Position is Everything
. Of course I ran into several of them; one of
them seemingly not turning on a horizontal scrollbar while positioning some
text WAY to the right instead of just 350 pixels.

Peter Keel,

2004-11-11

Fighting System for Computer-Games

Thursday, November 4th, 2004
Realistic Arms- Armor- and Fight-Models

Abstract

Most action-games, even the ones set in fantasy-environments
concentrate on ranged weapons, or do have only a very limited support for
non-ranged weapons, limited moves, thrusts and slashes. More so if they’re
first person perspective. Most RPGs on the other hand just display some
pre-defined moves, according to whether the agent hits or not, which
in turn is mostly defined by the stats of the agent and some dice. This
essay will present you with an action-oriented alternative combat-system for
first-person perspective-games

Premises

Real medieval hand-to-hand-combat is completely different than what
ever is depicted in movies or computer-games. The aim is to incorporate
these realities into a game-engine.

  • Armour is as light as possible, designed to be as much as
    protective as possible against specific threats and weapons. Chain mail
    for instance was designed against slashes, but not against thrusts.
    Armour is also nearly impenetrable against those specific threats. You
    cannot, for instance, pierce late medieval plate armour with a bow or
    light crossbow.
  • Arms are as light as possible as well, and change with time
    to accomplish a very specific goal, to inflict damage to a very specific
    target. A flail is only useful against opponents wielding shields, but
    in that case very much so, because you can hit them behind their shields.
    A lucerne hammer won’t inflict more damage than a sword, but is able to
    penetrate plate armour, thus only appeared with the appearance of plate
    armour.
  • Style arms and armour dictate how you are able to fight. You
    can’t just bang on plate with your sword and hope to break it some time.
    You could try to thrust into weak spots instead. There is no “parry” or
    hard block with weapons, instead real medieval combat focuses on
    counterattacks or avoidance.
  • Damage is primarily done to the opponent. The chance of
    damaging the armor in a way that it isn’t protective anymore is
    about null. But the armour will afflict your damage if not cancel
    it altogether. As part of a simple damage-model, fatigue could be
    used, thus making wounded agents slower. In extreme cases, limbs
    could be severed, limiting the physical possibilities of the agent
    further.

[If you’re objecting now, you’re probably wrong. If you’re not
practicing medieval armed combat and regularly wear armor, you most
certainly are]

Needs

Here we look at the technical needs to incorporate this into a game.

  • 3D-Engine Most basic. Mort probably any good one will do,
    focus on large seneries is best, as well it should be able to handle
    a great many objects with different textures (or shaders to accomodate
    for the lack of textures).
  • physics-engine is probably the most important part. Not only
    it has to apply phisics to normal objects, but also to players, and most
    importantly to weapons as well. It also needs the capability to define
    objects which can damage other objects, namely cut and pierce according
    to with which force/speed it is applied.

How it works

For ranged weapons, its simple. You target preferably a weak spot of
your opponent, and on a hit, your arrow or whatever will maybe hit some
armour, pierce it or not, and inflict a wound.

For hand-to-hand combat, you use your mouse. left button slahes, right
button thrusts; and it does it when you release the button, thus making
it possible to direct the weapon with movements of the mouse while holding
down the button. Its possible in that way, not only to direct your weapon
exactly to where you want to, like a thrust into the eyes, but also to
counter a thrust with a slash.

The weapons will of course have different mass and impact, thus making
it possible to pierce a plate armour with a lucerne hammer, or to thrust
through chain-mail with a one-and-a-half-handed sowrd.

Fatigue will be essential, making people wearing heavy armour or other
load tired and slow down very fast; opening the possibility for lightly armed
fighters to win nevertheless, even when one has to hit one small weak
spot in the enemys armour.

A further idea for more realism is that, poeple having mass, you can
define that some armour has sizes. Maybe three sizes for chain mail,
but very fine-grained sizes for plate armour. This way, most plate
armour found would be useless and could only be sold. This also balances
the inflation of armour.

Examples

To slay a wolf, you just target the wolf, go near enough and thrust or
slash anywhere. You could target the head or try to sever one of its legs.
The wolf isn’t armoured, so it doesn’t matter too much where you hit.

To fight a barbarian which wears a chain mail gets a bit more
difficult. Will you try a thrust to his head, or maybe a slash to his legs,
where he is unarmoured? Or maybe just thrust anywhere, in the hope your
long sword is able to pierce his armour?

The knight in plate armour is a very dangerous opponent. You could thrust
to his axles, or maybe run around him in order to make him tired (and then
thrust), run away, and so on.

Peter Keel,

2004-11-04