In our world, 13th Amendment is still there. There are no poor souls shoveling coal into the boiler. In fact there isn’t even a boiler… we’re dieselpunk and that means we have gas engines.

Version 1.1.3 is live today! Here’s the full changelog:

Content

• New “Raid on the Refinery” Crazy King map
• “Zale’s Handbook,” new in-game player manual
• New accessories and “Steampipe” and “The Warrior” costumes in-store

Features

• New “Crazy King” game mode, point capture with a moving point
• Steam Achievements integrated
• Map Vote – vote for your next match after each battle
• Level Weather: new effects for rain and frost
• Level Weather: wind and moving storms
• Indication of blocked players
• Add Back to Main Menu button in Loading Screen while waiting for connection

and more after the jump…

Map Changes

• King of the Flayed Hills is now Crazy King
• moving sandstorms added to Scrap on the Dunes

Balance

Heavy Flak Changes:

•  Decreased rate of fire with increase in damage to maintain DPS
•  Reduced muzzle speed with increased shell life to maintain range (1020m)
• Slight increase to drop

Fixes

• Fixed some networking issues that could cause client state to not sync properly (causing various strange bugs with reload, fire, and repair state display).
• The “Light Quality” setting in Options now more aggressively controls cloud quality. Try reducing it if you have framerate drops when looking at large cloudbanks.
• Missing rock collider in Canyon Ambush now fixed
• Fixed issue with components on fire not colliding properly
• Fixed resolution settings being improperly applied
• Surrender button no longer in spectator mode
• Fixed extinguisher animation bug in avatar preview
• Corrected Lumberjack ironsights layout

Player

• Collector’s Edition costume pack has been expanded to include 6 costumes, one Ladies’ and one Gents’ for each class. Anyone who already has the CE or 4-pack will retroactively have the additional costumes automatically unlocked. If you have the CE and and have already purchased one of these new additions, then we’ll give you your choice of another item of equal value. Just email us at feedback@musegames.com and let us know which item you’d like!
• The Facebook Like and Steam recommendation drive is still happening! Like us now or write a recommendation on Steam for a chance to win goodies.

Dear Illarionites,

the update this day addressed a problem that appeared mainly in mount Letma. It caused the client to freeze within seconds and windows reported it to be not responding. This problem is now fixed.

Tarnsman on DTS-T: Overall, DTS-T is a combination of poor maps, a boring story, and a couple of possibly decent ideas, all wrapped up in a package that is riddled with technical failings. While there are far worse WADs in terms of technical quality, it doesn't excuse DTS-T's utter lack of playability.

Set in a far fetched future, you play as a Reinforced Intergalactic Livalink Trooper.
Set in a far fetched future, you play as a Reinforced Intergalactic Livalink Trooper.

A 2D, topdown adventure game where you use two items to explore a collection of Zelda-like dungeons.
A 2D, topdown adventure game where you use two items to explore a collection of Zelda-like dungeons.

Foldit players, this one goes out to you.

We are the winners of the Katerva Award for Behavioral Change! This category honors those enacting global change on an individual level. The best technologies can't make a difference if individuals don't use them. Thank you for helping us change the world.

- Official press release

Hello everyone,today we bring you our latest release Unknown Horizons 2013.1. Some of the new features in Unknown Horizons 2013.1: Completely new tileset New buildings: alvearies, barracks, blen...

The PoxNora server will be restarted on 02.01.13 at 3:00 a.m. PST for general maintenance. Downtime should be minimal. 

Thanks to an intrepid inside source, we have access to previously-secret footage of the Zero-K developer team discussing the game’s story. Enjoy

http://www.youtube.com/watch?v=9IP1mp3cgRo

Christmas might be over, but there are plenty of opportunities and reasons to buy a new shirt - especially when it has Chasing Aurora's Fink on it!

As we ramp up to release the next version of OpenXcom, nothing is more important than getting rid of all those pesky bugs and crashes that always litter our development. And what better way than to team up with X-Com veterans to play through it live and test it for us?

