Das Tal - PvP Sandbox MMORPG
20
Sep
Patch Notes for Alpha Playtest #9

This has changed in between Alpha #8 (14.09.14) and #9 (21.09.14):

New Features

  • Developed a completely new ability system scripted in LUA. Allows for different ability shapes, proper effect stacks and generally more cool shit.
  • Added the totem as a new weapon set.
  • Added / reworked 28 abilities: Each weapon and amor set now has four unique abilities - the existing 12 abilities have been reworked and 16 new ones have been added. 

image

  • Added an ingame menu to reports bugs & feedback (press F3 or click the button).
  • Added UI that shows your current health and energy (de-)regeneration.
  • Added UI that shows effects that are currently active on you (for example when you’re snared or invul).
  • Added speech bubbles for local chat (positioning still slightly buggy).
  • Added energy costs for abilities to their popup information.
  • Abilities are now marked as unusable in the skillbar when you cannot cast them due to insufficient energy ressources.
  • Added “press RETURN to chat” info to the chat window.

Balancing

  • The 3rd and 4th weapon abilities now are bound to the Q and E buttons on your key board. Armor skills are 1-4.

Fixes

  • Fixed a null pointer that occured during the last playtest.
9
Sep
Das Tal’s Backend & Exit Games’ Photon

It’s been quite a while since the last technical blog post. This time the topic is our backend. I will give an overview of our infrastructure and write in more detail about our game server which is based on photon server.

image

Be aware that this is just our way of doing it. If you have an opinion or comment about any of this I would be happy to hear from you.

A little background on the game design

Our game is designed so that we have lots of different small, isolated game worlds. We are talking about 1k - 2k registered players with 100-200 CCU (concurrently connected players) on one world. The reasons for the size are that we want to time-box worlds, have intimate player communities (within one world) and that we want to keep the technical complexity as small as possible.

The core gameplay is focused around a very fast and twitchy gameplay.
So we are somewhere in the middle between a bunch of Counterstrike servers and  a “classical” WoW-like MMORPG structure with a huge world made of connected instances. Here is a gameplay example:

A birds-eye view on the infrastructure

This is an overview of the services that are somehow related to either the live operation of the game or its the development. Most of the services are already up and running although some only exist as dummies.

image

LIVE

DEV

A lot of these services are quite straightforward. Most MMO-like games have them - although probably in different tastes.

The game server

All these parts are important but the heart of all this is the game server. After evaluating different things we decided to use Photon server.

