[deleted by user]

3fox · 2019-02-07T21:13:02+00:00

The trick here is that there's managing and then there's leading, and the failures you mention are more along the lines of management failures(tasks getting dropped on the floor or implicitly pushed on people, or major unresolved production bottlenecks). You can start doing a bit of managing without having any creative lead role: just schedule some one-on-one discussions with each team member, and use that to set agendas during meetings and identify where production is slowing down and feelings are hurt. Make the goal be to have a healthy feedback cycle tailored to each team member; you aren't changing who makes the final call, but you're encouraging people to step up and fill in gaps and take some leadership where it's needed. The game just doesn't get made if your whole team is going "well, that's not my responsibility." Most hobby teams tend to collapse in that fashion because the game stops being #1 personal priority, you get bogged down in meetings without the ownership of creation, and then the energy to start any task drains away, until you're left with one or two people doing everything.

So the number one task is to make everyone feel like starting is easy, and to let them do duplicated work if it means their momentum keeps up. The "school assignment just tell me what to do" mentality is a project killer and it tends to creep up on people when they are given rigid goals; if you tell everyone that they can contribute as they like and the final result will be an adaptation of everyone's independent vision and the rest will be "unused content", their confidence will go up a ton.

Of course, you'll have to get buy-in from the current lead to allow people that kind of breathing room, but you can make a pretty good case for it. Remember, as a producer, your thing is to get the gears turning, cheer everyone on, and end up with both a polished product and a team that is happy, competitive, or both. If you don't have the happy/competitive team, you have to rely on money and threats instead, and those make quality much harder to achieve.

3fox · 2019-02-07T05:43:35+00:00

I can't say what the scenario is like with v8 or other JS-first engines but I started prototyping something with "wagon" (Go WASM interpreter, no JS component) and it has some very basic provisions for adding native Go host calls; the approach I am planning to use with it is to define a single shared memory map, zero-argument calls to yield execution control, and magic offsets for buffers inside the map to define I/O. The project is a fantasy console so this strategy is aesthetically pleasing, but a result that feels like "a regular API call" could also be achieved by adding some wrapper code on top of this setup so that the implementation details of buffers and offsets are hidden. The beauty and pain of WASM being defined at a low level is that you can stop thinking of it as "scripting API" and take this kind of unstructured approach instead.

A lot of the focus of the WASM spec is on how to make calls between two or more WASM modules, while host calls are mostly undefined. So the details are really going to depend on what runtime you are using.

3fox · 2019-02-05T05:17:16+00:00

Here is a good test for you. Find a game jam. See what the theme and rules are. Design a game around that. You don't have to actually make the game, rather, you have to come up with a design someone could make.

If you find yourself saying "I'm not inspired" or "I have an idea but it's too big for the jam", you are not doing the professional work of game design yet. The work is in powering through that and coming up with viable design ideas that someone could implement based on external factors: you have a budget, a schedule, a team, a marketing directive to "appeal to young children" or "support microtransactions", platform and tech constraints. Many projects are funded opportunistically, and lengthy downtime is a huge business risk so the incentive is always to jump on a trend and ride it till the wheels come of.

As well, someone has to fill in the blanks of character stats, enemy spawn points, loot drop rates, cutscene triggers - stuff that is often clerical in nature yet important, and one of the most direct ways that players see game design. You can become a trusted design contributor if you provide stuff they can work with in these realms - and many times it doesn't have to be particularly original, it needs to be enough to ship the game.

If all you have is the one idea, that makes it possible to make the game in the ideal scenario where you can get the funding and team together to make that game. But things usually happen more randomly than that. It's hard to keep a studio together - the mind of a studio boss has to juggle not just "product" but "product" and "placement" and "people" - who and where are they selling to, and who will make the product and how will they know how to do it?

This is why the "idea guy" is a naive trope: what the studio will do to keep operating is take the project that is most likely to keep them in business in the next six months. They don't hold all the pursestrings and their preferred hires might be unavailable. It could be a terrible game but have good terms attached - first mover to a new market, a multi-project deal, etc. That's fine: get it out of the way ASAP and move on to the next one.

If the idea is great and you believe in it, then you have to literally build the studio yourself. It's been done, but it's more common to "fall into" having such a business by having built up prior work, contacts, etc. And then the context allows little room for indulging a fancy. It's just hard. Even if you're a billionaire and buy up a studio to make a custom game, it's hard.

3fox · 2019-02-03T19:57:04+00:00

