Ultimate coder challenge blog #2

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
-Reading Cut/paste
-Opening file requesters.
-Directory search
-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)
-Mouse warp

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:
-Multiple Pointers
-1-3D Axis
-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
-View Vantage
-View direction

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 fast feedback!

  • Comments(1)//

Ultimate coder challenge blog #1

EverythingElsePosted by Eskil Mon, February 18, 2013 23:38:04
Intel 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.

Your 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 physical hardware.

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!



  • Comments(2)//

Rock paper SwissArmyKnife.

LovePosted by Eskil Thu, January 10, 2013 23:42:31
When we think of game balance we often think of "Rock-paper-scissor". It has become short hand for a perfect balanced game where each move have a perfect counter. The problem with Rock-paper-scissor is not that it is a unbalanced game, but that it isn't fun. The more I develop games, I realize that this definition of balance breads a bad mindset that creates less fun games because its a form of balance that precludes strategy. If i select paper you dont have to think very long what you would do to counter me. All the strategy is embedded in the rules instead of letting the player be the one who provides them.

In chess the different pawns have radically different powers, yet any pawn can be the one that puts the opponent in check matte. In the chess community there is a ongoing debate how to rate the value of the different peaces, yet their true value in a game of chess is always in the end determined by how the player chooses to use their peaces. The power of a chess peace is chiefly decided by its position on the board. In the hands of the right player any pieces can take any pieces. This is a radically different view of balance where the game doesn't become unbalanced just because the queen can do more then a pawn.

In my opinion the goal of balance is to make everything overpowered occasionally, but make nothing overpowered all of the time. The goal for any player in any game should be to try to get in to a situation where the tools available to the player becomes overpowered. If nothing is ever overpowered the game becomes pointless because no strategy is better then any one else. Just like in Rock-paper-scissors.

The strategic element of game should always encourage the player to be creative and reward innovation and knowledge by empowering the player when he or she does something smart and creative. When designers create units, weapons, abilities or mechanics they too often have a play style in mind. A tank, medic, sniper or spy have by their very classification taken away freedom from the player by telling the player how the classes or units are meant to be played. Instead i advocate making units with an interesting collection of abilities and stats that do not point to a specific play style. If you give a unit a sniper rifle then put a big bayonet on it, to break up the assumption that the only way the unit can be effective is on a very long range. Often when designers find that new play styles emerges that don't fit their intentions, they nerf the away the creativity of their players in the name of balance instead of embracing it as a part of the game and balance it in order to keep the innovation.

When developing LOVE I was originally very concerned with the potential for any ability to break the game, but now I'm more concerned with things that aren't occasionally overpowered. The trick is to just make sure that each mechanic is only overpowered in a very limited time frame and situation. When i created the pod system with 20 different pods I gave the players a range of very overpowered tools, and to balance them I just made them scarce. As I have developed the character upgrade system I made it possible to to get any pod type the player wants instantly, encouraging a player to be able to see an opportunity and then instantly make use of it. Once the pod is used it has a cooldown period, forcing the player to find a creative use for another pod type. If the player has enough possibilities just thinking of using the right one at the right time can be enough of a challenge that you don't need to worry about any of them are overpowered.

Imagine all the numerous settings that goes in to designing a gun. A few obvious ones comes to mind, like damage, rate of fire, clip size and bullet spread. These are usually not very good if you are trying to make an interesting game that promote different play styles. If you put these in to a spreadsheet it quickly becomes clear what guns are best and players will naturally gravitate towards these guns. But then if you start to actually implement a weapon system you realize that there are huge amount of very different properties a gun can be given. Is it quiet? Does it have a mussel flash? Does it set things on fire? Can it nail things to a wall? Does it give off an electric shock? Is the shock delayed? These kinds of properties are much harder to compare and their usefulness depends much more on play style and opportunities. They are far more primed for player discovery and creativity. Damage per second and other under the hood numerical settings should only be used for fine tuning not to set options apart. This is especially true when you can combine elements. Making a near sighted artillery unit, may not be as asinine as you think if it means that players can experiment with using other units as spotters.

