A reflection on game styles in CRPGs

blog entry posted by lalo (Lalo Martins) on 2009-01-15 03:20:00

Tags:

This is an attempt at a taxonomy of style choices I've observed in CRPGs (I still refuse to call the game genre “RPG”; a game is not an RPG unless it in any way involves playing a role). This is based on “old-school” games I've been playing most of my life, on “massively social” games that have been popping up recently (and a nod to those that aren't CRPGs as well), and on second-hand accounts of MMORPGs, which I personally haven't played enough to form opinions on.

Special attention is given to how these choices affect the design of Crossfire 2.0, and other future projects I have planned.

If you first need an introduction, refresher, or fact-checker about the “scene”, I'll make a somewhat heterodox recommendation: Sluggy Freelance's Years of Yarncraft storyline is an in-depth, insightful, and accurate, if not serious, look on the whole thing. It doesn't cover the “massively social” phenomenon, but I hope I will do that in the article.

Player styles

I'll start with player and playing styles, because I believe understanding how people play a game and how/why they enjoy it is necessary before you can even discuss the rest.

Bear in mind, like most taxonomies when applied to people, most of my classifications below are talking about primary traits; most people will be a combination of different types, either by combination, or over time (like, on different days you may be an explorer or a role-player).

Primary activity interest

A very, very long time ago, people who played actual RPGs (nowadays relegated to being called “tabletop RPGs”, sigh) first classified players in two basic camps: the hack-and-slash camp, and the roleplay camp.

Over the years, and as we got acquainted with CRPGs and adventures and computer strategy games, this was refined, expanded upon, simplified again, and distilled. Today, while there are many ways to make this distinction, which are certainly valid in their own ways, I believe a simple split in four groups is the most useful, in terms of understanding and designing games.

So I call players either: gamer, hack-and-slasher (H&Ser), role-player (RPer), or explorer.

Hack-and-slashers are in it to fight. Nowadays, that doesn't necessarily mean actual in-game fights; rather, H&Sers like to win. They get fun from the game primarily by enjoying the rush of victory and superiority. In a classic CRPG, the easiest and most rewarding way to do that is by combat.

The key aspect to please H&Sers is challenge/reward: it must be relatively easy to find something that challenges them, the challenge can't be too easy, it can't be impossible, and the reward after winning must be proportional and appropriate, in order to trigger the reward pleasure centres.

You can alienate H&Sers with limits. If, for example, they can only run so many fights in a day, your H&Sers will probably just create second/third/fourth characters, or abandon the game after a short time. If they defeat everything you throw at them and then there's nothing more to fight and they need to wait a day, or three, or a week before there's more, they will probably not log in at all during this period, and there's a chance they will have discovered something else in the interval, which means you lost the player.

Role-players are run by imagination. They want to “be” someone else and do things they wouldn't do in real life. They really care about the character. They also form a mental opinion of the character's personality and preferences, and try to make choices according to that.

The key aspect to please RPers is believability: they must be able to suspend their disbelief when they start playing, and stay in their imaginary world until they decide to leave. Anything in the game that pulls them back to the real world is a disruption to that “flow”. Believability is not the same thing as realism; realism is just one of the ways of doing it, but it would be boring if all games were realistic; many (most?) RPers go to the games precisely in search of some “believable” fantasy. My personal “three pillars of believability” are internal consistency, depth, and detail; I'll expand on another post if there is interest, but I think it's pretty self-explanatory as it is.

You can alienate RPers (other than the lack of the above) with simple discouragement. RPers are a relative minority, and many other players think they are a bit weird. Every time you remove a feature that benefits RPers, or add one that hinders them, their interest will wane. If players are allowed to openly discriminate against them, they will leave. A good strategy some games adopt is to offer separate, RP-focused servers where RP is mandatory.

Gamers see the whole thing as a game. Which, technically, it is ;-) A gamer enjoys looking for edges and tricks to optimise the character, the overall strategy, battle tactics, economics, party/guild workings, everything.

The key aspect to please gamers is strategy: there must be cool, useful, and difficult to find tricks. There must be a wide range of possible strategies. But to avoid alienating the other players, it must be possible to play the game without them. It's also a good idea to “shake things up” occasionally; change the rules so that some strategies get nerfed, others spring up, and the gamers have to look for the new ones. They'll complain, but it won't be sincere; while they do have an attachment to their painstakingly-develop tricks, they have more pleasure in finding new ones than using what they have.