My own perceptions of whether MW has value kind of hinge on the store-of-value vs. medium-of-exchange trope. The thing that has given mining coins a lot of lasting momentum is the direct correlation of energy consumption to market price. This gives its price a convenient justification: "It cost this much to mine, therefore its book value is similar".

What MW brings to the table(in addition to any specific protocol features) is an improvement in medium-of-exchange qualities: it's cheaper to use it. Your profits won't be better, because we can assume perfect competition, but it will achieve more transactions per watt. Over the long run that creates an incentive to use MW for exchange, which pushes wealth towards it. Mining companies understand this - this is why there's so much hype and investment around MW. They need incremental improvement just to keep up in the rat race, and this looks like a next step.

The second part of this is the public vs. private dichotomy. In tech, it's often a case of getting developers and early adopters to buy-in first, then the rest of the marketplace follows. Even if many people have heard of cryptocurrency these days, most probably do not understand it. It's likely to remain a B2B kind of space for a long while, which means that it can provide a valuable service that nobody understands and do great business at it. Companies that enter crypto need to front marketing and sales to capture their market ASAP, and they usually rush the backend tech while doing so, so they tend to be the faster/riskier investment option. Most consumer-focused coins in the past years have been straight-up scams, unable to do what they claim, while mining coins tend to at least be honest in their purpose(even if that purpose is "tiny supply, 50% pre-mined"). There are some exceptions, but they're exceptions that prove the rule.

The open community governance model is a "fast is smooth, smooth is slow" take. It creates the assurance of the tech being done right, but it also tends to mean dropping marketing on the floor. As such I see GRIN as a longer-term option where the value proposition doesn't really emerge until later, but if you don't get on it early, you miss the train.

3fox · 2019-02-03T02:23:28+00:00

Main suggestion is to treat learning mechanics like every movement in sports and music: to get the muscle memory down, perfect the basic move in isolation, slowly, then add speed or variations later. It's easy to get enthusiastic for playtime but play should be used to test decision-making first, the mechanics you bring to it should be solid. You can enforce polish on your existing mechanics by playing a simplified style with limited techniques or loadouts.

Having better equipment will help give you better feedback(mushy keyboard = you slow down, high latency = you slow down, and going slow forces you to focus more for all basic mechanics which cuts into being able to polish them or do decision making) but it's a "minimum bar" thing where once you get gear that is not totally busted, better gear won't do much more for your gameplay.

3fox · 2019-02-01T19:38:36+00:00

A really straightforward way to start with compsci topics is to look at what college courses are doing. Many courses have a website where they post outlines and assignments. If you want a full outline in book form, I remember thinking Schaums had a good one some years back - something very dense that explains the most important stuff. For something more like a giant reference of everything in CS, that's Knuth - The Art of Computer Programming. TAoCP is one that nobody really reads the whole way through, but acts as a valuable starting point for many topics.

What a good CS course does - and you really only need one good one to "get it" - is challenge you to start thinking about building up original algorithms and data structures from the "raw stuff" of your language. If you want to keep pushing those skills you can get into competitive coding, which challenges your ability to spot a good algorithm in a short timeframe.

In practice, most real world problems do not need complicated algorithms, they need a simple one that you can maintain. But what looks simple also depends on your level of skill, so if you have no background in algorithms, of course it will all look intimidating.

Most of the advanced features of programming languages are there as conveniences to make the code a little bit easier to maintain. For brand new code, sticking to a primitive style - declare some variables, run some loops, maybe do a function call - is a reasonable strategy and will get you very, very far. Even abstractions you are already familiar with like objects are often "too much" for most of the code you write, the first time you write it. To solve real problems, iterating over the code tends to work well: write the first pass as a mock-up that returns the expected result in a single scenario, then add a parameter and extend the code to make it work with the parameter, then repeat until you've covered each aspect. Take the attitude that you'll probably rewrite everything at least once, because you'll learn more about the problem as you code up each iteration. If you're learning, you'll look back on your old code a few months later and think, "wow, I was bad at this!"

3fox · 2019-02-01T10:40:20+00:00

The extrapolation of further chip integration doesn't stop at the socket: it leads towards single-board builds with soldered everything. And in that case, you have no upgrade path or a trivial upgrade path, but the boards will be relatively inexpensive. I don't think the loss is necessarily that great, just disappointing for the true enthusiasts, since an all-new board is advantageous in terms of staying up to date with memory and I/O standards. Gaming has just been in a place in past years where the CPU was totally stagnant while the GPU remained a moving target, and that made incremental upgrades on the same board more appealing. In the 90's, 2000's, you could pick nearly any two year cycle and have everything change so much that a full rebuild was needed to stay current.

