EverythingElsePosted by Eskil Sat, March 21, 2015 03:58:20
While testing the micro design of my new RTS game EXO I'm currently designing the macro game, and I have been considering a number of different design concepts.
To begin with, since I am making a strategy game, it may make sense to define "strategy". Its easy to think that just because you move around troops from a top down prospective you are dealing with strategy, but in my definition strategy is not combat, it is setting something up that gives you an advantage later. This definition creates two core differentiators when designing a strategic element, the first being pacing. There needs to be enough time to take a strategic decision and then some time before it pays off. The second observation is that Strategy doesn't decide the outcome, it mealy tilts the odds, while action is the final decider.
Judging by this definition EXO is in its current state almost entirely is an action game and not a strategy game. This is why I'm considering how to add a new layer of strategy to the game, and in this article I will outline some of my intellectual work on the subject.
The athlete and the coach.
What is the most accessible sport, running or a card game with a 1000 different cards? Well most people can run, so in a sense running is a game that almost everyone can do. Its a simple and elegant game. A card game with a 1000 cards is hard to learn and will take a lot of time to get in to. On the other hand, if you start training to become a runner, your running wont improve fast, and your training will also provide diminishing returns as you get better. No matter how much you train you are very unlikely to ever be good enough to compete in the Olympics because very few people has the DNA required to do so. The card game on the other hand wont be limited in such a way. If you learn a single card every day then 3 years later you will have mastered the game.
Knowledge is easier to gain then skill. This is why MOBASs with hundreds of Heroes and equal numbers of items don't feel as intimidating as one may think. While playing Quake is easy to pick up, it still seams insurmountable to most people. Creating knowledge complexity is therefor a good thing, because it allows anyone to claim ownership of the game by gaining knowledge about it.
When a sports team does poorly the question of replacing the coach inevitably gets raised long before anyone talks about booting out the players. Why is this? Its because the Coach has knowledge not skill, and everybody things they have or at least can have knowledge too. It is clear to most of us that we will never be able to kick, run or throw like a professional athlete, so when they fail we tend to be forgiving, but we all think we can do the job of the coach since it is purely intellectual. If a coach has to decide what player switch out, its a decision any of us can make, so when the coaches gets it wrong its easy to label them incompetent, no matter how many factors they considered internally.
The coach is the spectators proxy, we all imagine ourselves being the coach when we watch a game, because they make the same decisions as we do in our heads. A game like 100 meter dash is very hard to have opinions about because its all just about athleticism. Our only advice to the participants would be "Run really fast!". As soon as we move up to longer distance running we can start having opinions about strategy of when save your strength and when to go for it. If you are designing a game for spectators, it makes sense to create a large space for audience participation by making the type of decisions made by a coach a large portion of the game.
A turn based game, forgoes the "athlete" entirely, and is therefor a much more comfortable and less stressful experience. But it also removes the ability to in a dramatic manor beat the odds, by executing a perfect play. Just as there is value in a game allowing for a player to carefully set up a trap, there is a value in allowing a player to think on their feet and improvise themselves out of a tricky situation. This is the balance between the coach and the athlete.
One of the core things that you are looking for as a designer of any kind of game, is to create as many possible outcomes with as few rules as possible. Chess being the obvious example of a game that does this brilliantly. You can teach the rules of chess in a few minutes, but the possibility space of those rules can occupy a lifetime. Learning the game in chess is not about knowing what the peaces can do, but to see the possibilities afforded by what they can do. This makes the game both easy to get in to and hard to master. Ideally you want the spectator to instantly see the genius in the masters moves.
The way that i prefer to create a large possibility space is create many interlocking systems. If you have a game with 10 weapons, you have 10 choices, but if you have 5 weapon's and 5 armour sets, you have 25 combinations to chose from. Rather then increasing the length of the array of options you increase the number of dimensions of options. This also makes the game easier to learn. Even though you have 25 combinations of armour and weapons the player still only have to learn 5 weapons and 5 sets of armour.
How do one dividing the game in to segments of action and strategy? Strategy by its nature must be made over a longer time period, and should not immediately pay off. If you instantly get feedback from a strategic decision and the instantly can change your decision in reaction to the feedback then the decision ceases to be strategic. (This delay also often cause another design problem since it often makes the cause and effect less obvious)
Many strategy games divide their games in to early, mid and late game and gate abilities in such a way that it makes sense to wait to first tech up and then later attack. Early defence is deliberately stronger then early attacking units to slow down the pace of the game so that strategic decisions can be made. I kind of dislike this structure because it forces the game to play out in a specific order, I also don't like that many strategy game tuns in to 20 minutes of building, 30 seconds or fighting, the end.
Some games like MOBAS allow you to make important strategic decisions before the game starts (The pick and ban) and while this creates a lot of strategy it limits the possibility space, since players can change these decisions later in the game. The ideal game should allow you take multiple corrective decisions over the course of a match. MOBAs also control pacing using towers and other structures that are overpowered until the players has taken considerable time to level up. I find this a bit too rigid for my tastes.
Starcraft on the other hand is famous for its rushes, and Strctaft also allows you to make tech switches at any point, but it still limits you to a single race in game (Yes i know that Zerg can build Terran and Protoss units too). Early in in EXOs development i considered having multiple races in the game, but i now see that it is an ineffective way to create a large possibility space as choosing your race limits the combinations of units you can use. I find that its a missed opportunity that the most important strategic decision you make is a decision you make only once, as most players stick with one race for all matches.
These are games where multiple matches are stringed together so that players can redo their strategic choices between individual games. Counter-stirkes economy, or the limited supply found in Due process are excellent examples of this. I'm considering a tournament mode like this for EXO. Its understandable that its convenient to stop the action an let players think threw their strategies before the action restarts, yet it would still be better if decisions could be taken at any time.
To do this the games pace needs to fluctuate and at least partly be controlled by the players. Preferably a game should naturally have peeks of intense action and valleys of calm where the player can take the time to make more strategic decisions.
One of the core experiences of playing a strategic game is being able to think about it when you are not playing it. Your best strategies will be devised while in the shower, or in bed or while day dreaming at school or work. I think anyone who has ever been in to a strategic game has had the urge to play it just to try out some new strategy. The problem with this is that you don't want players to be able to always execute a strategy they have planed out before hand. The game becomes stale and not very exciting if players keep executing the same builds over and over again and again. If different builds counter each other too sharply, the player goes in to the game with one build, and fate decides if the opponent has chosen a build that is either strong or week against what the player is doing. The game turns in to Rock paper scissors and that is not a very interesting game. On the opposite spectrum you have card games where each game is played entirely differently depending on what cards are dealt. Ideally you want something in between where players can think up strategies outside the game, but where the game wont always be conducive to the execution of every strategy.
Balance is obviously very important for a competitive game, but i have started to think that rather then seeing balance as something good, maybe it is imbalance that is bad. Having a perfectly balanced game doesn't give you anything, its just that not having your game balanced will ruin it. Where as designers try to design games that have as many viable strategies as possible, players are trying to figure out a way to break the game by finding a single strategy so good it makes all other option worthless.
In a game like Starcraft with 3 different races almost all of the designers energy gets dedicated to keeping the game balanced. The designers cant just come up with a new unit idea and throw in in to they game, they carefully have to re-balance the entire game to take the new unit or feature in to account. To me it seems very inefficient to have a system where players constantly try to break the game and forcing the developer to constantly try to fix it. Therefor I think its important to build in to the game some sort of self balancing core mechanic that lets the designers be more creative.
A typical example of a self balancing system is where you divide a cake by having one person divide the cake and the other choosing one of the two peaces. MOBAs that employ a pick and ban system remove the spikes of over powered units, but does little to promote under powered units. A market based system where prices for less used items drop while the popular stuff rises would be even better.
I think its important to try to make player centric balance rather then opponent based balance. In Starcraft the Stim is an important upgrade for Marines in order to be able to counter speed Banelings. Stim makes the the marines able to go toe to toe with the Banelings, and is therefore balanced against Zerg, but having Stim is not at all balanced against not having it. There is no question IF the player should get stim, only how soon he or she should get it. If Stim was expensive enough or negated some other possible upgrade, the choice to upgrade Stim would be much more interesting.
I prefer strategic tech decisions that are different or temporary rather then just better. Lets consider a game with 3 different sets of armor. A traditional way to design it is to have armour level 1, armour level 2 and then finally armour level 3. The problem with this is that there are no interesting decisions for the player to make. The story in the game is already set. A more interesting way to design it, would be to have one anti fire armor set, one anti poisoning armor and a magic set or armour that makes you invulnerable for 10 seconds once a minute. Now the player has some interesting decisions to make and it makes sense to switch back and forth between the different armour sets many times as the game progresses.Where I am.
Right now I'm considering a system where the map has a bunch of resource nodes, that are all "Plugged" so that the resources inside are inaccessible. The players can set a number of units to pop the cap of the resource. This requires some units to be present for a time. Once the node is opened, it starts giving the holder resources. The opening of the node gets announced to the other player, and by capturing the node once it is opened an opponent can steal the resource. Since the resource only flows for a short period, it creates a temporary focus point of the game. Once the resource is tapped out the players will move on to harvest another node or attack.
My current idea is to have three or four different resource types, and have each upgrade require one or two of the resource types. By making the resource type provided by the resource node unknown until the player has "popped the cap", I force the players to adapt their strategy to the resources dealt to them. I think this could be a good middle ground where builds can be pre-planed depending on different resource combinations, but where the player never can be sure what a specific game will bring in terms of access to the tech tree. I'm considering have the price of different tech options dynamically fluctuate in price depending on their popularity.
I want to thank Chris Thursten
, Mahmud Din
and Richard Lemarchand
for their input.
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!
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?
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 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!