Watch as Jade Star tries OpenXcom for the first time! Listen as SupSuper and Warboy occasionally commentate and answer audience’s questions with a variety of “yes”, “no” or even “maybe”! Suffer as the game explodes and we get more bugs to fix!

(Part 1 got eaten by Livestream)
Part 3
Part 4

Wanna know when the next stream is gonna be? Well these things are kinda unplanned, but hang around on IRC and you might catch one. Or maybe you’d like to try it yourselves? Just contact us! We’re always happy to hang out with the community.

Way back in December, we had just implemented a bunch of the character logic for going through the world and doing things using our Finite State Machine model and utility functions. What we discovered was that writing the code for the FSMs themselves was, to put it frankly, a huge pain. Additionally, non-C++ programming members of the development team could not easily add new items and new behaviours to items (mines, buildings, trees, and the like.) Micah J Best, at the end of December, decided that we should use scripting to wrap some of the complexity and hide it from the end user, while simultaneously letting our development team create new objects and FSMs without requiring a programmer to go thrashing about in the codebase. I said, “Fine. Show me a proof of concept and then we’ll talk.”

Fundamentally, Gaslamp’s programming team operates based on spite. If somebody says “oh, well, we’ll never get that done in time”, or “oh, well, it’s too impractical”, somebody usually says “no, it well isn’t” and will jump to the bait. (I did this recently with a pipe system test.) Saying “Well, show me a proof of concept and we’ll talk” is equivalent to putting a red cape in front of a bull.

Over the holidays, Micah found himself stuck in Quebec. With nothing but inlaws, a language barrier, two laptops (one of which was destroyed by a cat), a turkey stuffed with poutine, and spite, he put together the first build of what is our new scripting system. It does, indeed, encapsulate all our programming decisions and is fairly powerful and flexible. We took apart all the character code we wrote in December, ported it to the new scripting system, and have now started using it to implement new things in game. It’s very powerful and, after some back-and-forth, I’m quite happy with how it’s turned out. We’re still fixing bugs and fine tuning how it all comes together, but let’s see how it all works…Our system is built on top of Lua, the happy interpreted language you may know from World of Warcraft and, if you’re a sysadmin, nmap. Each object type has a .go file, containing a name, a list of its variables, and a number of messages that it receives. Objects in Clockwork Empires (more properly, objects in our engine) communicate with each other in a given game frame by message-passing; this is the same framework that we use to communicate with the renderer, and between the renderer and the gameplay and networking layer. One advantage of this approach is that it’s very, very threadsafe; no object can get out of its sandbox except by messages, and we control the messages.  This makes it possible to do some… interesting optimizations. For those of you familiar with early game creation toolkits, this is the same programming idea as the languages exposed in Tim Sweeney’s ZZT game, and later on in Greg Jansen’s Megazeux.

Whenever an object gets a message type that it knows how to handle, it runs the corresponding Lua script. For instance, here’s the chunk of code for a mineshaft that, if you click on its interactive menu object and select “Mine”, registers a new mining job:

receive InteractiveMessage( string messagereceived ) <<     print ("Message Received: " .. messagereceived );     if messagereceived == "Mine" then         send( "gameCitizenRequestBlackboard", "gameObjectNewJobByNameMessage", SELF, "Mine" )     end >>

The mineshaft gets a message from the renderer saying “Hey, you just were selected and told to perform mining!” It then sends a message to the jobs request blackboard (the object responsible for managing all player jobs in the game) telling it to create a new job, “Mine”, from the jobs list with itself as the originating object. Jobs are still stored in XML, as are item definitions, character information, text strings, and the like.

Each message has a type. Message types can either be defined in C++, or on the fly in Lua scripts.

FSMs, for characters and Other Entities, are separate Lua files. Each FSM runs on a character, and cycles through a list of states. At each stage of execution, the FSM can remain in the same state or advance to a different state depending on where it is in its execution. For instance, here is the “pick up an item” FSM:

pickup_item = {     ["start"] = function(state, tag)         print("pickup_item")         -- FIXME: if I have a currently picked up item, I should drop it.         if state.curPickedUpItem ~= nullHandle then             FSM:abort( "Hands full." )             return;         end         -- As far as we are concerned on the game side, the transition is instantaneous. We remove the item from the grid,         --  we put it in the character's inventory, and we let this elapse some number of ticks.         resultROH = query( tag.target, "ROHQueryRequest" )         name = query( tag.target, "HandModelQueryRequest" )         state.curPickedUpItem = tag.target         -- de-register from spatial dictionary         send("gameSpatialDictionary",              "gridRemoveObject",               tag.target );         -- Start the animation         send( "rendOdinCharacterClassHandler",               "odinRendererCharacterPickupItemMessage",                state.renderHandle,                resultROH[ 1 ],                name[ 1 ] )         state.animationTickCount = 0         return "animating"     end,     ["animating"] = function(state, tag)         state.animationTickCount = state.animationTickCount + 1         if state.animationTickCount == state:getNumPickupTicks() then             return "final"         else             return         end     end,     ["final"] = function(state, tag)         print("Done")         return     end,     ["abort"] = function(state, tag)         print("Aborting")         return     end }

The query() function actually sends a message to other objects involved in code execution (in this case, the object being picked up), and halts program execution until it returns. We support this, internally, using Lua’s coroutine functionality.

There will also be a third type of Lua file, for “special events”, which will be responsible for governing Interesting Discoveries.

Unlike in Dredmor, where scripting using our XML system causes hideous silent failures, both our XML and our Lua code will scream at you, furiously, if anything is broken or incorrect. Modal dialog boxes will appear as soon as your Lua script breaks, and won’t let you advance the game until you have acknowledged all the Lua code that broke in this rendering frame. “Hot Loading” and resumption is Coming Soon, as well as some sort of a wrapper for Lua’s debugging functionality.

To cool the heels of the invariable cries of joy from the modders: we have not decided how much scripting, if any, we will end up exposing to the mod API and, if so, when we expose it. There’s a pretty good case to be made for doing a launch of the game without modding and turning it on later, like we did with Dredmor; amongst other things, this will ensure that we get the core game right and resolve any post-release issues (which hopefully we will have none of this time, knock-on-wood) before we start letting other people modify it.

In other news, Chris Whitman, Terrain Wizard, has finished rewriting the rendering code for our terrain. Our new terrain implementation doesn’t use a standard heightfield; instead, it uses an algorithm called Marching Cubes (thankfully now patent-free) in order to generate terrain from a scalar field. With this rewrite comes support for improved texture blending with Interesting Edges, and also the ability to raise and lower terrain. Support for terrain modification is necessary in a game like CE to ensure sufficient buildable space; additionally, we can use it (at our discretion) for things like Impact Craters from the Space Fungus Meteor.

Where the desert meets the swamp, the Aurochs bull shall call at eleven then the Obelisk shall show you The Pathway.

Biome selection is now in as well, although the biome generators themselves are only filler right now. Here you can see a “grass and plains” biome with a giant cliff for whatever reason featuring smooth texture transitions, a swamp biome with various swampy things in it, and whatever the heck is going on in that desert place with the obelisk and jolly little campsite.

So, yeah, humming away here quite happily. Now, back to work! I’ve got overseers to fix!

Hey everyone! Galcon 2 got funded on Kickstarter! Yay! For the convenience of those without Amazon.com accounts, I’ve been taking extra orders via PayPal. However, since we’re about to start ordering the actual rewards in the next few days, I’m going to have to stop taking orders. So, you’ve got just 2 more days to order via PayPal if you want any of the cool rewards! Here’s how to do it.

http://www.kickstarter.com/projects/philhassey/galcon-2-galactic-conquest

If you aren’t from the United States, be sure to add International shipping to the base pledge price!

Then send that amount to (removed) via PayPal. Change the subject to “Galcon 2 Kickstarter: (name of tier)”, where the (name of tier) is “DIGITAL Captain” or whatever you picked.

http://www.paypal.com/

Cheers!
-Phil

P.S. Galcon 2 backers will be getting access to the beta very soon!!

Since I've been doing some coding I thought I'd share what I'm working on. First and foremost my goal right now is to rework the drive-train code, this includes the tires. But I am sort of taking a round about approach to this which includes some pretty heavy refactoring. I've written a lot of concept code in the past for a new drive-train but never put it to use. I also wrote it in a reusable manner and am expanding this design.

History
The drive-train code I did write works on it's own, it just needed to be integrated into RoR. The new drive train code is built on the same principle as RoR, nodes and beams. Instead of nodes and beam in a 3 dimensional space we have nodes and beams in a 1 dimensional space. replace position with angle, velocity with moment, and force with torque and you have the same equations. This is where I started.

So I am basically building a parallel "world" for the drive train that works similar to nodes and beams. My starting point was going to be the wheels, since they essentially act like the gate way between the node/beam world and the drive-train world. My approach here is to simulate a drive-train wheel object which is nothing more than an an angle, then calculate where the nodes should be positioned based on that angle. While I was working on this, I realized that this is drive-train same concept I'm using for slide nodes: calculate where a node should be, calculate beam-like forces from where the node is, and where the node should be and distribute forces appropriately. So I started hacking away at some concept that I could use for both when I dawned on me that I had already written this code a long time ago for the drive train.

Theory
So here is a bit about my theory behind the drive-train code, and what will most likely be used in many many more places than the drive-train. As I've worked in the BeamForcesEuler routine I've realized that it boils down to two actions, updating the forces that act on a node, and updating the nodes position. I call them sources, and sinks; sources generate/calculate the forces based on the environment and are applied to the sinks, the sinks take the forces and decide what to do with them. In RoR terms sources are beams, engine, wings, commands, collisions, etc, etc, and sinks are nodes.

One of the cool ideas I will be able to introduce with this new idea is per-node integrators, I feel this will be handy because some weight/spring combinations are not stable but would be if a different integration method is used.

Way Forward (aka the plan)

1. Replace slidenode code with outside drive-train code
2. Refactor current wheel calculation
3. Rewrite current drive-train to make use of new code
4. Add new drive train features

Replace slidenode code with outside drive-train code
I'm doing this first because it's an existing system so I will be able to just test out the new code against existing slide node behavior to tell if it is working. This will be the biggest change all other items will make use of the concepts implemented here.

Refactoring this code will also have the added benefit of slide node damping since it's already built into the code I will be integrating.

Refactor current wheel calculation
Current wheels aren't very reliable, we average the speed of each node to calculate the rotation of the wheel, this is subject to fluctuation. Instead I will have one object that represents the wheel as a whole, it acts more like a traditional tire model in a game where it's simply a cylinder. This is very similar to slidenodes is that there is an ideal state, and a state the wheels actually are at.

I'm expecting this to help solve a few issues RoR currently faces such as vehicles slipping down a slop when they should be braked. Also under this approach folding wheels should be a thing of the past.

Rewrite current drive-train to make use of new code
Make sure the current drive train code works and behaves as is with the new wheel model, and make use of new code to perform drive train calculations. The current code is a bit of a mess and there is a bug where the first two axles are locked together but none others, this should solve that problem.

Add new drive train features
Multiple engines, torque converters, clutches, lockers, limited slip, multiple gear boxes, transfer-case, brakes, etc

My goal here is to model any and all kinds of different power, be it a traditional engine and 4 wheels, a parallel hybrid with two different engine types, or a helicopter with one engine powering two different rotors. Or who knows what. I want to flip over a car, spin one wheel with the mouse and watch the other wheel spin in the opposite direction when using an open diff. the best part IMO is that I've already got some of this working. I've test locked, open, and LS diffs. I've tested with one power source, and I've tested with two power sources.

And Beyond!
I plan on using this framework throughout RoR, hoping to achieve better performance, multiprocessor support, more organized, and easier to alter.

I'm excited :)

My work and progress is viewable here: http://sourceforge.net/u/aperion/rig...0fd7a443/tree/
What I will be using for much of my refactoring is here: http://sourceforge.net/u/aperion/rig...ics/framework/

Here are the major changes for Overgrowth alpha 196:

• Removed MSVC 2005 dependencies to fix "side by side configuration" errors
• Fixed all known unicode errors and removed unicode warning
• Fixed Angelscript caches not updating when include files are changed
• Fixed Awesomium keyboard input
• Removed last remaining ODE dependency
• Fixed shader preprocesser issue with baked imposters
• Fixed crash when loading a level that has no script
• Added main menu toggle to config file
• Added mouse sensitivity value to config file
• Progress on placeholder object spawn points and previews
• Completing a challenge level triggers level-end screen again

As you can see this update was mostly about fixing long-standing compatibility issues, as well as any bugs that might have been introduced during the extensive refactoring for alpha 195. This should clear the way for further gameplay progress!

Don't forget that you can help support us, try out our alphas, and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.

“We already have The Battle for Wesnoth; what makes Telepath Tactics different?” I’ve gotten this question a few times now. The short answer is, “So many things that I would have to write an article to list them all.” And the long answer is…well, this article.

Why the comparison with The Battle for Wesnoth in the first place?

There is an argument to be made that this isn’t even a legitimate question to ask. Even if the games were similar, what would be the harm in having more than one game in a similar style on the same platform? Ask this sort of question of virtually any pair of similar games, and it sounds transparently silly. “We already have a ton of Fire Emblem games. Why do we need Fire Emblem: Awakening?” “We already have the Diablo series. Why do we need Torchlight?” The answer is obvious: variety. For someone who enjoys the core experience of these games, even the relatively small differences between Diablo and Torchlight, or between Fire Emblem: Awakening and its predecessors, are sufficient justification for the new games’ existence.

But let’s set that aside for a moment and talk about Telepath Tactics and The Battle for Wesnoth specifically. I was actually confused when people first started asking what the difference was; it is only a slight exaggeration to say that this is like demanding to know the difference between Risk and Chess! These games are about as different as two games in the same subgenre can be.

After giving the matter some thought, it occurred to me that there are some similarities between Wesnoth and Telepath Tactics that people may be seizing on. Both games are turn-based strategy RPGs; both occur in fantasy settings; both are cross-platform; both support custom campaigns and modding; both have a robust map editor; and both support multiplayer.

I suspect that some people get as far as these features, then decide that the games are nearly identical. However, this is a little like observing that The Usual Suspects and The Godfather are both violent dramas about organized crime available on DVD and Blu-Ray, and then concluding that they must be more or less the same movie. Of course, two works can share superficial similarities while still offering wildly differing experiences; as we shall see, this is precisely the case with Telepath Tactics and The Battle for Wesnoth.

The Differences

Because there are so many differences between these two games, I’m going to organize them in list form.

1. Level of Randomness.

This is one of the more striking contrasts between the games, and one that should become obvious almost immediately when you sit down to play each. Wesnoth is heavy on randomized results; Telepath Tactics is not.

In Wesnoth, nearly all attacks have a 30 – 70% chance to land, and most units attack multiple times in a row when you order an attack. Consequently, the results of any given attack command vary wildly based on what Wesnoth’s random number generator spits out. (There is so much randomness in Wesnoth that it actually has automatic, turn-by-turn save scumming built into the game!)

By contrast, Telepath Tactics uses randomness sparingly. The RNG comes into play only in select circumstances.

This leads to wildly differing experiences. Wesnoth is analogous to Risk, in that it is a game that is largely about playing the odds; Telepath Tactics is a more chess-like experience where you’re thinking ahead, constructing a defense, and trying to seize on weaknesses in your opponent’s positioning of units.

2. Scope.

The Risk-Chess analogy also extends to the scope of the two games. Wesnoth is the more macro-focused of the two, with battlefields that span enormous geographic areas containing dozens of different villages. As with Risk, control of different areas directly correlates with your ability to keep hiring troops; and as in Risk, a lot of the challenge in Wesnoth comes from trying to grab as many of these resources as possible as quickly as possible without overextending yourself. Victory is usually achieved by starving your opponent for unit-generating resources rather than through tactical victories alone.

Telepath Tactics is more micro-oriented. As the name implies, Telepath Tactics is focused almost exclusively on the tactical level of play. As with Chess, you’ll mostly spend your time managing a finite number of units to achieve tactical victories. There is resource management, but it manifests primarily in the management of items and energy levels among your characters; you’re not going to be running around the countryside, grabbing villages to drum up money to support an army large enough to overwhelm the enemy.

This difference in focus has knock-on effects that resonate down to even the smallest choices in the mechanics each game features. For instance: Wesnoth uses a zone of control mechanic to keep enemies from easily sliding through small gaps in your defense to capture towns. However, Wesnoth very seldom employs any sort of flanking bonuses against individual units. Telepath Tactics, by contrast, awards a near-universal 50% backstab damage bonus to attacks that hit from behind; there is no zone of control. Telepath Tactics is more focused on good formations and precise positioning; Wesnoth, on keeping control of specific points on the battlefield. Each game’s mechanics reflect its area of focus.

That’s just one example I could pick out of many; in fact, most of the differences you’ll see below can be explained at least in part by the difference in scope between these games.

3. Level of abstraction.

This one is particularly closely tied to scope. Because Wesnoth operates on a high-level strategy plane moreso than a low-level tactics plane, it tends to abstract a lot of things that Telepath Tactics models in detail.

Take ranged attacks, for instance. Wesnoth’s “ranged” attacks aren’t actually ranged at all! Like melee attacks, they only hit adjacent hexes. The only thing that distinguishes them from melee attacks is that they trigger different counterattacks from enemies. Ranged attacks in Wesnoth are abstracted, in other words, not modeled.

Telepath Tactics, by contrast, actually models different attack ranges on the battlefield. Attacks can often hit at variable ranges, with damage falloff occurring as you target further and further away. Elevation effects make a difference in range and damage, while cover and good positioning can thwart a shot from going off in the first place. In short: you’re not just picking hexes to maximize the odds of a good, randomly generated result–to a much greater degree than in Wesnoth, you’re actually playing out that result yourself.

4. Variety of attacks.

Wesnoth’s attack variety is quite limited by comparison to Telepath Tactics. Most Wesnoth units have only one or two attacks, and that’s it. The attacks themselves vary in only a small handful of respects: type, damage, number of potential hits, and (in rare circumstances) a special effect (e.g. poison or health drain). Attacks in Wesnoth are so focused on damage-dealing that even basic things like healing aren’t handled via attacks (healing occurs automatically by keeping units adjacent to a healer).

Characters in Telepath Tactics tend to have a much wider array of abilities at hand: units can begin with up to eight attacks and skills (though most start with one or two), then steadily accrue more as they gain experience. This greater selection of abilities creates a much larger universe of possible moves you can make with any given character.

Further, the attacks themselves have many more dimensions to them. To name a few: element, range, area of effect, energy cost, backstab bonus, sidestab bonus, knockback, various stat-based damage multipliers, status effects*, post-attack effects**, and so on.

* there are more than a dozen different status effects in Telepath Tactics, and attacks are able to impart more than one of them at once.

** certain attacks will end the attacker’s turn after they go off; others will allow the attacker to continue moving afterward; and others will allow the attacker to both continue moving and use another attack!

Many attacks in Telepath Tactics are not about dealing damage at all, but are instead about positioning or energy management. For instance, Shove pushes a character back one space. Though Shove deals no damage on its own, it can be devastating when used against a poorly positioned unit. Which leads me to the next difference between Wesnoth and Telepath Tactics…

5. Environmental hazards.

Wesnoth does not have full-fledged environmental hazards–it just has different hexes that affect movement range and to-hit percentages differently.

In Telepath Tactics, you can damage characters by pushing / pulling / throwing them into water or lava, or by dropping them from high elevations onto lower ones. It’s not just about damage, though. Drop a character far enough, and you’ll stun that character in addition to dealing falling damage; push a character into water or lava, and they’ll have to spend a turn (and some of their valuable energy) swimming back onto land before they can act again.

All of this comes as a direct benefit of modeling the battlefield in detail instead of abstracting it with terrain hexes–and so, incidentally, does the next feature.

6. Manipulable environments.

In Telepath Tactics, you can literally change the battlefield as you play. You’ll build bridges to create new routes across the battlefield; you’ll build barricades to create choke points. You’ll chop through bushes and move boulders. You’ll lay down explosive charges to bust through walls. You’ll destroy your enemies’ bridges and barricades and fight to protect your own.

Wesnoth does not have these features.

7. Squares versus hexes.

Wesnoth uses hexes; Telepath Tactics uses squares. Hexes offer greater versatility of movement; squares make it easier to visualize distance. Each has its advantages.

8. Leveling.

Characters in Telepath Tactics level frequently and improve gradually with each level up, as occurs in a traditional strategy RPG like Fire Emblem or Disgaea. Battle for Wesnoth, by contrast, does not have character leveling as such. Instead, it has a small handful of class promotions with huge gaps in usefulness between them (so much so that the ability to hire new units in battle becomes a pointless money drain midway through a sizeable campaign–your new recruits will die almost instantly to promoted enemy units).

9. Characterization.

Most of the characters under your command in Wesnoth are generic hired troops. Combined with Wesnoth’s brutal randomization, permadeath, and character advancement mechanics, as well as the need to control large amounts of territory in order to maintain a sizeable army, the result is that you will be primarily relying on characterless units, units who you will lose regularly throughout the campaign.

Wesnoth’s single player campaigns usually do include a handful of unique characters, but only two or three of those characters (namely, those who produce an instant “game over” upon death) will be continually developed. This makes some sense: one can’t reasonably write a plot line that relies upon the development of characters who can die before they ever deliver their lines.

Telepath Tactics takes a different approach. All characters are unique, and are developed continuously over the course of the campaign. Like Wesnoth, Telepath has permadeath, but the game’s mechanics are such that you’re unlikely to see your characters get swatted down at regular intervals by The God of Unlucky Die Rolls. Furthermore, when characters do fall in battle, Telepath Tactics treats them as having taken permanent, career-ending injuries–for purposes of the story, they are not dead. Thus, they can continue to participate (which in turn permits the story to be far more character-driven).

Telepath Tactics also comes with the capability to let you create campaigns with true permadeath. In order to preserve characterization in these scenarios, however, Telepath Tactics employs easy-to-use scripting tools that let you change the way character dialog proceeds when certain would-be speakers have already been killed.

10. Items.

The Battle for Wesnoth technically supports items, but it seldom makes use of them during its campaigns. As with its minimal characterization, I suspect that this is simply a side effect of the fact that your characters die regularly in Wesnoth; micromanaging inventories just slows things down in a system like that.

Telepath Tactics, by contrast, features dozens of unique items, and characters have individualized inventories that can hold dozens of them.  What’s more, destructible objects around the battlefields tend to hide items, so you’ll have the option to hunt for extra loot during battles.

11. Setting.

Wesnoth is a generic high fantasy setting with European feudalism, magic, elves, orcs, trolls, and all the other things that hundreds of RPGs have ripped off from Tolkein since…well, since RPGs first became a thing. It’s all very familiar, which is a blessing in terms of accessibility but a curse in terms of the game having much of anything interesting to say.

Telepath Tactics deliberately avoids the Tolkein trap, opting instead for less familiar environs. The game is set in an island chain governed by a Roman-style empire on the brink of industrialization; however, natural resource exploitation by foreign interests threatens to destabilize the government. There are no elves, no dwarves, no orcs, no zombies; this world is instead populated primarily by original races (e.g. the shadowlings, floating disembodied heads that literally feed on human suffering). Cavaliers do not ride horses; they ride giant mantises. There is no magic; there are only different disciplines of psionics. Telepaths are both privileged and distrusted for their talents. Humans are regularly captured and enslaved. This is a world with its own dynamics and its own problems.

Conclusion

So, to summarize: the differences between Telepath Tactics and The Battle for Wesnoth manifest in

• their levels of randomness (Wesnoth employs far, far more randomization of results);
• their scope (Wesnoth is macro-focused, Telepath Tactics is micro-focused);
• their levels of abstraction (Wesnoth is more abstract, Telepath Tactics models in detail);
• their attack variety and character versatility (Telepath Tactics has much greater attack variety and a higher number of attack options per character);
• the presence of environmental hazards (Telepath Tactics has a strong implementation of this feature; Wesnoth does not);
• the ability to manipulate the battlefield (Telepath Tactics has this feature; Wesnoth does not);
• their use of square versus hex grids (Wesnoth uses hexes, Telepath Tactics uses squares);
• their leveling mechanics (Telepath Tactics uses gradual leveling, Wesnoth uses unit promotions exclusively);
• their characterization (Wesnoth campaigns have few unique characters, and develop only a small number of those);
• their items (Telepath Tactics has a more robust item system, and uses items with far greater regularity); and
• their setting (Wesnoth opts for generic high fantasy, while Telepath Tactics takes place in a more unusual setting).

To put all of this more succinctly: Telepath Tactics is a descendant of tactical RPGs like Fire Emblem and Shining Force, whereas The Battle for Wesnoth is more directly descended from pure turn-based strategy titles. Both lineages offer distinct advantages and disadvantages, to say nothing of very different play experiences.

Personally, I really enjoy playing The Battle for Wesnoth (aside from the occasional moment of pure rage brought on by missing seven 50%-chance-to-hit attacks in a row). I neither want nor expect Telepath Tactics to be a substitute for Wesnoth, any more than Chess is a substitute for Risk. These games have wildly differing scope, mechanics, and narrative considerations. As far as I’m concerned, Telepath Tactics and The Battle for Wesnoth can coexist happily side by side on PC–and goodness knows, the platform is certainly large enough to accommodate both of them.

 

Important: We will perform maintenance beginning at 7:00 AM Pacific* on January 29, 2013. We expect this maintenance to take approximately 1 hour. This will impact the following services:

• Login for all SOE games may be affected
• Players who are already logged in may be disconnected and unable to log back in
• Login for all SOE forums may be affected
• Commerce transactions, including purchases on our websites and in-game marketplaces, may be unavailable
• Account management may be unavailable

We apologize for this interruption and will resume all affected services as soon as the maintenance is completed.

*Convert to your local time

Thanks to Jaimswallace for the cool video.

Original link: The-ultimate-Crash-Compilation-ep-14-Less-CC-More-Crashes

I have everything I need to edit videos: Rigs of Rods, tons of recording software, and Sony Vegas. But one thing I don't have is motivation to make decent videos. This is why I congratulate Jaimswallace. :)

Screenhot of Mape showing the map of Krakatoa

Developers from Clonk Rage might remember Mape, an editor for dynamic landscapes described by a Landscape.txt file. The editor shows a live preview of the generated map while editing the Landscape.txt code, so that the engine does not need to be started to see the generated map.

Mape has been refurbished to work with OpenClonk, and it has been integrated into the OpenClonk source code, so that it is now officially part of OpenClonk. On the Development Snapshots page the current version can be downloaded including all dependencies for the Windows builds such that it runs straight out of the box. There is also a wiki page available which describes it in more detail.

Happy Mapping

 

 

Important: We will perform maintenance beginning at 11:00 AM Pacific* on January 28, 2013. We expect this maintenance to take approximately 1 hour. This will impact the following services:

• Login for all SOE games may be affected, but players who are already logged in and remain logged in will not be affected
• Login for all SOE forums may be affected
• Commerce transactions, including purchases on our websites and in-game marketplaces, may be unavailable
• Account management may be unavailable

We apologize for this interruption and will resume all affected services as soon as the maintenance is completed.

*Convert to your local time