Four pillars of games / entertainment

Comments

  • Yes! That's exactly the point.
    Yes. That's exactly the point.
    Fucking double ninja'd!
  • edited
    Yes. That's exactly the point. Eventually you'll find one prototype that simply has to be finished, something that, if you're not working on it, leaves your soul burning and empty. And that's a good thing too: Rather than being a waste, those prototypes allow you to stretch yourself as a creator (how would you practice writing, other than writing short stories - not novels) AND give you inspiration and possibly gameplay tools for other projects in the future. The larger your unfinished prototype pool, the more likely you are to reimagine a concept in one of them in a new setting and it'll just fit this time around, when maybe it didn't before.
    I totally agree with this. Over the last 6 months I have made 15 stupid little prototypes to test a mechanic/story/idee and only one of them stuck. But the feedback I have gotten indicated the one that stuck is pretty good.
  • That video @blackships shared about creativity with John Cleese speaks about allowing yourself the time and the space to be creative. And I know from experience that the best creative work we do in advertising are often only ever done after heaps of throwaway ideas.

    Thinking that one could create an entirely enjoyable experience with one try without discarding things along the way is pretty naive, I've learned, both from 9-5 and my own pursuit of games. Iteration is the process of creation, and one thing adds to another. A sketch is built up over layers and layers of erased things, ads are built up over many discarded concepts, etc.

    The 'waste' in a discard is much less significant than a 'waste' in overinvesting in on ideas that you execute on without testing testing testing :)
  • edited
    Yeah. Failing fast is pretty indisputably better than failing slowly.

    I think it's fairly uncontroversial to say that going through lots of sketches for games (like going through lots of actual sketches in illustration) is vital to master the medium. And the speed at which you can implement an idea and test it (and dispose of it if necessary) is very closely related to the speed at which you learn.

    This isn't confined to mechanics though, it's true of any medium. But it's especially true of any aspect of a game that is interactive or conveyed through interaction, simply because it is so much harder to predict how it will be experienced than in a non-interactive medium.

    Daniel Cook talks well on why failure in game development is so important, and it's so important to feel okay with failure, because fearing failure is anathema to creativity: http://www.lostgarden.com/2007/10/lesson-about-failure.html (Though Daniel Cook focuses on mechanics because that is his expertise).

    Some of the misconception people have with failure is summed up here:
    Daniel Cook said:
    Much of how creative people see the world is marred by the success bias. We are constantly surrounded by successful, beautiful creations.
    For me though, failing faster is only one aspect of why bottom-up design is more reliable and produces better results than top-down design.

    Here are the Pros and Cons in my mind (and I have tried both methods several times).

    Top-Down design (as in making decisions based on the idea of the final game, and is characterized by directed behavior intended to produce a specific result)

    Pros:
    • Can be explained to clients vastly easier (since the end product is envisaged).
    • Can achieve a specific result (if the you have a lot of experience in building similar games).
    • Can be more efficient (because a clearer goal is easier to work towards).
    • Can be inspiring at the start of the project (when most of the creative work is done).
    • Can work well in situations where the game isn't very interactive (because assumptions will be more reliable there).
    • Is easier to organize a team around at the very beginning (selling team-mates on the end goal).
    • Makes it easier to conceptualize meta-games or long gameplay loops.
    • Is easier to co-ordinate with teams (because everyone can know what they are working towards).
    • Can be easier to get investment in (selling the envisaged final product can be an effective tool, particularly in crowd funding).
    Cons:
    • Decisions are based on assumptions (which will most likely be wrong if you haven't made a similar game before).
    • Changes in direction (based on feedback) are more wasteful (because work is being done based on the end goal and may not fit with a new goal).
    • Changing direction (based on feedback) is really difficult (emotionally as well as time-wise). And so projects are inherently more likely to be mediocre experiences.
    • Can lead to outright dead ends with no enjoyable product to show for it (because the idea of the game was enjoyable, not necessarily the prototype).
    • In the event of a failure that also fails to test the idea, you may fail to learn anything from the failure (because you might not have adequately tested the idea).
    • Can take a long long time to fail (because the final product is assumed to be enjoyable).
    • Can be uninspiring towards the end of the project (because the creativity is font-loaded).
    • Less time is spent being creative (so results are more conventional).
    • Can lead to dangerously low morale at the end of projects (because all the creative work is finished). And mistakes get made in those circumstances, which can be a nasty downward spiral.
    • Having to make decisions based on assumptions is riskier and so conventions are more heavily relied upon.
    • Is especially poor at handling very interactive systems (because assumptions will be more unreliable the more interactive the system).
    • Allows developers to ignore feedback, or post-pone their response to feedback (because the feedback is relevant to the current prototype, not the imagined final version).
    • Doesn't necessarily focus on moment to moment gameplay (and so the core of the game is less likely to be enjoyable).
    • Can be worse with motivation to get things done, especially with working with other people, because you have to state your goals to other people.
    Bottom-Up design (as in making decisions based on the current working version of the game throughout development, and is characterized by experimentation and testing)

    Pros:
    • Decisions are made based on evidence, and those decisions are tested before more decisions are made that rely on them (so the decisions are as reliable as they can be).
    • Failure always produces a testable prototype, and so always allows you to learn from your mistakes.
    • Failure comes faster (and so less time is wasted on doomed projects and you build a repertoire of tested ideas faster).
    • More time is spent being creative, because decisions are delayed until implementation occurs (so decisions can be more innovative).
    • It is easier to change the direction of the project (because you will not have invested emotion in the idea of the final game, and will not have produced content to facilitate that end goal). And so projects are more likely to improve with player feedback.
    • Morale is distributed better throughout the project (because you aren't forced to follow your past self's decisions, which is a big deal for me because I don't like to be told what to do, even by myself).
    • Is far better at handling very interactive games (because decisions aren't made on dangerous assumptions of how players will experience interaction).
    • More time may be spent listening to feedback, and so learning to understand players can be faster (for the current project and future projects).
    • Is better at building communities around the game (because it means having a playable version of the game from the start).
    • Much more likely to put focus on moment to moment gameplay, so makes you more likely to produce a game with a solid core.
    • Projects that have a solid core make it easier to attract experienced teammates (ones who will not be sold only on the idea of a game).
    • Is better suited to inexperienced developers, or developers who are attempting something outside their comfort zone, because in those circumstances their assumptions will be even more unreliable than usual.
    • Can be better with motivation to get things done, especially in teams, because you don't necessarily have to state your goals to other people.
    Cons:
    • Does not work well with clients (especially clients that don't understand game development).
    • Is difficult to predict the end result of the project.
    • Can take longer to complete a project (because more ideas will be tried during the course of the project).
    • Makes communication much more difficult (as not having a clear end goal means communication has to be immediate).
    • Is harder to work with large teams on or with remote teammates (because of the already tricky communications).
    • Makes conceptualizing meta-games or long gameplay loops harder.
    • Incentivises working in very small teams at the start of the project (which might not be ideal).
    • Is harder to invest in at the start (because the early states of the game won't necessarily represent the final product well and the end goal is more effusive).
    • Is a more challenging process to follow, because humans naturally want to make decisions immediately, and following a bottom-up approach means leaving problems undecided upon until after a solution is implemented and tested. Resisting the urge to make premature decisions is actually difficult (as John Cleese explained in his talk on creativity ).
    I think towards the end of game projects a certain amount of predicting the final product is necessary. If not in marketing then in trying to tie the longer game loops together as a cohesive experience. But I think in the early stages of a game's development you are more likely to produce innovative/excellent results if you work according to a bottom-up approach (except in client work where that is not a possibility, or if you're designing a game according to an existing formula).

    I also think it is very easy to transition from bottom-up development to top-down development (or somewhere in the middle of the two), but much harder to transition the other way around (because of time investment and emotional investment as well as outside factors like investors who may have already been sold on the idea of the final game).

    I don't think that in bottom-up development there should be no idea for the game. There can be an idea of course, and maybe even a fanciful imagining of the final product.

    But that idea should not be used to guide decisions (in bottom-up development). Thinking about a story (that is far away from being implemented) is fine, but using that idea to dictate game mechanics or music or theming or other story elements or art-style means basing those decisions on assumptions, which isn't bottom-up development. The same goes for thinking about the way the game looks, or thinking about how it plays.


    That said, what does everyone think of those pros and cons?




  • I think that's a pretty damn useful breakdown, personally I'm more inclined to bottom-up (and I would argue that all the most successful projects I've seen have been bottom-up too).

    When I was doing client work I managed to sell them on the idea of doing exploratory prototypes and would end up doing most of the game design work in those, meaning I could take a very bottom-up approach (provided the client was okay with seeing something that played well but looked and sounded bad) and then the client would be involved in the decisions that took a project further. That worked really well.
    Thanked by 1EvanGreenwood
  • edited
    Yeah, I was mentioning to Merrik today how QCF managed to sell clients on exploratory prototypes.

    I feel like that takes some seriously steely stares, eloquent wordplay, masterfully arranged info-grams, and intoxicating aftershave to pull off. As far as I am aware it is an unique achievement.
  • And budget. Client work = marketing = budget, and budget = time. And typically there's no budget or time. I don't know how you pulled that off @dislekcia.
  • edited
    I think just about all AAA games, and just about all AA games follow a mostly top-down process.

    Though there is of course some experimentation there, but it is experimentation to fit into an already decided idea of the final product.

    And it kind of has to be that way. The teams are sooo big and burn so much money that they all have to be kept working, and the communication overhead in doing that is staggering. And investors need to know the game is a sure thing, because even running 1 month of a studio that big is a massive amount of money.

    As I recall, my motivation for bringing up this thread derailment in the first place, was that most academia focuses on Top-Down development. I expect it is partly because they're primarily servicing AAA, partly because Top-Down development is much easier to teach (teaching Top-Down game development is similar to teaching creative writing or furniture design), and partly because the people teaching Top-Down development don't distrust their assumptions.

    Also, I think it's fair to say that Top-Down development *theoretically* works fine. And in very simple games, or games where producing prototypes of ideas is relatively trivial (like board games) the "cons" of it are not apparent.

    But in practice, in any game project where the execution of an idea is non-trivial, Top-Down development allows human error to snow ball and the development process becomes increasingly unstable. Whereas the advantage of Bottom-Up development is that it encourages problems to be solved as they occur, and mistakes are less likely to be compounded.
  • Even the top-down approach is built upon MANY MANY MANY layers of bottom up - previous games, the team who've built tons of games bottom-up, etc. Bottom-up generates experience, Top-down only really works if you've (you as in the whole entire team, like AAA studios as a collective) had megatons of experience.
  • edited
    @Tuism: I wouldn't be too sure about that. The games industry is famous for having incredibly large rates of churn (new people coming in to jobs as the people in them leave/are fired/companies shut down) and a really fast burnout threshold. That means that most of the people working in the AAA industry are usually pretty inexperienced. Sure, there are usually senior people on each team, but they're not always guaranteed to be at management/decision-making level, so you end up with new people holding the purse strings and new people making the game, with experienced leads trying to hold it all together.

    That should go some of the way towards explaining why the same mistakes get made over and over again and why there's a lot of focus put on corporate communication and trying to "preserve learning" in the production tracks at GDC.
  • Fair enough, there's not always gonna be the best people in the best teams making the best decisions even in AAA.

    Though my point was that the best scenarios and the best case for top-down approaches are usually ones built from a lot of bottom-up experience already, right?

    Otherwise what we're saying is that there is never a case where top-down is good (other than the client-and-budget-satisfying thing, which puts "a good game" second.)
  • edited
    @Tuism I also don't think that most people making AAA games have gone through a lot of bottom-up development to get there.

    I think most people working in AAA (or AA etc) have done top-down development their whole careers. From game development colleges (or through comp-sci etc) and then onto massive projects (I don't know many people working in AAA but that was their experience).

    The reason why AAA games can continue to do well is that they throw all the money at polishing conventional designs, squeezing juice out of hardware, and producing masses of content. Some people at the top of the big companies have decades of experience, and that along with relatively bottomless budgets keep those projects alive.

    Bottom-up development is really difficult to pull off with a team of more than 5. Not impossible obviously, and it gets easier to add people as the project starts to take shape.

    Even in the size of team we have at Free Lives it gets really difficult. There have been far too many times that someone asks me "what are we do in this aspect of the game, I need to know to work effectively" and I have to tell them "I can't possibly tell you because we haven't got there yet and you're asking me to make guesses". And then we have to sort of make compromises or rely on best guesses (which doesn't always work out).

    And a lot of people who want to work in AAA simply don't want to make indie games. They'd rather teach engine programming until they find a job doing that than make indie games (for instance).

    [edit]
    Tuism said:
    Otherwise what we're saying is that there is never a case where top-down is good (other than the client-and-budget-satisfying thing, which puts "a good game" second.)
    Top-down can be better for games where the implementation of the interactions are trivial (like Dear Esther, which was originally a mod for Half Life2). There's no advantage to designing a game like Dear Esther (in those circumstances) with any other approach than the approach that works for writing novels.

    Top-down is better in AAA (for all the advantages I listed). Bottom-up development would kill a project of that size. I'd expect the communication overhead to be unmanageable.

    The closest I've heard of AAA developers getting to bottom-up development is for small teams to be prototyping separate ideas which they hope to incorporate back into the main project (which AAA developers do do, and very often developers spend months or years on prototypes that never make it into the final game).

    Also I think bottom-up experience != top-down experience. Particularly if you are moving from indie to AAA (or visa versa). The game understanding (or the art understanding, or story understanding) is mostly transferable, but, if you are one of the people making decisions on the game project, you need to be able to make the best decisions for that system.

    ... Full Disclosure: I have never worked in AAA. My opinions are based on only a few points of reference (and a bit of extrapolation from having worked in teams of several people and teams of only a few).
    Otherwise what we're saying is that there is never a case where top-down is good
    Also, it's a field of probabilities. A top-down approach might work fine for a small team. It might even result in a better game. But it probably won't. So it'd be impossible to say "that there is never a case where top-down is good" even with a small team. But it'd be fair to say that there are a lot of disadvantages to that approach in certain circumstances where their may be advantages to a bottom-up approach.

    Also. I know of at least one author who writes books with a bottom-up approach. Tom Robbins
    Michael Dare said:
    When he starts a novel, it works like this. First he writes a sentence. Then he rewrites it again and again, examining each word, making sure of its perfection, finely honing each phrase until it reverberates with the subtle texture of the infinite. Sometimes it takes hours. Sometimes an entire day is devoted to one sentence, which gets marked on and expanded upon in every possible direction until he is satisfied. Then, and only then, does he add a period.
    And then he starts on the second sentence, and sees where that takes the story.

    It shows. He wrote some of my favourite books. And many of my favourite sentences.
  • edited
    First of all, I'm not feeling up to reading through quite everything that has been said since last I posted, although I've skimmed over those posts, I believe, so I apologise in advance if I've missed something that should be said, or if any of my points have been obviated, or if my arguments are not at their best.

    My major point, perhaps, is this: what works for one person may not work for another, and what fails one person may work wonderfully for another.

    Regarding "top-down" vs "bottom-up", I'd like to note that I feel that "bottom-up" development is likely to produce a different set of games to "top-down"; for example, I suspect that "bottom-up" would likely have a problem that I seem to recall appears in genetic algorithms: getting stuck in local maxima, potentially missing higher peaks. "Top-down", on the other hand, might produce mechanics that might never be found by "bottom-up" by virtue of producing a different set of conceptual "environments" from which they might arise.

    I'm not saying that "top-down" is better than "bottom-up"; what I'm saying is that "bottom-up" isn't suited to me, that both methods are perfectly fine, that each might serve different people differently, and that "top-down" isn't "naive and wasteful" for me.
    When he starts a novel, it works like this. First he writes a sentence. Then he rewrites it again and again ...
    I seem to recall that I've also seen writing advice that directly contradicts this, that advises writing the whole thing out, good or bad, and then going back to re-work it.
    [quote]I strongly suspect -- based on experience -- that attempting to build a game that way would result in lots of prototypes being made and never finished.
    Yes. That's exactly the point. ...[/quote]
    The problem is that, as I recall, I've had prototypes much as you describe that others have given very positive feedback on, but . Indeed, I'm not sure that I recall any prototypes developed as you're describing that have kept my interest.

    For example, I recall a game that I built a few years ago. If I recall correctly:

    The original concept involved using spells for puzzle solving (albeit somewhat differently to To Light a Candle; magic is somewhat ubiquitous in my work), but I only managed to find a use -- or only ever got around to implementing, I'm not sure -- a spell that applied force on impact. I turned the prototype then into something slightly different: a sort of cross between pool and Sokoban, in which the player used these bolts of force to knock statues around a fenced-off area onto pads; there were also teleporters to add a little extra interest to the movements of the statues. Once all pads had a statue, a door would open and the player would progress to the next level.

    I showed it to a few people -- including, as I recall, a professional game designer -- and the feedback was rather positive, encouraging me to continue with development (including suggesting that I allow community-sourced levels).

    But I had lost interest in the game, and developed it no more.

    On the other hand, I've had concepts that I believe fit your description of "top-down" that have held my interest for years, either revisited whole or re-worked over time.

    Simply put, developing like that, and the games that I find that it tends to produce (at the least in those early stages) tend to be ones that interest me only briefly.
    ... but then I realised that even a modern adventure game needs to have some sort of mechanical difference to it. How else will it succeed when the genre is having problems otherwise, if it doesn't have some neat mechanic that drives the entire game at a molecular level?
    This is another debate; suffice it to say that while I would love to see development of new mechanics in adventure games, love to see it branch out, I don't think that new mechanics are at all required. Indeed, it seems to me that adventure games are making somewhat of a comeback, albeit that I doubt that they'll likely reach the popularity of such things as action games.
  • edited
    @Thaumaturge: What, exactly are you arguing for here? To be left alone to work on stuff your way? Nobody's stopping you. For equal assessment of game design techniques among a group of game designers? Good luck there! ;) Maybe for advice that more suits your method of development? Fair enough.

    It honestly sounds like you want to be left alone to keep going the way you are. That's cool. But I can't help wondering how many games that's produced for you so far. Because that's what I think keeps @BlackShipsFilltheSky and myself posting in this thread: The impact of this advice on newcomers.

    Do we want newcomers to spend years on games that they don't release, or do we want them to learn their failings as fast as possible and move on to newer things all the time, constantly getting better? So far every time @BlackShipsFilltheSky or I have spoken about this, we're talking from the perspective of helping people learn shit faster.

    I guess I don't see how what you're arguing for does that and I really hope that's just my lack of understanding instead of you arguing to defend a cherished habit of your own that's not being evaluated along the same lines of efficiency and impact for newbies.
    What works for one person may not work for another, and what fails one person may work wonderfully for another.
    How does anyone new know what works best for them? They can't know anything about things they don't have experience of! Getting experience and trying different approaches is the core of what I've been arguing here. Should people try to gain experience quickly or never move on to learning things because they've never been pushed to build metrics for their own learning?
    Simply put, developing like that, and the games that I find that it tends to produce (at the least in those early stages) tend to be ones that interest me only briefly.
    Your conclusion from your anecdote makes no sense to me... So you made a game that you ended up giving up on. That happens a lot. In fact, it NEEDS to happen a lot. How many of the games that you've felt super-engaged to work on have turned out to be awesome things you could release? Are you only working on them because you're tricking yourself into feeling engaged? (Because there are many, many ways that people trick themselves into that, why else would people get stuck doing ultimately useless engine make-work so often?) As a metric, how useful is your own engagement at telling what will be a great game? How do you know you're not misleading yourself and acting on assumptions that haven't been tested here?
  • I was looking into that concept Herman mentioned about stating one's goals and motivation.

    It looks like it is a fairly substantial effect:



    Which produces an interesting problem to solve when working in teams.

    I think during Free Live's recent 7DFPS jam I felt some seriously low motivation. I'd taken a very Top-Down approach to the jam and things weren't working out. I wonder how much just stating the goals at the start hurt me.

    Obviously bottom-up development is much better at not stating goals, but it does get tricky when working in a team, and I think I've fallen into some bad habits (well, I think I've done a few things top-down even when I didn't have to).



  • I think that the top-down is something people do when they're one person. You have this idea, and you brood on it forever, until you think it's the best thing ever, all simulated out in your head. Then you gotta birth that idea out.

    This happens mostly when you're doing other stuff - whether finishing your previous project, or your 9-5. It's what we tend to do if we're "game designing". We build the entire thing in our head. It's quite hard not to, in fact.

    The problem with that it's untested and already deemed awesome, and we as humans are incapable of true simulation in our heads. The only real simulation is... Well, real. That means playtesting, and since we're not making games for ourselves (like art), we need to get other people to try it. The sooner the better.


    The bottom-up approach requires a mindset of... zen? You do things without expectations, which is REALLY REALLY hard to get to, especially after you've been working in "get this done" mode for so long (the 90% on the 10% principle). I find myself brooding on ideas right now and simulating them in my head instead of jamming them out cos I'm busy with Bear Chuck, whereas I used to actually just bang something out.

    Not easy, but KNOWING IS HALF THE BATTLE!
  • edited
    Here's some other really useful thoughts one of the problems with top-down development:

    http://www.hobbygamedev.com/adv/the-brain-is-not-an-emulator/

    The article has a lot of meat in it. But I really like the closing thoughts:
    Chris Deleon said:
    ...what makes great videogame designers isn’t writing better design docs, or even having better ideas, so much as it’s having a better process for building, trying, rejecting, and salvaging ideas, then seeing through the polished completion of those thoughts that survived and fit well together. It’s an elaborate dance to compensate for the inability of our brains to know or manipulate gameplay accurately as thought or words alone.
  • edited
    Although I think the limits of imagination is an important factor, I also think it is a question of designing at the right layer, and letting the other layers follow. If you start at the top and work down, the top will be good, but the minute-to-minute (being constrained by whatever is at the top) may or may not be good; you have less control over it, and so, on average, it's mediocre (or even bad). If you start at the bottom, the detail will be good, but the overarching experience (being constrained by the blocks from which it is built), may or may not be good, and so, on average, it's mediocre (or even bad).

    So the question for games is, where does the fun lie: do we appreciate games for their grand schemes, or for the minute-to-minute activities?

    (This works well to work out the effects of the approaches with other other design activities as well: we appreciate code for the neatness of the overall design, not the cleverness of each line. Things like stories can be appreciated for either, I think: beautifully constructed plots; or the turn of every phrase or the composition of every frame. Food is more about the bite than the set of courses [well, IMHO]).

    (Just to be clear, I think this is just another component. I am not suggesting foregoing experimentation for rapid feedback, for example, or making lots of small games to learn the craft).
  • edited
    @hermantulleken Are you talking about the difference between a bottom-up approach and a top-down approach?

    Because if so I think you've misunderstood the approaches.

    In that the distinction isn't about focusing on different "layers", but rather about not relying on assumptions and emulation in your head (in bottom-up development) and relying on assumptions and emulation in your head (in top-down development).

    So while there may be some advantage in looking at the "overarching experience" early in development (particularly if you have a concept that can benefit from that), that advantage is only going to be as good as your brain's emulation of the experience. Meaning the "overarching experience" might still be more mediocre in top-down development than in bottom-up even if you focus on that "layer".

    I have this already listed in the comparison:

    Top-Down development:
    Pros:
    Makes it easier to conceptualize meta-games or long gameplay loops.

    Bottom-Up development
    Cons:
    Makes conceptualizing meta-games or long gameplay loops harder.

    So I'm not sure if you're disagreeing?

    But are you maybe just talking about valuing different "layers" in development? And maybe sketching and testing the higher layers first?
  • edited
    @BlackShipsFilltheSky I think I understand it the way you mean, and I am not disagreeing with you at all.

    The way I see it, top-down has a few problems when used for games, one of which is the inability to emulate in your head what is necessary to be emulated (that you are talking about), which I agree with. Another one is that it will optimise the the wrong thing even if you could emulate it perfectly, because the things that make a game work are in the detail (the hands-on-toyness) more than in the big picture. (And sorry for repeating stuff you [and @dislekcia] already said essentially too; I have been thinking of this all day, and been trying to work out in my own mind why software engineering is different from game design in this one aspect :)
  • edited
    So I just came back from the Battlefield guy (Daniel Matros, just for the record I didn't forget his name :P)'s talk, and I must say, what he said pretty much confirms what we've been chatting about. Indie and AAA are practically polar opposite ends.

    The first thing they have before they build a game? A vision. A unifying vision of where the game is going and what it's striving for. In Battlefield's case it was stuff like to be the best FPS, millions in production value, and some other stuff I can't remember. It's very top down. It's non-explorative.

    Nothing about mechanics, nothing about emotions, nothing about... "fun". The starting point seems to be a really a big numbers game. How can we make this game SEEM to be worth the R600 cover charge so that we can sell 100 million copies at that price. The game becomes a tool...

    And man now I sound completely cynical :P

    He did say though, make mistakes. Make a lot of mistakes, and learn from them. And they make those mistakes through crazy amounts of testing. So that makes tons of sense. They build their games bottom up part by part, and put it all together in a giant puzzle kind of way.
  • edited
    @Tuism You do sound a bit cynical.


    @hermantulleken Okay! Yeah, I think we're on the same page (I had just phrased it not too clearly).

Sign In or Register to comment.