Another common problem is that game designers think that they need to give all options drawbacks in order to balance them. Team fortress is a great example of a game where rather then choosing what abilities I want, I feel like i have to decide what disability I can live with. Do I want to be slow? Not be able to turn while I shoot? Not be able so shoot without scoping? Only be able to shoot 3 shots before i need to reload? Ten people with different superpowers can be just as balanced as ten people with different disabilities, its just much more fun to play a super hero. If something is fun and overpowered, maybe you should make everything else as fun and overpowered too rather then try to nerf away the fun?

The reason we want to make games fair, is because unfair games aren't fun, but if our method making the game fair is to take away the fun then what is the point?

  • Comments(7)//

Why Obama might lose

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.

  • Comments(6)//

Love servers will be released.

LovePosted by Eskil Fri, September 14, 2012 19:17:25
A few days a go I was out having lunch and I was thinking about punishment in games. Its a topic I have been thinking a lot about. Games with harsh punishments like permadeath can be very effective at increasing the tension, but they can also become very frustrating. In a game like love that it ultimately cooperative it is easy to fall in to trap of collective punishment. Then i thought of a interesting solution to this, a spawn timer that forced players to stay in the settlement for a limited time after dieing. If I would have gotten this idea a few weeks ago I would have just implemented it, told my players about it and seen how it would have worked out.

Love has always been about experimenting with new ideas, but I cant do that anymore. After last week I have seen an explosion in new players and interest. It has been absolutely amazing and it has been a massive success and donations are pouring in. But it also made it very clear to me that too keep changing the game like I have in the past, for the players I used to have, just wont work. Many of the new players needs less players and action, they need a calmer safer environment that doesn't change to experiment in. To them Love needs to become more stable, and not have me constantly put new experiments in there. In many ways it has already become more stable just because I am now much more happy with the game, so fewer major changes are needed (and the fact that administrating the ballooning number of servers and players is taking up so much more of my time). This however is not enough. Love needs to be able to branch for different players and skills.

This is why I have come to the conclusion that letting players run their own servers is the best way froward. Its been requested many times before, but with very few players it always felt better to have everyone gathered in a few shared servers, but now things are different. The servers are over populated.

The new servers that you will be able run yourself, will be configurable in various ways so that you can run them with or without AI, you will be able to re-seed when ever you want, you will be able to save several copies of the world, put a password on them, and pause them.... and maybe just maybe I will make some options to make Love more punishing. I will still run my own servers that will be accessible to anyone.

This was not something I planed, so I will need to take some time to work out all the details. I need to redesign a significant part of the master server architecture, and will need to expose these options in some new way. Anyone who has donated 25$ or more in the last week will have gotten an extra voucher code, that I originally intended to use as a Beta/Alfa code for some future project. Now I'm instead going to use this as a voucher code for running servers. If you have donated 10USD in the last week and now wish you had put up 25$ to get a server voucher, just E-mail me and Ill figure something out (Or you can just donate 25$ now...).

It will be a few weeks until I'm able to release the servers publicly, but I'm working as fast as I can to make them ready for public release. Luckily PCGamer has stepped up and will in a few days start running the the first beta servers that will allow me to test this. I cant thank them enough for all their support!

  • Comments(8)//

Love Dev Update #2: Clarity

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.

Will trigger a rain storm a that will eventually flood the entire world, causing all power sources under watter to stop functioning.

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.

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)

The occupying tribe will get access to the massive artillery peace in the red settlement and will begin shelling players in its hemisphere.

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.

  • Comments(12)//

Love Dev Update #1: Pacing

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?


If 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 to talk to other players.

  • Comments(2)//

Testing, testing, is anyone out there?

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?


  • Comments(10)//
« PreviousNext »