You can alienate gamers with ephemeral rewards. For example: say you offer a way to greatly improve weapons. Say it's either hard to do, or expensive; and say it's relatively hard to find. That's the kind of thing gamers love. But then, after a lot of effort to improve his sabre, he discovers that your game mechanics require changing weapons every few days. So now, all that effort is wasted.

Explorers want to see your game. They want to see everything, try everything the game has to offer. There are subgroups, of course; some want to see the whole world, some want to play every single last quest, some “collect” items, some want to understand the underlying story, some want to play many times with every possible class (or profession or whatever the equivalent).

The key aspect to please explorers is rich content: this one is a no-brainer :-) the more there is to see, the more they'll like it. But it has to be interesting; if every town looks the same, they'll stop by the 3rd or 4th.

You can alienate explorers with too much or too little obstacle. If I can simply create a character and explore the whole world, I'll have fun and maybe even write you a good review, but I will also drop the game after a few days. On the other hand, if I can't explore anything new for a whole week, I'll get bored and leave as well.

An interesting way to put it is that each of those 4 groups “plays with” a different portion of the brain. The H&Ser plays with the instinctive pleasure centres, the RPer with the imagination, the gamer with the intelligence, and the explorer with the curiosity.

Finally, there is of course a fifth group: those that aren't interested in the game itself, at all. There are many possible cases here; some people play MMORPGs and “massively social” games primarily to “meet” new people, or to chat. Others like looking at the game, because it's cute or cool or whatever; although those either don't stick around for long, or evolve into a specialised sort of “explorer”. Some play because they like the setting; this is especially the case for games that are adaptations of known fictional settings. Again, those players either leave after a while, or drift into one of the other categories.

The social spectrum, for the player

A very important point is how much each player wants to interact with others. Some want to play alone to the maximum extent they're able; others are in the game primarily for the social aspect. In the middle of the spectrum, players will like to do things in teams (or parties), will want to join guilds, use in-game chat, ask other players for help (possibly in a forum/message board), and interact with other characters in the game knowing there's an actual person behind them.

From a strategic point of view, it's a good idea to encourage social interaction. If I play on my own, it's not a big deal if I don't play for some time; but if I have a few “game-friends”, and I grew used to chatting with them every week, or every day, or whatever it is, then I have a reason to come back; I wouldn't want to “miss” my game-friends.

To quest or not to quest

Good quests are one of the best tools of the trade. It's what turns a game into a medium for interactive storytelling. However, the plain, harsh truth is that some people don't really care about your story! Some people want to be able to enjoy the “regular” things to do in the game, and stay away from the quests, or do them just as much as absolutely required. Again, it's a spectrum; on one end, some players completely avoid quests, while on the other, they play for the quest and only do other stuff in order to “support” the quest requirements.

Wait, what? Some people like doing the day-to-day character maintenance more than quests, or even to their exclusion? It's easy to fall in the trap of assuming the day-to-day stuff is boring; but in reality, people are different and have different tastes. True quote from a real person in my tweeter feed today: “I hate when my routine gets disrupted. Life without routine is totally boring and not worth living.” I was amazed at first, but upon reflection, it just proves my old core belief that people are different; and it matches my observations of game players. Some really do come back every day for the maintenance routine, and find quests a disruption.

Worker vs. fighter

