EverythingElsePosted by Eskil Sat, October 26, 2013 04:45:34
Lately I have been thinking about encryption (haven’t we all?) and as an exercise I have written my own encryption algorithm that I’m going to describe in this article. Of course i know rolling your own is a bad idea, but that doesn't mean its not fun.
I base it on the idea that i want to use the simplicity of a one time pad, but to have a considerably shorter key. If we have a small key we should be able to procedurally generate an infinitely long key from the initial key seed. Note: at this point anyone who knows anything about encryption can see an obvious weakness here: the procedural algorithm will produce a pattern that can be found and used to break the key. True, but that is a mathematical way of thinking about it: a specific algorithm yields a specific pattern. But what if the algorithm isn’t specific? What if the key describes the algorithm? If the key is data that can be used as an algorithm to produce data, we can create a cycle where the algorithm is self modifying and therefor wont create a pattern.
One way of thinking about it is to imagine the encryption algorithm as a virtual machine that produces a one time pad, and new instructions for the virtual machine. All we really need to do is to ensure that the virtual machine never gets stuck in a loop where it produces an output that makes it repeat its previous operations over and over.
That’s pretty much the basic idea, and once you start to think about it you realize that you don’t need a full virtual machine, you can do something much simpler that has similar characteristics.
pos_a = key;
pos_b = key;
pos_c = key;
for(i = 0; i < length; i++)
old_a = pos_a;
pos_a = key[pos_b] % key_size;
pos_b = (pos_a + 1 + key[pos_c] % (key_size - 1)) % key_size;
pos_c = (pos_a + 1 + key[old_a] % (key_size - 1)) % key_size;
decrypted[i] = encrypted[i] ^ key[pos_a] ^ key[pos_b];
key[pos_c] = (key[pos_c] << 31) | (key[pos_c] >> 1);
key[pos_a] ^= key[pos_c] ^ i ^ decrypted[i];
Lets go over this code and start by first analyzing the key line here:
decrypted[i] = encrypted[i] ^ key[pos_a] ^ key[pos_b];
This is the encryption using a simple XOR. XOR in it self is unbreakable because any input can yeld any output with the right key value. However If we re-use the same XOR key more then once it becomes possible to guess the key. The assumption of any encryption algorithm must always be to make the message unbreakable even if the breaker has a part of the message in plain text. So the first thing we do is to XOR with 2 different parts of the key; key[pos_a] and key[pos_b]. The breaker now knows two numbers if XORed together will produce the XOR difference between the message. if we a working with a 32 bit implementation that means 4 billion combinations. That’s a lot, but its still a clue. So the next thing we do is to destroy that clue:
key[pos_c] = (key[pos_c] << 31) | (key[pos_c] >> 1);
key[pos_a] ^= key[pos_c] ^ i ^ decrypted[i];
Here we take a third portion of the key, key[pos_c], that the adversary still haven got a clue about and use it to destroy one of the two XOR factors. To this we add in the decrypted message and a counter, that will add a poison pill and prevent the algorithm to ever get stuck in a pattern. By adding the decrypted message we also add the same entropy as the message it self has to the possible combinations. To make sure we have good entropy we also shift the key one step, so that we aren’t constantly XORing the same bits. Then finally we get to this:
old_a = pos_a;
pos_a = key[pos_b] % key_size;
pos_b = (pos_a + 1 + key[pos_c] % (key_size - 1)) % key_size;
pos_c = (pos_a + 1 + key[old_a] % (key_size - 1)) % key_size;
Here we simply use the key to recursively select the 3 sections of our key we will use in our above algorithm. Since none of these position values are exposed, they obfuscate how the algorithm work as they will just modify how the algorithm selects its key values, they wont actually be used in the math relating to the message. Since the keys at pos_a and pos_c will be XORed to destroy the key, they cant be the same, and since the key at pos_a and pos_b are used to decrypt the message, they cant be the same. The core idea here is that the adversary can crack the key, but not how the key was generated as that process is fenced of from the encryption process.
I would love to see if anyone can break this. If you want to try here are a few assumptions you can make: The key is only used once and is random, but assume that you have access to both the encrypted and a significant part of the plain text message (The encryption should hold up even if an attacker can accurately guess significant parts of the plain text). I’m very curious as to how the key size and amount of plain text data is given can impact the security of the encryption.
This is one of thous times I wish i was very rich so that i could offer up a big cash price, but maybe i can owe you beer if you break it?
pos_a = key;
pos_b = key;
pos_c = key;
should obviously be:
pos_a = key % key_size;
pos_b = key % key_size;
pos_c = key % key_size;
See? I already look stupid!
EverythingElsePosted by Eskil Thu, March 07, 2013 07:19:11
Have you ever wondered why we don't have flying cars by now?
The answer is that we do. We just don't call them flying cars. We call them helicopters. Are you disappointed yet? Disappointed perhaps that our mode of air transportation doesn't break at least one laws of physics? So why don't we all have helicopters by now then? Because helicopters aren't very good for most people. They are harder to control, more dangerous, require more space, and most of the energy they consume isn't used to get you where you want to go, but to keep you from crashing down in to a ball of fire. If you think the maintenance bill for your car is steep, be glad we don't all have flying cars.
If you google "futuristic interfaces
" the fist thing that strikes you is that the future is incredibly blue, and very transparent. Graphics technology will also take a giant leap backwards and resort to drawing most things in wireframe.
Whats is cool in a science fiction is not the same as what will take off in the future. The transparent computer monitors you see in films are there because it lets film makers get a good shot of the hero using a computer rather then there being a pent up demand from computer users to be able to keep an eye on the wall while reading E-mails.
If voice commands where so much better then buttons, then why are text messages more popular then voice calls? Voice recognition is unlikely to ever be better then a human, so if we choose not to use voice when we communicate with a human why would we chose to do so with a machine? Bendable displays are really cool, but some how I have never had the urge to bend any of my displays (I have quite a few) so I think Ill skip pre-ordering one. We think we want to be Tom Cruse in minority report, but two month later when we are on sick leave for twisting our arms out of their sockets, we may think differently about the ergonomics of that interface.
Whenever you buy a gadget, you don't know if you are going to use it. You buy it because you think its going to be great to use, but often they end up collecting dust like some home gym bought January first. Lost of people bought Wii and Kinects but how many people ended up using them every week a year later? How you end up using something is different from what you thought when you bought it. Most of the time you need to discover how you like to use something.
Right now I really want a Asus TaiChi, but not because its a Laptop that can turn in to a tablet like Asus tells me, but because its a laptop i can use to easily show things without connecting to a projector or making everyone huddling around my small screen. To me a thin laptop is something you bring along, and when you bring a laptop its usually to show something. I dont care about the touch screen, tablet mode or Windows 8, because I gave away my last tablet, I would plug in a mouse and install Windows 7. The Lenovo Yoga intel sent me I have found to be great standing on its side like a dinner menu on a table so you can read long articles while eating. This great way of using the device the marketing completely omits.
For someone technically minded something like Twitter is incomprehensible. The innovation is a limitation! Twitter may be an indictment either that we have lost our attention span or that most people ramble on too much without saying anything meaningful, but no matter what, it has turned out to be useful.
So how do we build the future? We build something that is better and different, I don't care for new, show me better. For the future to win it has to be better then the past, until it is, its just fiction.
EverythingElsePosted by Eskil Mon, February 25, 2013 12:20:54
There is a fundamental problem when creating new hardware: you need software using it before anyone is willing to buy it. The problem with getting software written for new hardware, is that no one wants to put in the time to build applications using hardware that no one has bought yet. This chicken and egg problem has killed lots of cool hardware, from anyone who hasn't had the skills to develop their own killer apps, or the clout to convince the world that every one will buy their hardware. My first week of work on the challenge has been dedicated to trying to solve this problem.
The plan is to write a platform layer like GLUT and SDL, but with a twist. Instead of giving the application access to inputs like mouse and keyboard, I describe generic inputs like pointers, axis and events. That way an application that supports a pointer, works just as well if the input comes from a mouse, a touch screen, a Waccom, WiiMote or any other hardware that you can use to point with. Obviously they have differences you can query; A mouse may have multiple buttons, while a touch screen only has one "button". (You cant "right click" on a touch screen, well yet. If you build that hardware my API will support it).
Most platform libraries come as a DLL, and if we make this a open source DLL anyone could add what ever hardware support they wanted to it and any application using the DLL would be exposed to the new hardware. Great! Except if we wrote a DLL that supported every known hardware, it would obviously become huge and create a dependency hell, and what if someone created a version of the DLL that supported my sound system and someone else wrote a different version of the DLL that supported my pedals, how would I be able to play my racing game and hear the engine scream when I pushed the pedal?
So I decided we need a different approach, Lets make the library lean and mean instead, but lets give it a plugin interface so that you can write modules for it that add new functionality. Each module is independent and can add as much or as little functionality as you want. The library itself is only a few files large so you can even just drop them in to your project and make a self contained executable that has no dependencies to any DLL. Nice and tidy!
This week I set out to write this library dubbed "Betray" and I knew I was in for a bit of a Indirection hell but problems didn't arise where I thought they would.
The first objective was to do a bit of house keeping and create a utility library to handle some platform specific things, that aren't related to windows, drawing or inputs. In about a day I wrote the sub library "imagine" to handle the following:
-Directory management (Listing volumes and directories, had to do some
work to unify unix and windows here)
-My Application settings API (previously found in "Seduce")
-Dynamic loading of Libraries and sharing of function pointers.
(Needed for the plugin system)
-Threads and Mutexes. (Previously in my old platform layer)
-Execution. (Previously in my old platform layer)
Then I went on to implementing the basic out of the box functionality of the betray library: (Much of this was code taken form older projects)
-Opening a window with OpenGL/OpenGL ES Context (With FSAA)
-Mouse / keyboard
-Opening file requesters.
-Quad buffer stereoscopic. (It should work but i don't have a display
to test it on :-()
-Multi-touch (will still run on pre 7 Windows)
See the API HERE
This was quick and easy and I followed it by building a brand new plug-in API. It too went fairly pain less, although the constant passing around of function pointers got mind numbing after a while. Once done the new plug-in API supported:
Allocation and setting of:
-Buttons with labels and key-codes.
-The ability to hook in to the main loop.
-The ability to listen to events from windows event pump
-A sound API (Few features are still missing)
-A settings API, so that plugins can communicate their settings to a
See the API HERE
I started out writing some test plugins for some hardware I found in my apartment like a Microsoft 360 controller. It worked brilliantly once I figured out what the DLL needed was really called (Not what MSDN says). Then I went on to write a plugin for TrackIR and that went reasonably well too.
Then I had this idea that turned in to a Rabbit hole: What if the Betray API could trick the application in to drawing in to a texture instead of the the screen? Then (potentialy) a plugin could manipulate the screen output before its drawn to screen. You could do things like Color correction plugins (You could play Diablo as gloomy as you want!), plugins that could save out massive screen shots, and if you let the plugins draw more then once you could even support anaglyph 3D, and mult-iscreen CAVE environments!
This was just too cool to not do, so I wrote all the code I though I needed to do this. Then I ran the code... Well it did nothing I thought it would. The problem is that the application has a bunch of OpenGL state and as soon as the plugin tries to access any OpenGL functionality it will need to set its own state, and thats a problem because it, A doesn't know what state OpenGL is in, and B upsets the applications state. I briefly considered trying to read out the current state so that plugins could put it back once it was done with it, but that would be a huge amount of work and wont be forward compatible as newer versions of OpenGL adds more state. The solution will have to be to use 2 OpenGL contexts and its starting to get complex so I will need to do way more work on this.
Finally I came to the big price: The depth seeing camera intel sent me! I'm not at all convinced that depth seeing cameras are very good as interfaces but there is one particular feature Ive been looking for and that is the ability to get the vantage point of the user to the screen. A depth seeing camera should be able to very accurately compute the users head position in front of the computer.
Initially I had some problems just from the fact that the API is C++, and I am a pure C programmer but my good friend Pontus Nyman was nice enough to lend a hand and write a C wrapper for the functionality I needed. So one night we sat down to tie together his nice wrapper with my nice plugin API. Intel has provided us with the Perceptual computing API that contains face tracking so this should be easy, but when we started looking at the data coming out of it, it wasn't very good. It was jerky, imprecise and often didn't pickup a faces more then a few times a second. All the output turned out to be 2D and it leads me to believe it isn't using the depth camera to help it do better facial recognition (the depth camera output was less noisy then the color cameras). You do get access to the depth buffer, but its warped and you need to do a look-up in to a uv table to map it over to the color image, the problem is that you cant do it the other way around so its hard to look up the depth in the depth buffer of the facial detection running on the color buffer. We did some hacks to get something out of it, and for a brief moment here and there it was working, but not at all reliable enough.
I will give it a few more days, but right now its not looking very good. In theory I could write my own face detection code using the depth buffer alone that could be much better but that is a much larger project then i planed, for only a tangentially important feature. I want to begin work on my interface stuff this week, maybe its something I can look in to after GDC. This Week I intend to tie up all lose ends in the Betray platform, release it and move on to the new interface toolkit!
Edit: Intel confirms that the algorithm is not using the depth map for face
recognition, but they also suspect I have faulty camera (I sent them
images), so they are sending me a new one. The cameras are
Pre-Production so this kind of thing is expected. Very nice to get such
EverythingElsePosted by Eskil Mon, February 18, 2013 23:38:04Intel has invited me to participate in their Ultimate code challenge, so for the next 7 weeks i will be working on supporting some cool new tech and blog about it on intels developer site. For people not reading it, I will repost everything here too.
PC is an amazing peace of kit, it’s amazing because no other computing
platform is as versatile and no other platform is so open for
innovation. You can buy hardware for it from thousands of vendors, you
can hook it up to just about any display or input device and you can
make it do just about anything. While maybe no longer being the latest
buzzword, the combination of screen, mouse and keyboard, is still the
best way to be productive, get a headshot or to create the next software
wonder. Whatever cool mobile app or console game you think is the hot
stuff, it was conceived on a PC. If we could only choose one computing
platform it would have be the PC, for the simple fact that no other
platform could exist without the PC.
But all is not well in the PC world.
If it was, then how is it that my Amiga 1200 was able to boot from
power on to desktop in less than 2 seconds when it takes the better part
of a minute to do so on my i7 Machine with a 500meg+ a second SSD? How
is it that when I type in text in to a modern word processor it
sometimes lags behind when it didn't on the Commodore 64? How is it that
it takes a minute to search for a file on my PC hard drive when Google
can search the entire internet in a fraction of a second? How is it that
Facebook remembers every click I make, but my own computer can’t
remember where I left off the movie I was watching last night? While
Intel and others have done an amazing job shrinking down processor
wiring down to the thickness of a few atoms and making processors able
to do billions of operations per second, we as software developers
haven't really done our part making the software.
While the tablet or phone operating systems have yet to become
platforms where I can get proper work done, or do complex tasks like say
having two browser windows open on the same screen, I think the PC
needs more attention. It should not be seen as technology of the past
but as a starting point for where we want to go. What we really want is
to have the openness and flexibility of the PC everywhere. Our phones,
tablets, laptops, workstations, TVs, even walls should all be PCs so
that we can freely move software, files and tasks from one to the other
and never let the hardware form factor dictate what software we can run
on the device. What we should have is software that transcends the
The interfaces we have on the PCs aren’t really adapted well to work
on a wide variety of devices. While we want to keep the open nature of
PC hardware, we need to change our software design so that the desktop
of the future would no longer be familiar to someone using a Xerox Alto
in 1973. We need a new paradigm for the PC.
My goal with this challenge is to show what the PC could be, how we
can develop software that can run well on a range of different hardware
setups, from screen resolutions to input devices. Intel has provided me
with some great new hardware, and I intend to show just how great PC
software can be for these devises, if we only spent the time to develop
it rather than just focusing on closed platforms. There are many things
to improve but with only 7 weeks I will focus on building a framework
for graphical interfaces. I will apply this work on at least 3 different
applications. A game, a data visualizer and creative tool.
I will be writing an open source software layer that makes it easy
for any developers to make use of the diverse hardware available to us,
and makes it possible for hardware vendors to experiment with new
hardware configurations, without forcing us as developers to rewrite our
applications in order to take advantage of them. If we are going to
consider how to write applications that are independent of hardware, we
first need to consider the types of usage scenarios and pros and cons of
different input devices and how they should be supported.
If we are going to write applications that can run on almost any form
factor with any kind of input device, we need to think about the
limitations and opportunities it creates. To begin we should probably
assume that the device has some kind of pointing input device, so we
want to create an API that unifies the concept of pointing, disregarding
if its multi-touch, a mouse, a Wii remote style device or (god forbid)
a track pad. If we are stuck with a non-pointing input device like a
joy pad, we need to figure out a way to make applications useful anyway.
We should also figure out a way to support an "escape" with every
interface. This could be something like the windows key, or the iOS home
button, something that can always be accessed to connect with the
operating system. We also want to support very wide range of display
sizes and resolutions. All the way from your phone to large displays
that may cover and entire wall. Large enough displays means that we want
multiuser support too. That creates some interesting challenges since
we can no longer assume that two multi touch events are triggered by the
same person trying to accomplish the same task. We also must consider
that the user many not be able to reach all parts of the screen, so we
can’t have any static menus or buttons, like a start menu, taskbar, dock
or Apple menu. We will need to solve most of these things with popup
menus. We should obviously support a keyboard, but we should also
provide some kind of pointing based fall back for typing.
To display our interface we should not assume that the pixel
resolution in anyway corresponds to the size of the interface. All
interface elements should therefore be vectorized and scalable. We also
want to support an interface that takes in to account the users view
angle, this means the interface must be 3D. If we build a 3D interface
we can easily support stereoscopic displays, head tracking, head mounted
displays or augmented reality applications.
This first week I will dedicate to building an API that will be able
to provide application developers with all these things and also let
hardware vendors make drivers for it. Next week I will talk about how I
go about doing this.
It’s going to be a fun ride!
EverythingElsePosted by Eskil Wed, October 24, 2012 23:35:42
With two weeks left until the US election, you would think that every possible angle of how voters think have been discussed, but there is one thing I haven't heard anyone talk about: Racism. You may think it has been discussed a lot, but only in terms of how racists won't vote for Obama, not why they would.
The US in may ways is a very segregated and racist country, yet if there is one thing no one wants to be called its a racist. You may call an American all kinds of names, but nothing hits home like being called a racist.
Many white people In the US spend considerable effort to work on not being perceived as racists, especially if they are. Like having the token friends to invite to your parties so that no one will create an awkward moment when they comment that everyone is white. Its especially important to behave correctly when there are black people around. Bringing up any discussion of race relations is a mine field no one wants to end up in. Dont mention the war. And if ever you find your self in a situation where you must talk about race be sure to come well prepared, with names of black friends, your favorite black entertainers and athletes and a story of how once I saw a Taylor Perry movie and liked it.
As most people fundamentally think that their vote doesn't affect the outcome in any meaningful way (and they are often right) who they vote for can become a statement of who they themselves want to be rather then who they really want to be in the white house. They may want McCain to be president, but they want to be the kind of guy who has no problem voting for the black guy.
Any white person could see the writing on the wall in 2008: If Obama would win it was going to be historical and everyone who didn't vote for him was going to look behind the times and racist, and If he lost there was going to be riots and talk about a racist conspiracy, and then you sure don't want to be the one who stood in the way of first black president. Being able to say "I voted for Obama" become a great replacement for "Many of my friends are black", not just to convince other but to convince yourself you a not a racist.
So why does this matter now? Well all the people who felt the need to prove to themselves and others that they aren't racists by voting for Obama, no longer have that to prove. In fact voting against him may even make their case stronger. By voting both for and against the same black guy you sort of prove that race has nothing to do with your choice. Its the ultimate I'm-not-a-racist defense. It also has some of the "you had your chance now, so stop whining" that racists likes to complain about along with affirmative action and black history month.
My guess is that Obama will loose a few percentage points in this election by no longer getting the I-need-to-prove-that-I-can-vote-for-the-black-guy vote. Will it be enough to loose him the election? Time will tell.
LovePosted by Eskil Mon, June 18, 2012 16:34:48
Have you ever been confused by Love? If so, lets consider some fundamental things in Love and how they impact your perception of the world:
-Like any First person game, a player can only see about a tenth of her surrounding at any one time. The quick mouse movements helps but it still remains a problem over say top-down games.
-In a large scale world, things frequently happens far away from the player. In love things can literally happen on the other side of the globe.
-Its a free roaming multiplayer game, so you cant simply trigger an event when all player are there to see it since the players are likely to be far away from each other. You can guarantee that some players will miss things.
-Players can log in and out at any time, so players need to be able to quickly understand the current situation, without having been there to experience the events that caused the situation.
-In a shared world without personal progression, players will be dropped in to the state the world is in, not one that may be appropriate for their level of experience.
If you come to the conclusion that the kind of game you are making, is incredibly difficult to make for these reasons, you have two options. Either painstakingly find solutions to these problems, or make a different game. I have decided to do both. I want to solve these issues, so I'm trying to work them out in Love, but at the same time I know that there are lots of things I cant do because I have these limitations, so in order to be able to go beyond that, I'm making another game that doesn't have these limitations, but more about that some other time.
The easy way to communicate with the player is to simply tell the player what they need to know. If players aren't there to see the bomb get planted, you just play a "the bomb has been planted" sound file to tell everyone its been planted. I think this is a bit of a cop out since it violates the "Show don't tell" rule, and its going outside the game world. Also if something happens that the player needs to know about, shouldn't the reason that the player needs to finds out that it happened, be that it actually influences the player? The expansion "Dark matter spreads over fair land" and my continiued work is all about creating large scale visual events that the playes can experience in the game.Dark matter actually spreading over the land as it gets dominated
Let me give you an example. If you have played Love you may have experienced artillery strikes, and you may think of them as just another weapons. To me they are much more then that, they are "quests". What they do is that they provide the player with the motivation of a problem (Hell raining down on them) but also what they need to solve it. The artillery leaves clear trails in the sky to lead the players to the position of the artillery peace so that they can go deal with it. Most games would have a old man with a exclamation mark over his head, or a female voice in your ear, that precedes to give you some scripted spiel about how you need to go kill some goblins, Nazis or whatever to save the village, despite the fact that they have been killed by hundreds of thousands of players before you or that no matter how long you wait to kill them, the village will never be attacked. the artillery on the other hand does all that, but without using words, by being a real event.
Power beams are also used the same way. If item A is giving you a problem, and it is clearly getting the power it needs to operate from object B, no one needs to tell the player its good idea to go and disrupt B. Its an Implicit mission.
Just like artillery uses the sky to draw a directions for the player, many other items in Love uses the sky as a canvas to give players information, like the beams coming out of powerwells and occupation monoliths or the cloud of domination.
For all the major pivot points in the story, I have made sure that their effect is something near global. These are the events that all players should be aware of. In a large scale world you want events to have a global impact, because you don't want players to be able to ignore things just because the happen some place far away.Blue:
Will trigger a rain storm a that will eventually flood the entire world, causing all power sources under watter to stop functioning.Yellow:
The Planet will stop turning and half the planet will be in perpetual darkness, and the other half will be in eternal sunshine. The bright side will be ravaged by wild fires, while watter will freeze, trees will die and power wells will stop producing power on the dark side.Green:
All cable relays will stop operating. (Yeah, I know it doesn't sound as epic, but its a big deal for any player trying to automate matter gathering)Red:
The occupying tribe will get access to the massive artillery peace in the red settlement and will begin shelling players in its hemisphere.Purple:
The occupying tribe will be given access to balloons so that they can attack the player from the air.
All these things should be noticeable even if you missed the event that caused them. I'm planning to strengthen the clarity of each of these and even give them some effects that can be to the players advantage.
Bring clarity to a game like Love is a huge amount of work because its something that has to be added everywhere. Bullets has to travel slow enough for you to dodge them, character designs changes depending on a tribes state, Laser sights tells players where direct hit weapons are aiming, the map gives players the ability to foresee events, and so on. You cant add anything without thinking about how to make it clear to the player and that very often means you have to scale down your ambitions, and simplify things.The map showing to location of the artifact and the spreading domination.
One thing to notice is that none of these involve characters. While characters may be the basic building block of most stories, they simply don't work well in this setting because they are so local, mobile and fragile. Instead I have made each settlement a "character". Having many tribe members in one place makes them easier to find, and it matters less if one or two of them gets "lost" and the players don't have to manage as many relationships as each tribe works as a hive mind having a shared opinion of you.
Adding clarity, is a constant battle between making things familiar and yet innovative, complex yet easy to understand, clear yet integrated in the fiction. All the things that make Love a challenging game to understand, like the large world, the shared progress, the multiplayer aspects, and the evolving world, are also the things that makes it great. The difficulty is to keep the good things while making it more inviting for people to come and experience it.
LovePosted by Eskil Sat, June 09, 2012 21:01:09
Since my last blog update, I have gotten a lot of feedback from people who wants to know more about the latest Love developments, So I have decided to start posting a series of updates that deal with different aspects of what I'm working on, for people who don't play very often and don't keep up with the minute details of the things I post on twitter.
A very clear goal when designing Love has been to create a world that is proactive. In many games, the player is required to actively move forward in order to engage the game. The enemies that are hellbent on killing you in the next room, will never bother to actually seek you out no matter how long you stand and wait on the other side of the door. In other games, mainly multiplayer games like Starcraft or counter-strike, there is a rush to engage the enemy, or the enemy will rush you. If Love was about making either of these, it would be easy to solve, the problem is I want both.
I want to give the players the time and opportunity to explore and build, activities that are largely self motivating, but I also want the world to force itself on to the players in multiple interesting ways, and compelling them to deal with events that the world initiates. I want the players to be in some, but not complete power over what their objectives are.
Back in the early days of Love the five tribes had very complex relations with each other, and while it was very cool from a simulation point of view it never made much sense to the players. After a few different versions I settled on a new structure that would be the back bone of the expansion "Dark matter moves over fair land". The idea is that there is a powerful object (The artifact) and who ever has it becomes "the evil empire". This tribe would then slowly dominate the world and occupy all other settlements. It is simple and straight forward. The thought was that in the beginning the domination would be fairly benign. but then for each settlement it occupied, some basic functionality of the world would change forcing the players to eventually deal with the domination.The Omprelly Enclave has been occupied, casing rain to flood the planet.
Freeing a tribe from occupation would make them friends of the players. It made it very clear who was a friend and who was an enemy and why.
Two weeks before I was to release the expansion, it all turned out to be a disaster. The problem was that I had given the dominating tribe all the nice stuff that the players wanted, so as soon as a domination would start the players would rush over to it and raid it, before it had the chance to grow. Instead of being the heroes freeing the world from domination, the players became the dominating tribe, constantly killing any tribe that dared to challenge its domination. Even worse the players would bait tribes in to trying to dominate the world just to be able to kill them. The relentless slog to kill dominating settlements just turned out to be a disaster for pacing, and players just got tired of it.
Something had to be done and I decided to build a brand new tech tree, that the players could build up mostly independently from the dominating tribe. It was a mad dash for two week before GDC but it worked. By making the goal of the players to develop their own infrastructure, they would let a domination grow and they would only deal with it once it started making their life too difficult. Something I learned from this was that its very important to add "normalcy" for a world to seem real. To get epic and memorable battles, you cant have a constant battles. Battles and struggles should be about defending normalcy.
Even though this improved the pacing enormously, it still isn't good enough. The question becomes how fast should the domination spread, or in other words, how often should the players be forced to deal with it? If its too often the game becomes monotonous, and the players feel they never get the chance to advance in the game because they are constantly interrupted, If its too seldom players who don't have much self motivation will get bored because nothing happens.
I'm still tweaking these numbers, but I have come to the conclusion that while I can probably find a good average, its going to be different for different players. While all players want diversity, some people like to build settlements and infrastructure most of the times, while other like to explore and yet other players want mostly combat. Another problem is that if you only feel like playing for 15-20 minutes the kind of play you are looking for might not be available at the time. My new plan is to create the opportunities for elective mini skirmishes that the players can engage in to when ever they want.
Last week I added the two first ones. I made it so that the Condita Raiders controls all gas wells and will defend them if you try to harvest gas from them, I also made the matter melders in to objects found around the Kondosant Clans settlement that you would have to power for a few minutes to get, while constantly being attacked. I even generated some new terrain to make the battles more interesting.A trapped melder by the Kondosant Clans settlement
So far this has worked very well. Now I'm looking fore more ideas, on how to add other activities for players to engage in. While the two I have take care of players who want combat, I would like to add some that lets players interact with the AI, explore the world, take strategic decisions, and collaborate. I also would like to tie these smaller events better in to the main "story". If you steal items from a tribe will they still help you fight the domination? Can you use the fact that a settlement is being occupied to steal stuff without any repercussions?
Right now I'm planing to add some sort of world switch, that favors either power or matter based activities, and I'm looking for an interesting way to bring back prisons, so that players can mount escapes, and rescues. What would you like to see?
EIf you would like to try Love for free, just download the client here and click on the demo button to play. Also join the teamspeak channel at teamspeak.quelsolaar.com to talk to other players.
LovePosted by Eskil Mon, June 04, 2012 22:53:15
Ed Catmull, my hero, and president of the Pixar animation studio (as well as the inventor of texture mapping, subdivision surfaces, and much more) once said that there is two ways you can find out that the movie you are making is bad, either the audience tells you its bad after you have released it, or you figure it out yourself while making the movie. The difference is that if you figure it out yourself before you release it, you can still do something about it. At Pixar the goal is always to try to find problems and fix them before the films are released. The last few years i have visited various studios, and a theme that runs threw all the really good ones is how humble and self critical they are. Its not something emotional, its about being methodical. They are constantly worried about missing something, and they seek everybody's opinion in order to make it better.
A few days a go I had a conversation with a few players who complained about the fog in Love, and said it should be reduced. I found this to be very peculiar because these players have played for years and never complained before, despite the fact that I just reduced to noise a few weeks ago. So I started tweaking the numbers and after twenty minutes I gave them a new executable to try. This one they liked much better, so problem was fixed. The thing was that in the new release, I had in fact increased the fogs brightness, not reduced it. What my player were complaining about was that the fog looked bad, so they wanted me to remove it. Once I make it look good, they no longer wanted me to remove it. This is a lesson that I have learned over and over again making this game, whatever your users say, should always be interpreted as "Look at this!". How you go about fixing the issue is the job of the designer, not the player. A player can never be wrong in their opinion, but they are very likely to be wrong when it comes to how to address it.
At this years GDC I went to a full-day tutorial on user testing, but I walked out after 20 minutes for the simple reason that the people giving the tutorial, believed in what the user testing would give them answers as to how to design a game. User testing is very much like economics. No economic theory can ever take in to account every factor that influences the economy, therefore it can never be accurate. It doesn't make economics useless, it just makes it very dangerous to think that it has the answer. Testing tells you how people react to what you are showing them, not why, and not how they will react if you show them anything else. Unless you are testing the final release, the tests you are doing will have very little bearing on how people may perceive the final product. Testing is essential, but the results of testing is often also weirdly useless.
Swedish state television used to have the saying "We want to show our audience what they didn't know they wanted to see". To me this is the essence of progress, to provides something different but also great. Therefor you you cant ask your audience what they want, you can only ask them what they think of what you have already created. In video games many of the things we imagine we would enjoy turns out to be not so much fun, and some very counter intuitive thing turn out to be great, and as designers, we must learn the difference. We need to learn how to read the players feedback without taking them at face value. The more we understand about how the systems we build work, the fewer iterations we need to find the right solutions.
All this makes testing a very precarious affair in general, and if there is one thing that has been a problem during my development of Love, it is getting feedback. The problem of testing a multi-player game you are developing alone, are obvious. Further, by design Love has a dynamic environment where players are free to do what they want, and takes place over along period of time, making useful data collection almost impossible. Another problem is that some systems in the game either have limits, or are very successful, and I therefore want to be very careful about not breaking them.
An example of that is the shared resources system that gives the game have a very collaborative atmosphere where players are cooperating very well and griefers are almost unheard of. In most team or cooperative games this is a huge problem. Obviously this is great, but it also means that a new player logging in may find them selves in a game of very advanced state that completely overwhelms them with its complexity. If i would separate their experience from the rest of the group, I may make it easier to learn the game, but i would also drive a wedge in to the social fabric of the world.
Early on new players often complained about details like spelling errors in my help texts, and my feeling has always been that if that is your strongest impression of the game, the game cant be very good. I haven't head that in along time, and that tell me the game is now better (The spelling is still terrible). For a long time I believed that "good" meant attention to detail, but I no longer believe that. I believe that "good" is a hump you have to get over, and once on the other side, nothing else much matters. We love Star wars because its so good that we are along for the ride, despite its shortcomings. All the little scruffy bits becomes part of the experience and we hate it when Lucas tries to fix it. Its like when you fall in love, the person you are in love with may have all kinds of annoying habits, but when you are in love they are all endearing. If you are complaining about the little things, its because the important things are not good enough for you to forget the little things. Since testing so often brings out nitpicks about the details, it becomes easy to not see the forest for all the trees.
Yes I'm working on a new project too, a very different kind of game, and while I this time plan to put in an impressive range of tools to measure and track player behavior, It will also have to be released in a very unfinished state. I know that making a game is a long journey of trial and error, but what is scary is that most players don't see it that way. They think that the slice they play today, is exactly how I want it to be, and how it always will be. Yet, without professional testers i have no other option but to make all my failures public.
I'm still adding stuff to Love, testing things, learning things and its getting better and better (and sometimes worse), but the truth is that in a way Love missed the boat. I found out what was wrong with what i was doing far after the game had been released. I still don't know everything i want to know about it. I relesed a new versions with some things i want to test just a few minutes ago. I don't have regrets because I don't think i could have done it any other way. I had to release it in the state it was in order to find out what state it was in. The world has moved on from Love, and now its something I share with a small group of players who hang out in our team speak server, and rarely do we get new players to join, (Although you are welcome to visit, and stay for as long as you want). The servers costs more to run then the game brings in. Yet I'm having so much fun in my own private petridish where I can test ideas and explore new gameplay, and wasn't that what the project was all about from the beginning?