Mainly because we can easily share code between server and client (C#), because it is fast and well established. During pre-production I wrote a little bit about the game server middleware evaluation we did. 

Overview

image

Our game server is a fully authorative server. The core game loop (simulation) runs at about 15 ticks/second. Because multi threading is incredibly hard we decided to limit the core game loop to just one thread. Designing and maintaining a single threaded game loop is much easier. There will, for example, be fewer strange timing bugs during high loads (like duplicated items).

The downside of this is that our core game loop can not scale horizontally and we will finally hit a point where we cannot scale-up one game world anymore. But our game worlds are small by design so that’s OK.

Other things like network IO, calls to external services, long-running calculations (pathfinding) or saving the world data run in different threads. Actually all these things run as a fiber using Photon’s internal fiber implementation. 

We use a 2D grid index for client interest management. This is necessary to reduce traffic and CPU load to a manageable level. 

Our gameplay is based on the entity system framework Artemis and it uses Farseer for collision and movement.

For small messages between client and server we only use photon’s own serialization (key value list of basic data types). Bigger and more structured/complex data gets serialized by protobuf and encoded as a byte array in the photon protocol.

The game state completely fits into memory. Therefore we just serialize it completly using protobuf and save it into a file. This is only feasible because each game world is small and limited in time and will not exponentially grow.

My tip: Next to the protobuf-encoded file we dump the complete game state as one big YAML file. This way we can easily inspect the game state with just a text editor. No extra tool needed.

All logging is done via log4net which is contained in the photon server. Windsor is our IoC container. 

Our unit test setup uses the Visual Studio Unit Testing Framework and is based on the setup in the photon MMO demo example.

Peer & service interaction

A peer represents a connected client and acts as a gateway to communicate with the player. Each peer has a fibre that processes the incoming and outgoing messages. Basically all peers exist in isolation. Communication between different peers is done using services. For example after finishing the authorization the peer registers at the chat service and can send and will receive chat messages in the future.

image

A peer has a protocol state object that represents its current state in the protocol. So if a client connects and joins the game it goes through these steps (from the view of the client):

  1. Verify that the client version and the server version matches
  2. Login and authorize the client (account service is involved)
  3. Choose a character (account service is involved)
  4. Get skill definition and other global balancing values from the server (balancing file, skill definition service is involved)
  5. Get the map information necessary to download the static map data from an external server (download url, hash) (map storage service is involved)
  6. Download the static map (if they are not already present on the client and the hash matches) (game server is not involved)
  7. Instanciate the map (game server is not involved)
  8. Enter the game(game service is involved)


Game service

image


The game service runs the fiber for the core game loop. It is the gateway between ingame (things running on the game fibre) and not ingame. So if a peer wants to enter the game it calls “gameService.Enter(peer)”. Character movement messages go through “gameService.OperationBodyMovement(peer, movement)”. All these commands get queued up in the game loop fiber and get executed between ticks (calculating one step of the game simulation).

Another job of the game service is to snapshot the current game state (synchronous) and hand it over to the map storage service which serializes and stores the state (asynchronous).

Core gameplay loop

This snipped shows how the tick method gets called within the game service.

public void Start()
{
    …
    // Calls tick each 10ms on the game fiber
    simulationTick = fiber.ScheduleOnInterval(Tick, 10, 10);
    …
}

private void Tick()
{
    // Tick gets called with a higher frequency than the 15 tick/s.
    // So call the realy simluation only if it is “behind”. Normally we run with 15 tick/s but
    // if there is server lag the simulation can catch up.
    if (isActive && tickTimer.IsProcessNecessary(world.Clock.Ticks, world.Clock.Delta))
    {
        …
        world.Clock.OneStep();
        world.TicksSinceLastRestart += 1;
        // artemis system update
        world.EntityWorld.Update();

        // fake lag to testing purpose
        if (serverConfig.GameFakeLagEachNTicks > 0)
        {
            if (world.Clock.Ticks % serverConfig.GameFakeLagEachNTicks == 0) System.Threading.Thread.Sleep(serverConfig.GameFakeLagTimeInMs);
        }
        …
    }
}


The heart of the game loop is the Artemis entity system. The entity system and all code that interacts with it is shared between client and server (the system that handles the game network synchronization is an exception). This is so the client can use the same data structures and methods if necessary. Currently the client only uses data structures and some check methods from the shared gameplay code. Artemis contains systems for the different gameplay parts (eg. ASCharacterRegs for health and energy regeneration, ASCharacterCast for casting skills).

A very important system is ASFarseer. It calculates collision and movement with the help of the Farseer library.

The ASSpatialIndex system contains different spatial indexes based on grids and is necessary for efficient client interest management. There are also special grid indexes to handle the footsteps (eg. protect regions against “footstep flooding”).

The ASNetwork (called “game network outgoing” in the diagram) handles all the game state synchronization with the clients.  This component has access to all the peer instances that are currently active within the game service.

image


The following steps show the interaction of these components on the basis of an example:

Example: A player moves her character and sees the result on the screen.

  1. Client sends movement message
  2. The peer receives the movement message
  3. The peer’s ingame state processes the message and delivers it to the game service
  4. After finishing the current tick the game service processes the movement command and plans the movement on the affected entity
  5. During the next game tick the ASFarseer system simulates the movement of all entities
  6. At the end of the tick the ASNetwork system sends back an ACK message for the processed input messages
  7. Additionally the ASNetwork system sends relevant position updates to the active peers (using the grid)
  8. The client adjusts the local predicted position to the received position

That is all for this week. If you have any questions about how we implemented things or if you have feedback then please get in touch with me at sebi@fairydist.com.

- sebi

5
Sep
Patch Notes for Alpha Playtest #7

This has changed in between Alpha #6 (31.08.14) and #7 (07.09.14):

New Features

  • The character hitbox now resembles the shape of the character more. It should be easier to hit other chars with (bow) shots now.
  • Target preview UI: While casting you see where your ability will hit.
  • Added sound effects while casting.
  • The random clan option now picks the currently smaller clan when login in.

Balancing

  • Increased casting times for most abilities, especially LMB ones. 
  • Decreased staff nuke range (12 -> 9)
  • Staff’s nuke now hits the caster, too.

Fixes

  • Fixed an audio bug that slowed down the client sometimes.
  • Fixed an audio bug that made two music tracks play at the sime time.
  • Fixed a bug that prevented you from running when pressing RMB as a staff user.
  • Made the chat more readable.
4
Sep
Das Tal Gets a Little More Fancy - Audio, Stealth in Cover, Footsteps

Hey guys!

We outlined a lot of this in patch notes, but I wanted to write about the changes that have been made to the world of Das Tal a bit more clearly so that people can understand what they actually affect.

Audio

Music that we had in our art prototype, created by our own composer who will be rejoining the team later in the year, has been added to the alpha build. Along with environment noises such as birds, wind and bubbling tar pit audio and animation, this really adds to the atmosphere of Das Tal. It may be an alpha, but it is important to get these sorts of things in also, so that people can give us feedback on how to shape the mood of the game as we progress.

We have also added some placeholder spell and attack noises. While sounding pretty underwhelming, they allow testers to time their attacks more precisely and tell the difference between one spell and another. Knowing when your enemy casts sprint, invulnerability or a snare can allow for better countering for those who pay attention to the sounds.

The ambiance used in the current build, but recorded in the art prototype. It’s a long story.

Stealth and Footsteps

Stealth in the bushes that are all over the Das Tal landscape is something that a lot of people have asked after, even though it is something we never really mentioned being planned. This feature was in fact in our art prototype, and has now been added to the current alpha build. We tested the new feature last week with a small group, and it is surprising how much it can change gameplay. Stealthily capturing flags becomes possible, as well as setting traps at high traffic intersections or by the flags themselves. There is also the obvious option of fleeing to cover when getting ganked, and evading death is much more possible since this change for the mobile leather armor in particular.

Footsteps are a good way to counter the use of the stealth, so it is fitting that they have been added at the same time. Again, it is people who take notice of the small things, like footsteps leading in or out of bushes who will take advantage of these features. We have already seen in testing that footsteps are a great way to tell which parts of the map are most active, which lets people tactically decide to run headfirst into the battle or try to sneak some flags away from the main group.

The attack and spell noises, as well as invisibility from the player’s own perspective. Which is still technically visible I guess, but if you were in game he would disappear.

This Sunday

All these changes will be there for you guys to experience and give feedback on this Sunday at our regular test time of 8pm CET. If you already have a key, simply come along, you have likely received an email from us already.

Also, check out this thread on the forums if you have been active and want to apply for tester or veteran tester privileges now that we have entered the new testing period.

I hope you are all well,

David

30
Aug
Patch Notes for Alpha Playtest #6

This has changed in between Alpha #5 (24.08.14) and #6 (31.08.14):

New Features

  • Players now leave behind footsteps when walking over sandy terrain. Those footsteps fade out over 60 seconds. 
  • When walking into tall grass patches you now become invisible to anyone outside your grass patch. You can still be hit with skills though.
  • Added ambience SFX, background music and foot step sound effects.
  • Added place-holder skill use sound effects.
  • Added Determination: Being affected by crowd-control effects (root, snare) temporarily increased your Determination stat which will make later CC effects on your less efficient. Determination decreased over time.
  • The tar pits are now animated.
  • Added a new splint mail armor variant to the game for testing.

Balancing

  • You do no longer share your line of sight with clan mates.
  • Decreased energy regeneration (6 -> 5 / second).
  • Increased health regeneration (0 -> 1 / second).
  • Increased default attack DPS by rougly 50%.
  • Increased heal spell HPS by rougly 25%.

Fixes

  • No more weird player shadows when in a tall grass patch.
  • Tar pits no longer block your line of sight.
  • Tweaked the staff casting animations.
29
Aug
MMORPG.com Interview: Understanding the Approach

"Alexander Zacherl is a crazy man. Not in the tweed-wearing, eccentric billionaire sense, but in the ‘I’m going to make a sandbox MMO with only four staffers’ sense. When you hear about studios with hundreds of people and millions of dollars, the difference in scale is astonishing. And yet, for Zacherl and his team at Fairytale Distillery, it actually makes sense.

Das Tal, the sandbox MMO currently in early alpha, is a passion project. As we spoke during Gamescom, it became clear that there’s no other way this game could be made. By focusing tightly on the experience they want to create – small-scale conflict-heavy worlds that last 3 months at most – the studio can pick its battles, yet still provide those alliances and betrayals that the sandbox genre is renowned for.”

So write’s MMORPG.com's Gareth Harmer which we met at this year's gamescom in Cologne for an in-depth interview about why and how we're makign this game. Read on to get all the juicy details about the beauty and madness of making a big game with a small team.

25
Aug
Attack Gaming First Impression

Attack Gaming joined our PvP stress test yesterday. Here’s their first impressions video - pretty cool, huh?

24
Aug
Patch Notes for Alpha Playtest #5

This has changed in between Alpha #4 (17.08.14) and #5 (24.08.14):

New Features

  • the world map now gets downloaded from an external source, no more slowdowns when someone logs into the server
  • added a server list to the login screen
  • added VIP status support for some players
  • attack animations now scale with the skill cast duration

Balancing

  • increased mana regeneration by 50% (4/s -> 6/s)
  • decreased robe heal mana costs (100 -> 50) and healing power
  • decreased quake recast timer (120s -> 30s)
  • splint mail push heal decreased (25 -> 10)

Fixes

  • you are now invulnerable during the get-up animation
  • fixed bugs with the animation IK

Server Hardware

  • increased the CCU cap massively (20 -> 200)
  • moved the game server to a 3.4 Ghz quad-core dedicated server, hosted in Germany
  • These changes are not permanent. More server locations will go online during the alpha test phase.
20
Aug
Rumble in the Jungle: Two Villages Under Siege

Alright. We’ve had four awesome alpha weekends with you guys where we had a lot of fun duking it out in small-scale PvP. Here’s two videos, one made by us and one courtesy of the Serial MMOist.


Rumble in the Jungle

But now it’s time to go big. We’ve just sent out 800 single-use alpha keys for our next alpha test this coming Sunday (August 24th, 8 PM CET).

image

This test’s goal is to stress our game servers. We expect around 100 players to be able to log in at the same time so don’t be too upset if you don’t get in at first. Not everybody will actually make it to the test but we’ll still be over-subscribed a lot. You can also expect a good amount of lag as we’re getting nearer to the current server capacity - so keep your cool if things start lagging out a little (or a lot). 

Our upcoming tests will be less crowded again as we’ll increase our server capacity further and keep the number of invitees a little smaller. 


Veteran Tester Status

As I just wrote, these 800 keys we just sent out are single-use. So they are only good for this one test. Once the test is over you’ll have to wait for us to select you for another test again. This of course is going to get harder as more people sign up for the alpha waiting list.

The keys we’ve sent out to you before today are permanent - so if you’ve had a key before this test you will also be able to participate (and you’ll continue to be able to join our coming playtests).

But so far all of you have been restricted to playing only in the short time when we opened up our game server for the Sunday playtests. This is going to change for some people. We are occasionally going to promote a very small number of testers to veteran tester status - based on their feedback quality and testing prowess. This will enable you to log into the game server 24/7. And even better: It will allow you to log into the server even if we’ve already reached the player cap for that single playtest. 


Development Contribution

So until now there have only been two ways to get into the alpha tests: Get randomly selected from the waiting list or impress us with your community contributions to the game (like signing up for our Greenlight campaign). We’re now working on opening up a third way.

This way will be by supporting our game’s development via alpha funding. In simple words, add to our company piggy bank and we’ll open our servers for you. Sounds dirty, but that’s game development for you, we need to pay the bills to keep the lights on. Even though we’re funded for the coming months, we need to start generating an income to sustain the team and even increase it. For example we’d really love to add another programmer to our team (with a focus on client side code and tools) - and new team members means new expenses.

Your support will earn you a bunch of awesome perks - one of them being access to the game’s alpha. But again: This will not be the only way to get into the alpha. The other two ways (join the waiting list or do something awesome in the community) are still perfectly valid. In some way or another you’re going to make it into the game, and I’m already looking forward to playing with you all.

Alex

Page 1 of 7
Older posts »