In the “massively social” CRPGs that are popping up online recently (I'll offer Travians as an example that I actually like playing), you have other things to do than going around bashing people's teeth in.

Now, on many MMORPGs you can do other things as well. The stories of “gold farmers” in WoW are a famous example; real-life sweatshops with people connected to the game making in-game items in an in-game sweatshop. But in most games, those activities are second-class; you can't be a level 70 tailor or miner, for example.

To explore the case of Travians, it started up not so much as a CRPG, but a kind of RPG-ified “The Sims”; just like “The Sims” was originally a toy to spy in more detail on the life of citizens from Sim Cities, and later grew to oversell its “parent” game by far, also Travians grew out of another game by the same company, called Travian (yeah confusing... but the company is German, and in German Travian is called Travian, but Travians is called Travianer, which is... well, slightly better). Travian is a strategy game, a kind of massively-multiplayer Catan/Civ. Then along came Travianer/Travians, where you get to play one of the actual citizens.

The funny side-effect of this story is that, although there is fighting aplenty and a quest, the main focus of Travians is not to fight, but rather to be a productive citizen. You harvest one of the primary resources from Travian (clay, wood, ore, or grain), or you process them into secondary resources (bricks, boards, coal, iron, flour, bread). Fighting doesn't reward you with money, only experience; to get money you need to work. (But if you really, really want to be a bum, you can live off of digging up treasure in the swamp.)

This experiment (and the success of Travians) brought a realisation: some people like doing things other than fighting. Some people like putting the character to work, or figuring out the complexities of trade.

And frankly? After the success of The Sims, we really should have figured this out earlier.

Simple vs. rich (or, dull vs. complex)

Complexity in a game is a tough issue. Complexity comes in all levels: quest, rules, user interface. Make it too simple, and many players will be bored; and, of course, you won't attract any “gamer” players. Make it too complex, and many players will be bored, or confused.

Personally, I'm a follower of the school of making complexity optional. Offer a very simple version; the easy-to-find quests, the basic rules, the default UI. But also offer layers and layers of extra complexity the player can opt in to: extra quests or side-quests that, preferably, tie into the main quest and enrich its story; additional corner rules for special, rare items, or for advanced classes, or something; optional elements in the UI that can be configured.

And then there are wizards. This is complete guesswork on my part, but from observation, I believe people who prefer to play magic-users, also prefer a little more complexity. It makes sense; understanding large spell lists, with the reward of having more options of action, as opposed to getting a weapon and bashing stuff — that's clearly a complexity choice.

The trade of trading

Trading is a human pleasure. Like most human pleasures, some people abhor it, others can't live without it.

In most CRPGs and CRPG-alikes, some form of trading is required. In Crossfire, WoW, or even old-school Diablo and Ultima, you'll get random stuff from questing, stuff that you don't want but that is worth money; on the other hand, some items you'll never find, or you won't find often enough, so you'll have to buy instead. In Travians and others, you need to actually produce and sell things in order to make game money.

But from that, sprung a funny tangent: some people like doing it. Some people enjoy looking for the best price, or even finding ways to make profit out of buying stuff in one place and selling it elsewhere.

I'm told in the Korean MMORPG Ragnarok Online, playing a trader is actually an option. It's still somewhat limited, as you still need to fight in order to level up; but it's an added choice, and apparently, lots of people actually go for it. I'd like to see a CRPG where fully playing a trader is an option; your goal is actually to make profit, and you level by making good deals. Or rather: I'd like it even more to write it ;-)

Game model styles

Time is money

A trend that is integral part of the “massively social games” phenomenon is limiting how much you can do based on time. Generally, that's done using some sort of points that regenerate through time, and which you spend to do some of the things in the game; Travians has “occupational points”, and Imperial Galaxy has “command bandwidth”, for example. There are ways to get bonuses to produce these points faster; in Travians you get more OP if you sleep in better beds, while in Imperial Galaxy it's basically a matter of keeping your “home sector” clean.

Strategy and building games use more resource-centred techniques; in Nile Online and Travian, your limit is how fast you can harvest resources that are needed as materials to build stuff. Also, each building takes a fixed time to build, and you can only have one construction going on (per city) at any given time; so if my current palace upgrade takes 12h, that means I can't build anything else on that city for the next 12h.

The purpose of these limits seems to be twofold. On one side, you want to avoid giving compulsive players that have no lives a very big advantage, because that drives everyone else away. But also, these daily limits are an encouragement for players to come back every day and do a little more.

This is a hard choice to make. And personally, I think there's an enormous risk of limiting it too much and becoming annoying; everyone I know who plays Travians agrees there aren't enough OPs in a day.

In some games, the limit can also serve to encourage players to explore other aspects; in particular, the more social aspects. But doing that well requires your limits to be partial (not affect the social aspects — Travians fails in this point), and more importantly, it requires the other aspects you want to emphasise as an alternative to be well-developed and interesting.

Specialise or balance?

This one has been an ongoing argument in Crossfire for as long as I can remember.

Some games strongly encourage you to build an all-rounded character. In Travians, for instance, I tried to ignore the combat aspects at first, but quickly found myself unable to complete quests. Then, still unwilling to split my (limited) attention, I decided to focus on combat; but after a few days, weapon upgrades became too expensive for me, and now I need to spend a few more days upgrading my tools. So their system essentially forbids focusing.

On the other side, MMORPGs usually encourage teamplay by giving strong benefits to cooperation between differently-focused characters; the typical successful WoW party requires (at least) one or two tanks, one or two damage-dealers, a spell caster, and a healer. (The typical D&D party adds to that recipe one trap finder and one leader.)

In Crossfire, focusing is good on lower levels, but the usual complaint is that pretty much all level 100 characters are identical (or possibly, can be divided into dragons and non-dragons).

It's all about choice

There are different kinds of players, with different preferences and styles. Do you try to allow all styles, or do you focus your efforts on pleasing one category? Both are valid choices, especially if development resources are very limited.

If you think this section is too short, feel free to re-read the first section of this post, Player styles, and reflect on all the game model choices hidden in there ;-)

