Friday, June 02, 2017
Anyway, why would someone who cares about performance like linked lists? The answer lies in what they allow that other containers might not. Also it lies in the fact that I am a C++ fan, not a C# or other managed language fan.
In C++, you can have intrusive linked lists quite easily, but you also know exactly where your data is. This makes it possible to have a single item in multiple linked lists.
Q: What is the reason for having linked lists in the first place?
A: For fast delete and insertion!
Bzzz, wrong. A linked list is great for making insertion and deletion not just fast, but also to allow maintaining order (try making a map-like container that stores data in contiguous ram like an array). This order element of the linked list is for me the major reason why I use them. Even for large structures, I still prefer an array (vector), and prefer reducing the size and promoting move semantics over changing core containers. No, the linked list is a great structure for having things stay where they are, whether in memory, or in order.
So, firstly, why would you want a thing to be in multiple lists? Let's start with something simple. Rendering. I want all my "mooks" to be in a "mooks" list for updating, but I want all the "red mooks" to be in the "red mook" list for rendering specific to material. Consider how I rant about existence based processing? Well, you can have an entity that represents the behaving AI of a creature, and when and only when it's meant to be active, add its "Behaving" intrusive link into the Behaviour tick list. Even if it's not behaving, it's still got to be rendering... well, until it's two rooms away, in which case it get's dumped from that list too, but if you make a noise, then it will start behaving, but still not be rendering. In this example, the order isn't important, but you can immediately see the benefit.
What about multiple orders? Some things need to tick very infrequently, but there are a lot of them. In this case, we can add a tick time, then insert into a list based on that time. This way we only check the first few entities until we run out of time delta. Sometimes we have objects that are waiting for resources to rise. We can order them by cost, and show highlights on only the first n up to the cost.
It's worth remembering that this doesn't often work well for dynamic value calculations, where each element in the set can change value, and thus require sorting every frame. Use this technique to provide a benefit when it reduces the amount of work even attempted. If the sorting has to happen more than on just insert, then it's probably not worth the effort.
Linked lists are a data-oriented design container, because of their nature of being ordered, or being simple to extract or insert into list or rings, because they offer a way to stop processing when you are sure you are done.
Anyone caught checking to see if an item in a linked list "needs to be updated" will be shot.
Anyone caught doing a foreach over an ordered linked list will be shot.
Monday, November 21, 2016
"There is another, subtler problem with maximizing. As discussed in the previous article, sharp declines in the rate of reward are very punishing for players and can result in quitting. If the player has learned to maximize their reward in one portion of the game, creating a high and consistent level of reward, moving to another part or level of the game will most likely result in a drop in reward. This contrasting low level of reward is extremely aversive and can cause the player to quit. It may even be an effective punishment for exploring new aspects of the game, as the transition from the well understood portion to the unknown marks an inevitable drop in rewards." - John Hopson from Gamasutra-ThePsychologyOfChoice
So, yeah, those planets with high sentinel tolerance, and the easy to find stone cube things that are worth around 10k a pop? They set me up to hate every other planet in the universe. I can't go back either, as I have used a black hole to jump ahead. This one way path away from happiness is a big and painful experience that everyone should go through to truly explain the meaning of the saying the grass is always greener on the other side of the fence.
I am thinking of going back to the game and fly around until I can find another one of those planets, because they are probably quite common for them to be a net meme.
But, if the risk reward systems are balanced, then it's most likely that they will be balanced away from this quick cash solution, so am I destined to be unhappy with progress from now on?
Maybe No Man's Sky 2 will have the game balance as a sanity checking stage during planet generation. I'll play that one.
Tuesday, July 21, 2015
This is something that a fair few older game designers often ignore, and it's because for a decent amount of the history of game development, design has been an airy fairy, hand waving, throw things around and see what sticks, kind of thing. It works to some extent, because a lot of the games we used to make were small enough that what we were actually designing was game mechanics. But that's not true any more. Now, games have a few mechanics they want to explore, and those mechanics might be refined over the development of the game, but in truth, the throwing stuff around and seeing what sticks stage of development is over pretty darned quick now. Plenty of companies that don't work with data have had a "great idea", implemented it, and then at publishing time, found that the thing on which they worked really hard is not received well because it's not very good. It's not even like the developers are likely to have thought it was really good while it was in development either, but for some reason, there's a blind spot for failure to make an engaging design. It's like they're frightened to measure how well the game is doing, in case they have to change something. It's almost like they're trying to win logical fallacy bingo. A bit of cognitive dissonance here, a bit of sunk-costs there, and a bit of gamblers to top it off.
Some companies make a big deal out of measuring their games, and they usually do pretty well. The spate of freemium games could not have landed such huge amounts of money without the constant attention to performance indicators. Measurements are key to a game that isn't actually designed to be "fun", but instead designed to extract cash from people with their consent. To this end, it appears that maybe the reason some people don't want to check to see if their design is good, might be that they want their game to be good without being polished by maths, or they want it to be a cult classic, warts and all. They don't want it to be as good as possible because they've sold their soul to the same people that make Cash of Beach, or Game of Candy. They want it to be as good as possible because they want to be proud that it's all their idea.
Using metrics saves you time thinking about stuff like "would the player find this too difficult" and allows a designer to concentrate on the actual inventing stuff. Being freed from having to do the laborious play-throughs and focus tests with hand written notes, gives the designers the mental space to come up with truly innovative game elements, and in house testing with feedback allows them to be able to see if they will work, or do work, without having to commit vast sums of money to them. Design, and art, love constraints, but hate the constraint of time. Give your designers and artists strict technical constraints and all the time in the world, and you end up with beautiful things. Stop them from working by not letting them utilise a universe of tools and metrics for seeing if their work is successful, and you end up with a big ball of ideas that only work in the heads of those that invented them. Nothing can be designed in a vacuum.
Graham McAllister on Molyneux's strange decision to ignore data.
"However, Peter is not alone in making such reckless statements. I was recently at a conference where a speaker was saying that all that was needed to make a great game was to hire smart people and have good ideas."
He's a different era of game designer. There's nothing inherently wrong with how he designs game mechanics, but my opinion is that he does need tempering, as without data, it's very hard for him to see what it is he does not know. Peter did found the cannery on the tagline "A great team with a great idea leads to great success".
Friday, May 15, 2015
I left 22cans because it no longer made sense to be there. I loved the idea, and I signed up to create a slew of creative experimental games or applications that would eventually culminate in a final product that would be great, if not one of the greatest games of all time. I felt like I understood where Peter Molyneux was coming from, what he wanted to do, and why he wanted to do it.
I think I wasn't wrong at the time. I think Peter wanted to make something great, grand, and successful, but his goal evolved over time, and for me, in a different direction than I had hoped for. We shared a need to make something people cared about, and to begin with, we shared a desire to experiment on a large scale. I enjoyed my first two years, working on curiosity and then working on Godus, but as we moved to free to play, I became uneasy. It's not something I signed up for, and though I'm not dead set against games that are free, such as dota and world of tanks, I don't feel right making a game with wait timers or feature pay walls that don't actually make the game experience any better. The longer we spent working on free to play mechanics, the less excited I felt about the company, and the more time I spent becoming enthusiastic about the technology.
I love working with hard technical problems, and there was no end of them with Godus. I worked on rendering landscape stuff, stuff that was dropped, stuff that made it into the game. I worked on networking and multiplayer, which was at times totally impossible (I think even provably so) but we pushed anyway. I worked on save games, and that was made harder by having to make it work with networking code (that wasn't tested, and in the end turned out to be feeding the game duff data). I worked on making things that were broken and impossible to fix, fixed. I enjoyed the successes, got annoyed at how only the failures were recognised, but in general, I think I made the most of working on Godus.
The straw that broke the camel's back was the direction the company took in early December 2014, when I was switched project away from Godus. I didn't like the game design (I won't explain the design as it is still kind of meant to be a secret) and I felt like it was completely misaligned with my values. It made me very sad. I felt depressed over Christmas, and started to look around to find another place to work. I never thought I'd leave 22cans. I didn't just feel sad about feeling like my morals had been ignored, I also felt sad about being disappointed in the company progress in general, and how maybe it could have been better if it hadn't gone the way it did. I felt like I had no power to stop the company from doing things I felt were not helping move it forward. I also felt like my professional experience was being ignored, and generally, the company direction couldn't be affected without being part of some group of people rather than being able to back up your ideas. Maybe realising that also hammered home the feeling that I was along for the ride, and not actually part of the company.
I guess I've always been attracted to the crazy and the risky. I looked around Guildford because I don't want to leave the area. I have too many friends nearby. I wanted Media Molecule, or Hello Games, but ended up with a pretty sweet offer from Epic, who I'd previously thought were too big a company for me. I like their style, they seem like good guys, and they have always made awesome games. I handed in my notice, which didn't surprise my lead. He understood my stance on f2p, and even told me he had expected my resignation earlier. I was then given a 6 week notice period, and was allowed back on Godus. I thought being back in Godus would be cool, but the problem with being on the way out was that my opinions and desires were pretty much ignored. Still much better than Rockstar, who once I said I was leaving, took my entry fob, and told me to not set foot in the building again. But then again, that did mean that I got a month off to do whatever I wanted with.
Just as I was all settled into the idea of working at Epic, an ex canner posted about how cool it was working on VR, at nDreams in Farnborough, a place I hadn't thought to apply because it seemed a bit far. It woke me up, made me double take what I was doing, and I jumped at the opportunity to do something exciting. So in a matter of less than a week, I went from becoming safe secure, working as bug fixing and tech support at Epic, to doing crazy new things at nDreams.
So what really happened? Peter Molyneux was, and still is, a constantly driven man, heading forwards, but strong enough belief in himself to define what forwards means and be able to ignore the detractors. I thought he had the same values as me, maybe we did for a short while, but I haven't the guts to admit that a company can have values a simple as making as much money as possible, and that's probably why I should never be given the chance to run a company. I wanted to, and still want to be challenged, and want to be famous for the right reasons. Right in my opinion anyway. I want to do VR because it's cool, it's on the rise, being here at nDreams at this point is great because it's like buying Google stock in 1990. It's like discovering the last bit coin. It's either great, and going to lead to something amazing, or at the least it's going to be a really interesting ride.
So I guess I left 22cans because I just didn't want to be part of just making money, and not make anything cool. Working on VR at nDreams is almost the opposite of how I felt after Godus. I now feel like I'm doing something that is risky, cool, interesting, ground breaking, and rewarding.
It's an adventure, like everything else in life, and new technology like this is the frontier.
Oh, did I mention we're hiring?
Tuesday, August 19, 2014
RULE 1: don't get hung up on doing it the right way:Its massively more important to be able to see the game live (with a terrible codebase that needs to be rewritten) than it is that you don't have to re-write. This is because usually, the design changes enough that re-writing was inevitable anyway.
RULE 2: do not design the game based on what you can do technically.Design the game, and demand things be tried out. Hack them in regardless of how "not quite how it should be done" it is. It's important to try out ideas before you invest too much time in them, and it's important to not avoid things because you see "doing it right" as being too difficult.
Following these rules, you quickly move from being someone who finishes well defined projects on time and on budget, to being a developer that can flesh out design ideas and mark them as "explored". That's the core difference of business and games. In games, the design document cannot be up front, and we use code to prove the design wrong, before moving on to the next iteration. We also never finish on time. (unless you are either a god of game development, or aren't actually doing something all that innovative)
Tuesday, March 11, 2014
But why? Why are engine programmers the best?
In my opinion, the reason why people see engine programmers as the best could be down to results. Engine programmers - and graphics programmers - often get given impossible missions, then somehow manage to pull it off. They get asked to reduce resource usage, then get told the ratio, something like "Hey, you know we allocate about 1GB for resources, well, we want an iPhone version, and we need to get it down to 50MB", or "This game looks great on the XBox and the PS3, but can you make it look just as good on the Wii?" These are obviously things that are impossible. These are things that engine programmers normally see as challenges. Once the stage is set, these programmers will make strange movements, cut resources by half, or in four, will reorder the rendering, will adjust the way the system works to squeeze out the last bytes and cycles. Generally they are seen as gods and heroes because they don't just do the impossible, but they do it repeatedly.
Well deserving of their praise are the engine programmers, for they are the bringers of savings, the enablers of features, the gods of getting it done, and the princes of performance over politics.
But they have it easy. They have the benefit of a restricted set of inputs, outputs, and they are allowed to do things any way they like, as their how, their implementation, is not seen by the user. There are other branches of development that are much more scary; often those developers don't get the praise they deserve.
Game-play programmers have to work with a constantly evolving design. Game-play code often starts out very clean and the design of the game is often reflected in the code. As the design changes, those changes bend the code into the mess we learn to hate. This constant evolution can leave the code base in a bad state, building up technical debt, ultimately leading to a horrible mess of code that does what the game-play programmer expects, but only in the situations they had thought of. Bugs creep in everywhere, slow down the development of the game, and usually someone is blamed for bad coding practice when all they were doing really was just trying to keep up with the engine programmers.
Then there is the User interface programmer, who usually has to work with UI frameworks, because style must be consistent, even if the interaction with the framework is not. Linking callbacks to states, and states to visuals, and visuals to input possibilities. UI has to show state when it changes, such as toasts, health bars, dialogue, and modal dialogues. They are in charge of making sure you see the achievement or trophy, without distracting you from the game. They have to work with constantly moving data (the game's state is always in flux) and moving output format (usually a high level designer will make sweeping changes that affects how the data is transformed into the on screen representation, and then complain when told it will take more than one day to put in an extra column on a scoreboard). The UI programmer faces the same challenges as the game-play programmer, the same crazy design changes, but without the kudos of it being part of the game. Can you name one famous UI developer?
Then we get to the dirtiest of programming jobs: the network programmer. Like an engine programmer, they have to do the impossible. They have to link up multiple machines, keeping the latency down while managing to keep everything synchronised, working with the same or similar crazy race conditions you face in multi-threaded code. They have to change everyone else's code so it doesn't reference other entities by pointers, doesn't waste space or bandwidth, or take a too long a time to figure out what needs to be sent in the first place. These gods of high latency shared state are obviously doing something extremely complex, but you don't often see much being said about them. Maybe that's because they are too busy fixing bugs that you just introduced by changing something in the player state based on an unsynchronised global variable. Sure, maybe you can name one network game developer, but do they have any hair left?
Oh, I guess there is always the guy that does all of those things at once, but indie game developers get a lot of kudos. So at least there is that. Still, I think most people would like the easy life of doing the impossible, to a slow moving specification, with obvious visible results. Most people would probably like to be the engine or graphics programmer. Because they are the best.
Tuesday, October 29, 2013
I'm making a tiny stand. I encourage you all to decide for yourself if you want to do the same. I make my tiny stand so you know someone else is too.
The recent news about Ryse, and the furore over our own 36 hour marathon has kept this at the forefront of my mind, and when GTAV came out, I felt that I couldn't bring myself to buy it. I've been waiting for this game, and I really do want to play it. I love RockstarGames games, and I enjoyed working for them, but at a cost to my family that I didn't see at the time. Maybe a bit of Stockholm syndrome, maybe a bit of pride, but definitely not right. I make my tiny stand for my wife and children.
So, before I go buying a game, from now on, unless it's an Indie title, I'm going to have a look at the quality of life at the studio before I part with my cash. Call it voting with my wallet for a better life for all those like me. I make my tiny stand and give my money to someone who didn't cause a breakdown.
The colleague asked: why bother, you can borrow my copy?
If I do that, then that's as good as me pirating the game, that's not the point. I need to point out that we shouldn't play the game, not just not buy it. Any boycott should punish the person boycotting too, otherwise it's not a message that carries any weight. I make my tiny stand, and stand by it.
Other games I am not going to play, or ever play again:
Uncharted 3 - Naughty Dog announced : “We absolutely killed ourselves on this project. I think this was the hardest thing any of us have ever done.”
Pretty much anything by E.A. / RockstarGames.
I currently feel safe to play:
Anything recently made by Insomniac
Magic the Gathering Online and the up and coming Carmageddon by StainlessGames
Dishonored - Have it that they only did 2 months over 3 years, only 12 hour days 4 days a week.