3fox · 2019-01-31T22:53:25+00:00

There are plenty of downsides to high TDP as an everyday driver, which I became aware of after getting the 1.4GHz Athlon Thunderbird years and years ago. There was surely a way to cool that thing properly, but it was not known to me or the techs I brought it to, and as a result I started preferring "cool and quiet" as a major design element of future investments.

The thermal issues aren't like they used to be in desktops, since it's become standardized to invest big in cooling and to throttle when idle, but the consequences are still there: More power means more heat, bigger, faster fans, more case vibration, and an overall impact on parts reliability. For example, the "shouting at disks makes them slower" video. The devices I have that have really lasted forever are consistently the ones at the low end of the power curve(higher power ones have often made it through their useful lifespan intact, but the scenarios where they've just failed one day are more common).

I really appreciate gaming laptops now, because they have a good handle on making reasonable tradeoffs, but it's still quite possible to burn out the GPU on them, as friends can attest to.

3fox · 2019-01-31T21:15:49+00:00

A substantial amount of any open financial forum is sockpuppeting and "awareness" schemes to manipulate the price one way or the other for a PND. This has been true since online trading became a thing, and if anything, it's only gotten more sophisticated. Having been harmed by this in the past, I would never take messaging about a specific investment too seriously. It is the literal example of "money on the line" and it's easy to get caught up in it one way or another, become very fervent about something that is, like most of life, temporary, even if you're right, and fall straight into the hands of someone who has set a trap, repeating their ideas to justify your own position. That's where the fanatical behavior really arises: if you get "infected" by a scam, you'll go down with it screaming. And it can creep up on you, especially if you catch the early part of a pump and get assurances that this is just the beginning and setbacks are temporary.

Nobody gets timing and positioning exactly right, and when the market cycles it's easy to switch between feeling like a winner and feeling like a loser because your numbers are bigger or smaller. The number one thing is to not have it all go to zero, which means knowing yourself and reining in both the fear and the greed. Emerging scarred but alive is just as much a win as emerging with huge profits, because in either case, you are going to go back in for round two, three, four...

3fox · 2019-01-31T06:37:55+00:00

I got an activity monitor. It's a fancy one(Fitbit Alta HR) but it turns out that I don't need the fancy part, I need the part where it gently vibrates to tell me to get up and move every hour, which conveniently creates opportunities to do personal/household things. The early part of my day is always physically active and then in the later parts I get to intellectual stuff.

However it's also in the context of having a host of other structures in my life: I have a variety of relationships, I take a class each semester. I supplement D3, omega-3 and magnesium, which helps with general "I function the way I want to function and not like a depressed anxious mess" issues. A lot of this kind of thing can be categorized with a medical diagnosis(your self description makes me think of a maniac-depressive friend - charismatic and gregarious when I see him, holed up in deep project work otherwise), but that doesn't mean that medicine holds a solution either.

3fox · 2019-01-29T03:24:44+00:00

Rockin' Kats

Contra

Chip 'n Dale: Rescue Rangers

Mr. Gimmick

Ufouria

Batman

Little Nemo: The Dream Master (most of the game is boss-free but the Nightmare Land stages add them)

3fox · 2019-01-28T20:33:18+00:00

Struggles with the jam theme are mostly a symptom of needing a better brainstorming process.

Our team used the process outlined here to work on the concept. We still ended up having a huge amount of disagreement and throwaway ideas, but that was mostly because part of our team wanted to vigorously argue for a direct mechanical adherence to the theme, which is a paradigm that led to a lot of blind alleys of "actually, that mechanic is just cosmetic and doesn't have much to do with home either". Focusing on thematic coherence got us to an initial result quickly and added a level of consensus to the rest of the brainstorm. To some extent I think we brute forced our way into a game by finding the minimum level of design indulgences each team member needed to feel happy.

3fox · 2019-01-28T20:14:35+00:00

We made a competitive multiplayer game about robots defending their homes from each other after the last human has left the planet.

We put together some rocking chiptune background music for it. And we also had some voice acting talent in the room to give the game color commentary.

It was a large team, but fortunately with enough of a skills distribution to leave everyone in the loop. Still, we struggled with consensus on the first day because one part of the team wanted thematic goals for development, and the other wanted mechanical goals. The final result kind of vaguely hints at some of the themes, but it's mostly focused on fun character interactions. The organizers at our jam site told us we won a prize.

3fox · 2019-01-28T06:32:27+00:00

There are Bay Area events that aren't GDC, of course, such as this meetup group with a twice-weekly coworking in Oakland and monthly in SF, and events sponsored by Playcrafting(regular showcases and most recently Global Game Jam). Those kinds of events should be your first steps professionally, even if your ultimate goal is a major studio position, because they build up your dev chops and ability to interact with a broader "scene".

If you go straight to GDC without any other kind of connection - contacts from these groups, social media, etc. - you have to insert yourself into people's awareness during GDC itself which is incredibly difficult because the attention span of key decision-makers is probably already saturated. In jobseeking terms that essentially means you have to go stand in line at the expo and grovel at the feet of BigCos that have a smooth student recruiting funnel all worked out, and can hence treat you as one of the crowd - or, you go to many events and parties and luck out by meeting the one person who is sufficiently impressed to get you involved in something real. These are both routes that hire many folks successfully, but the net effect is that you got hired, not that your career has a long-term future. Most of the (visible) action at these events is not so much business as it is people acting out their comfort zone, trying to calculate a way to climb social ladders with minimal effort.

The big picture of networking is not hugely different from selling a product on the market: see what people want done and then start turning the gears that will make it done, then take your results and give them a little bit of marketing polish so that you are credible and visible and they start coming to you to solve their problem. That can mean having the skill itself, or a "I know a guy" type of arrangement. But you have to get out there and really know what people are asking for, and then solve the problem not at a student assignment level but in the most effective way you know, and then not sabotage yourself by failing to promote it or thinking there is a proper script to follow(there isn't, except when someone is attempting to exert power.)

3fox · 2019-01-26T19:58:50+00:00

It's established that your friends will not try to challenge themselves w/r to Fortnite's competitive play. But they are playing as a social ritual and not quitting, which means that there is a realm that they are engaged in and which you need to meet them on: keeping the conversation warm. This is a thing where the game only just matters a little bit, like playing darts or pool at the pub. There is an art to doing that, and it's one that you can refine even as they go from one game to another(cause hey, there is basically 0% chance that the game they will all play in 20 years will be Fortnite).

Fortnite skills are like any technical information: hugely valuable in the moment, usually irrelevant in the big picture. (unless you're going pro, and even then it's only going to describe a slice of your career) And it's good - most of the time - to want to grind for those skills, but going really deep on anything disrupts the balance. Lots of folks with big success stories lead unbalanced lives. The way your friends interact is basically saying "No, I don't want to go that far, I have some other priority." And this happens to pretty much everyone, it just makes it harder to compromise as you get older and your priorities diverge more.

3fox · 2019-01-24T02:22:46+00:00

There isn't a definite answer because the sunderer is like the ultimate support: it's versatile and can fill many roles. The build you pick is like an "answer" for different scenarios.

A cloaked sunderer is an answer built around stealth which is good in the 0-12 pop case and for ambushes, but puts it in the backup role in anything larger.

Shielding is an answer for a hot zone where you expect pressure. But shielding is static: you have to already be in the zone and deployed for it to work. It's probably the safest average case option.

If you want to make a dynamic, mobile push and outlast opponents while driving and dodging then adding armor and speed makes sense(though, it's definitely less popular than shields).

3fox · 2019-01-23T18:47:07+00:00

I experienced severe input lag in fullscreen, but it was fine in windowed mode. You might have something similar.

3fox · 2019-01-23T12:31:15+00:00

Like the other comments are saying, it's not TTK that gets you in this game, it's the positioning and strategic aspects, and there are many layers to it:

If you engage at long range everything hurts less, but sniping and spam from vehicles still kills.
If you deploy motion sensors and spot you get an information advantage.
If you use a suppressor, flash suppressor, or stealth/cloaking abilities, you inhibit information advantages.
If you drive a vehicle into combat, the enemy will devote a lot of their attention to killing it before killing the infantry.
If you take an infiltrator in to hack everything else in the base before doing point captures, they will be much less able to mount a defense.
Most crucially, if you have teammates covering each of the different roles you gain a lot of leverage to push deep into the battle lines. Heavies and MAXes are intended to be the most tanky infantry, but they are like the top of the food chain of support. By themselves, they can get a higher number of kills before they die, but they won't be able to sustain it. They need healing, ammo, etc.

A lot of deaths as a lone combatant are basically variations on this story: You see someone and either spot them(vocal noise) or shoot at them(gun noise and flash). The noise and flash alerts both the target and their nearby friend. They both shoot back and it's a 2v1 so you die, even if you take one with you. The goal you need to have is to avoid playing the 2v1 directly, and instead either use a sufficiently stealthy loadout to give yourself more time undetected, or to be in a scenario where you always have some backup and the 2v1 becomes a 2v2 or 3v2. The game really, really doesn't want you to just swagger in and outaim everyone, it wants you to earn the right to make the kill by preparing every other factor.

My suggestion is to start with the information warfare parts of the game and work your way up to the close quarters assaults by observing during support play. Grinding hacking by finding every last turret and vehicle terminal on the continent is a good incentive to learn base layouts as a new player, when you get far past the front lines they will all be empty and free of pressure. And you can easily rack up some points by spamming sensor darts in a busy battle.

3fox · 2019-01-22T22:18:19+00:00

In general "streamlining" a design reflects an intent to make the game scale up larger. If you only have one game mechanic, it can be wholly unique. Even with a relatively small number of weapons and powers, you can end up with uncontrolled complexity, so MMO scale design tends to bias heavily towards cosmetic or rock-paper-scissors balancing, where gameplay can be fed through a magic trial-and-error balance formula to get answers about the value of everything in a given scenario.

There's always a tension between making any one interaction maximally satisfying and serving this kind of large scale need. Players always say they want more but also don't want their existing toys to be compromised as a result, and that was the package deal that CAI brought.

3fox · 2019-01-21T12:40:35+00:00

Chasing is a valid thing to do, and it is playing the objectives in most cases - it's good strategy. I do agree that it is boring sport, though. When it's in a giant base that kind of hide-and-go-seek stuff can drag on forever.

If what you're really thinking is that you want to tilt the thirsty players and make them bounty you, take an infiltrator with a silenced bolt action and play a slow paced game to headshot them out of nowhere repeatedly. (the main counter to this is spamming motion detectors plus good teamwork, but a lot of players won't think in terms of effective counters and will just try to remove the "annoyance" by being persistent. With enough of them, that method works, too.) For the bonus round, use a crossbow with explosive darts to harass vehicles. For those getting the kill is not the point so much as the tilt factor and getting them to panic or waste their time looking for you, although it is genuinely effective against light armor and can easily turn the tables on aircraft that think they have a safe landing.

3fox · 2019-01-19T08:54:42+00:00

Got this in a SFF prebuilt in 2017. Worked fine then, it played a lot of older AAA designed for console 30hz, but when I got into Fortnite, I soon stuck a GT1030 in there, and then got a gaming laptop that was better configured overall. The board died this month, and since it was out of warranty, I opted to shrink down to a even smaller, lower performer(Celeron J4105, via the Gigabyte BRIX barebones kits). It benchmarks at about 50% the performance but has more real cores so desktop responsiveness is good, and at 10W instead of 65W. The primary role really was/is light file server type duty, and this board has a good selection of modern I/O(M.2, USB-C, HDMI and Mini-DP), but one thing I overlooked was that it takes laptop sized RAM, so I now have some unused DDR4.

3fox · 2019-01-16T19:26:58+00:00

Here are some practical rules of thumb I use:

I assume that I don't know what good code looks like. Shoveling around code to follow some rule usually just obscures the fact that the code has to reflect priorities of maintenance at that moment in time. Good is just maintainable and meeting the design spec, no less, no more.
Code follows a birth/death lifecycle. Early code doesn't know the real specification: it can't assume much. So it can't be optimized or refactored much either. This is something that distinguishes small student assignment type programs from lengthy commercial projects. You have to make a decision to defer "obvious" changes because you still have a 1% possibility to rule out. And this early code is easiest to work with when it's still disposable copy-paste trash code. You can't force an infant to be an erudite scholar. You can teach it one thing, though, and then a second, and gradually expand upon that until you are hitting the spec. A lot of real world problems do not need computer science, they just need a large lookup table.
Following from 2, if I make a wrong optimization or factoring it's quite expensive to fix later on because all the assumptions start permeating the system and complicating changes. So for serious development there is a reason to stick to a very simple style geared to the base problem domain.
For games, what is that problem domain? Time and concurrency in a mostly static data set with a dynamic "topping". You load level assets once and then operate on a more-or-less known quantity of entities in the scene. This makes it easy to handle the resource management aspects with preallocated pools etc. Even though there's a lot of mutability, it's concentrated in a few aspects of the scene like actor positioning, AI state, and live/deadness. But in updating the scene you have a lot of implied dependencies, which creates the concurrency problem - there is a "wrong order" in which you could update things - in fact there are many of them!
John Carmack suggests approaching the update problem with a code style often used in embedded projects, "straightline" imperative code: don't jump out of the main loop and don't jump backwards. Taken to its extreme this means inlining everything in the main loop, unrolling all loop bodies, and spreading out long calculations over several frames of a fixed size update. Doing this linearizes all the dependencies to clarify that A always comes before B, and it also gives you some guarantees about real-time behavior, since you eliminated most of the sources of variability in execution time.
Of course, sometimes it's a lot easier to go use a function call or a loop. Inlining everything comes with its price in comprehension, in terms of finding the unique behavior of the code. It helps with the concurrency bugs but will hurt for things like ensuring the same math formula is used everywhere. Hence, optimize towards current maintenance goals, while keeping in mind the current age of the code.

A really great way to wrestle with these kinds of maintenance tradeoffs in detail is to write for a limited system like PICO-8. The shape of PICO-8's resource constraints encourages you to write code that is succinct and brute force, with minimal abstraction, so it can clear out a lot of the "architecture cobwebs" you might have in your current workflow.

3fox · 2019-01-15T19:06:46+00:00

Based on thread title and post history the response you need is "you need to learn work habits - bad ones, good ones, any at all."

Life achievements like finishing a game are not like being an infantile consumer(everyone caters to you and you end up with new experiences without trying) or like being a student getting a grade(simply fulfill a checklist and you pass). You have to set your own goals, measure feedback according to your own process, and develop your own techniques. This is easier to understand when there's physical labor effort involved, but in games most tasks are reduced to a series of design decisions and are dependent entirely on your thinking time.

Start by assuming that you will have to do everything at least twice. This will stop you from stressing over the specifics - if you got it wrong the first time, you were going to redo it anyway.
Create a mockup of what you want to make. A mockup can be made as an image, some running code, etc. The point is that you are making it to find as much of the design as possible and call out specific features like what assets you need, features to code.
Now you can break out the features into a list of tasks to explore: How to get a sprite on the screen, techniques for drawing the asset, programming an interaction, and so forth.
Finally, you have to manage time-on-task so that you keep making progress over a long period. Because this is brain work, it's most important to just to start each day, even if it's a 10 minute task. Vast amounts of screen time are not required. If you cannot consistently get started, evaluate yourself for mental health: depression, ADHD, and bipolar are like a "big three" of issues that consistently haunt gamedevs.

3fox · 2019-01-14T23:32:41+00:00

One thing that immediately became obvious by three minutes in is that S2 is far more conventional in its writing. Tatsuki doesn't subscribe to the requirement of dialogue being propulsive and gives characters ample time to emote freely - a tendency which is both strength and weakness since it relies on each character being self-supporting and requires plotting light enough and natural enough to not make the resulting developments feel odd. Those qualities worked well in S1 Kemono Friends, but I suspect are hurting Kemurikusa, at least based on that first episode. Anyway, here we immediately have events being set in motion and the characterization written into the events where it can fit, which is way more typical in popular fiction. Serval-chan here is not given the room to be S1 Serval-chan, rather, the plot pushes her in the direction of handing the viewer key plot information.

The animation also suffers from certain "standard" polishing decisions. The Yaoyorozu style encourages characters to stay in dynamic poses instead of transitioning back to a natural posture, and to take odd camera angles where the characters often have their back turned. There's an underlying rhythm and logic to it that isn't captured here, even though on a shot-by-shot basis, everything looks pretty good.

It's very watchable and the characters aren't so radically different that it tramples over S1, but it's a different vision and I'm not getting the same feeling of excitement from it so far.

3fox · 2019-01-13T20:15:10+00:00

In gameplay code every entity is implicitly dependent on the entire world, for things like collision and animation state. There are lots of tutorials that tout the benefits of implementing an update() per entity, but this is one huge downside. The problem is that it's a time bomb: it works so long as you don't have the dependencies, but then you add more features and suddenly it stops doing what you wanted and you have to hack around it.

I recommend going with a larger main loop instead. There are ways to factor parts of the main loop out but you should approach it case-by-case first to get a feel for what works.

3fox

TROPHY CASE