The social spectrum

The new batch of (mostly web-based) “massively social” games is all about interacting with other players. While Imperial Galaxy can be played solo, it's frankly not a fun game if played that way; the fun is all in belonging to a fleet. Travians has huge benefits for guild membership, it has “Community Actions”, “Social Points”, and the best ways to acquire experience are fighting in the arena (against other players) or playing mini-games (against other players). And you make money primarily by selling goods on the market (to other players). Nile Online is pretty much impossible to play without making heavy use of the market; and god offerings benefit an entire nome, and are really hard to make on your own.

These games also incorporate a measure of social networking technology, with friend lists and features that depend on them, integrated messaging systems, and heavy use of chat.

On the middle of this spectrum lie most MMORPGs, where parties are necessary to complete most quests, and guild membership offers big, but not overwhelming benefits.

In the web-based arena, most Facebook games offer big, but optional benefits for players who have large numbers of other people in their in-game “team”; however, this is more an incentive to invite people to install the game, than an actual social aspect.

Then there is Spore, and its amusing moniker of “massively single-player”. It allows you to interact with content created by other players (which Sim City and The Sims already allowed, although it was a little more difficult). An earlier, and possibly better, example of this approach is the Pokémon (portable) series; the game is primarily single-player, but there are great benefits and strong encouragement to interact with others (for trading pokémon or PVP battles).

Starting from zero we've got nothing to lose

In Years of Yarncraft, Pete Abrams pokes fun at this aspect, by having Torg's character start the game armed only with a stick, and having to kill a bunch of salamanders as his first quest.

How low do you want characters to start? The traditional answer, until relatively recent times, was that a starting character had to be reasonably capable, enough to entice and interest the player. But now, the trend seems to be starting very close to zero. And if the game offers a lot of choice, that may actually be a good thing, because then you won't have to make some of those choices until you have a better understanding of their effects.

Of particular interest to this aspect is the trend of making the first few quests a tutorial of sorts, teaching some of the most important things in the game. Travian plays this card heavily (possibly a little too heavily; you don't want people to feel patronised).

This also ties in to game mechanics choices (which I'm covering in the next post) about character growth and the meaning/algorithms of attributes and skills. It's common in simpler games to start all attributes at 0, which means normal human average, and then simply add to them a number of points per level, without any real final cap.

Those pesky economics

All RPG-like games must include some sort of an economy. In single-player games, that's traditionally just a question of making sure more powerful items are more expensive, while at the same time your ability to acquire game-money increases as you progress. Additionally, different items would be available for sale in different areas of the game world.

Then, simulation-heavy games and procedural content came along, and it became fashionable to try to achieve a “real economy” in the game world. I have personally not played a game that does that, or even seen positive reviews about one, so the benefit seems questionable.

But there's something better than a simulated “real” economy: a real real economy. Travian, Travians and Nile Online have all succeeded in doing that, Nile to a much greater extent. Quite simply, if most (or all) trading is with other players, and you have a sufficiently large number of them, soon real market factors will emerge, and in a way that players can understand without too much effort.

Maybe the ideal best is a mixed, real/simulated “real” economy, where player purchases have a strong (primary even) influence, but where items that players aren't really interested on can also fluctuate, as NPC demand for them grows and shrinks due to simulated or player-caused events. But the reason those web-based games have succeeded in creating an actual economy is one that may defeat this point: simply, those games have staggering numbers of players — thousands upon thousands online simultaneously at any given moment — which is enough population to simulate the economy of a small village.

On a side note, someone linked a very funny (but true) article about RPG economics to #crossfire earlier in the week. While the article is about D&D (and other “tabletop” fantasy RPGs), it mostly applies to CRPG as well.

To be continued

All right... I ran out of time and brain power :-) and I'm afraid nobody will bother to read this if it gets any longer than it already is. In a few days time, I'll write about game mechanics styles, and story/setting styles.

Automagically-translating chat thingy

blog entry posted by lalo (Lalo Martins) on 2008-12-19 20:23:00

Tags:

Usually, I have to communicate with the people in the building's management office via Google Translate. It works, but it's awfully painful to be constantly flipping the language drop-downs back and forth. (It's two drop-downs, one for source and one for target language.)

So I wrote a little javascript gadget that does the hard work for me, and also keeps a “log” of the conversation. You can peruse it at http://lalomartins.info/transchat.html

(Attention though: this is not a chat app, not in the modern sense. It's “chat” in the old-school sense, of actually talking to a person that's in front of you. It's... an interpreter widget, not a chatbox :-) enjoy and spread if you wish...)

XML considered harmful, or,

blog entry posted by lalo (Lalo Martins) on 2008-10-25 15:37:00

Tags:

I have, on a number of occasions, stated that XML is harmful, and should be taken out and shot. So here I am today, to explain why I think that, and offer alternatives.

Not good for humans

The main problem is, of course, that XML was never intended for humans. It's not designed so that we can efficiently write it, read it, understand it at a glance, or maintain it. But many tools that use XML today tend to forget that, leading to hours of wasted time and lots of frustration. (XML for configuration files, anyone? Zope's ZCML and .Net's configs and all those Java frameworks?)

Then, of course, that's not XML's fault; it was never designed to succeed at that task. The fault lies with developers who misuse it. Well, yes and no. The reason people misuse it is because it's overhyped; XML is the new peanut butter (or garlic butter, according to Pete Abrams) — adding it to anything makes it taste better and sell more. (I don't even like peanut butter.)

Not good for machines

What it was designed for is communication between programs; an unified, extensible format for data transmission. By having libraries to handle it in most languages and environments, you'd make it easy for developers to deal with it, and as a consequence, to make their programs communicate.

However, after roughly ten years of working with it, it is my informed opinion that XML fails at that, too. I'm not saying it got supplanted by better technology which we invented later. It did, to be fair. But what I'm saying is that it was wrong from the beginning. And if it's not good for us and it's not good for our programs, why are we still using it? (Peanut butter, I know.)

So let's try to break out of the hype and prove that it's bad for our programs.

The perceived problem with XML can be summarised in one sentence: XML is costly to parse. But that's too superficial; let's go deeper, look at the specifics, and the flaws in philosophy/design that lead to this perception.

Parsing XML: layers

I usually tell my co-workers that there's two “layers” to parsing XML. While that is true, it's only true in the context of our data; if I were to make that statement more generic, I'd say: there's always at least two “layers” to parsing XML.

The first, the “bottom” layer if you want, is syntactic parsing. This means reading XML itself: tags, entities, attributes, comments, CDATA, PCDATA, white space, the works. The input to syntactic parsing is a string or stream of bytes; the “output” is an API — SAX, DOM, ElementTree, you name it.

On the opposite end of the stack, the “top” layer so to speak, is semantic parsing, or extracting the data you're actually interested in. The “input” here is a generic API; in the typical case of two layers, the API from syntactic parsing. The “output” is a domain-specific API or, more commonly, a collection of structured data (usually objects, nowadays).

An example where you may have more than two layers is when you're using something else built on top of XML; the most common case being feeds. So at the bottom layer something will parse XML, then another chunk of code will parse that as RSS or Atom, and then your semantic layer will actually extract the data. At work, we initially made our data available as RDF; so we had a second, “middle” layer (we actually used a JavaScript RDF library) which would parse the RDF, and then we did our semantic parsing by using the RDF library's API. That made our code a lot simpler, but it also made it a lot slower; so we later switched to ignoring the RDF and simply treating it as XML. (Even later, we switched to a JSON format.)

Syntactic parsing: too much structure

Syntactic parsing is what XML is supposedly “all about”; the point being, you don't see it. In our case, at work, it's done by the browser (which gives us DOM with a touch of XPath). In pretty much any other case, it will still be done by your environment (the browser, in our case; JBoss and .Net are other examples), or by a standard library.

Well, that's great, right?

It is, yeah. But it hides the fact that those libraries (even if it's “hidden” in the environment, it's still at some level done by a library) tend to be huge and ridiculously complex. The XML syntax is designed to cover an enormous universe of cases that your program will concretely never encounter, and yet, you have to pay the complexity cost for them.

Semantic parsing: not enough structure

XML shines on xHTML: a markup language for text, where you have arbitrary streams of text sparkled with special instructions about it. Some of those “instructions” are really containers, which have more text and instructions. XML does that really well.

It shines a little less on something like SVG, where it represents arbitrary streams of heterogeneous objects. Some of those contain other objects, and XML does help there.

But the truth is that, for representing your program's data? It probably sucks. Its model is very different from the object model of most (all?) popular languages and frameworks today. In the end, we find ourselves designing our data structures as many as three times: once in the language in which we're actually writing it, one in a relational database, and one in XML. The mappings between them are often poor, since the semantics of the three models are so poorly matched.

Sadly, it would be relatively trivial to pick a lowest-common-denominator model that would fit all of today's popular languages. But XML didn't even try.

That's not the whole of my objection, though. Due to the MASSIVE FAIL in the syntactic layer, we get a semantic layer that's only marginally simpler than it would be to parse a DSL (domain-specific language); maybe less simple, if you use a good library for your DSL. There are about half a dozen XML APIs in wide use; smart people are frequently getting annoyed at the ones already there and coming up with a new, better one. And although a modern offering like, say, ElementTree can be light-years ahead of SAX or DOM, it can't help being clumsy and feeling unnatural to the language; at the bottom line, what it's doing is dressing up a rotting corpse.

Conclusion

Here's a better phrasing then, for the problem of XML as I see it:

XML has too much structure where it doesn't help, and not enough where it matters. One of the reasons I love JSON is that it's not designed to mark-up text, or to transfer “streams of data”; it's designed to transfer objects (JSON means “JavaScript Object Notation”), which means it maps nicely to my code on both ends, whether that code is JavaScript, Python, C++, or even C. (It maps nicely to Java as well, but who cares.)

Alternatives (existing and ideal)

Right now, for real-life code, most places where you're using (or thinking of using) XML would probably be better served with JSON. A few more complex cases may justify a DSL, but I would hesitate a lot before going down that route.

Ideally, I'd like to propose a new format; an “active” derivative of JSON, inspired by the modern practise of “JSON with callback”. Essentially, I'd like to replace JSON's “flat” object notation ({'attr1': 'value', 'attr2': 'value'}) with something which looks like a Python constructor (MyClass(attr1='value', attr2='value')). The pseudo-classes (or pseudo-functions if you're looking at it from C) would play the role that tag names play in XML elements, which would make it even more straightforward to map this data to actual objects on each end.

This would, of course, lose the benefit that “JSON with callback” can simply be executed in a browser. But then again, “JSON with callback” is not formally correct JSON anyway, so we already sacrificed some portability for that ability. “Real” JSON is usually converted to “JSON with callback” by a simple routine on the server side. A similar transformation could convert the format I'm proposing into JavaScript; the fragment above would become: MyClass({attr1: 'value', attr2: 'value'}).

Mass unblocking in the Great Firewall of China

blog entry posted by lalo (Lalo Martins) on 2008-08-02 22:13:00

Tags:

Seems a batch of sites got unblocked. Wiki.edia (marvel as I blog in regular expressions) is accessible (again), Wikibooks, Reuters, CNN, and a lot more.

Still blocked: blogspot, livejournal, wordpress (no surprise here -- lots of political blogs), BBC, certainly more; most importantly, Sinfest and CRFH :-( (why the f* is CRFH blocked? Zombies? Satan?)

Also, the web feels slightly faster in general!

The Ballad Of Sir Href

blog entry posted by lalo (Lalo Martins) on 2008-03-26 16:03:00

Tags:

It goes like this...

Take a page from Arthur's book
Join this body august most
Take seat at the round table
Where no knight a row will brook
Remain strong but never boast
Proper form makes you able
The Elysium Fields to fill
And submit all to your will
With your style and your skill.
older posts