chipsy

I've written many 48 hour games. I've also written games that drag on for months or longer without apparent progress.

The difference literally comes down to whether you are doing easy things or not. Having an engine or framework does help make a variety of things easy, but it does nothing for the one or two features that aren't. Eventually you hit a wall where it takes forever, and that's your next month. You get over the wall and then a flood of other new features come in almost instantly. Also in the same ballpark are features that you have coded before and are familiar with, vs. ones you aren't. You can get a lot done "from scratch" by spamming preexisting knowledge at the problem, but it still takes time and it isn't exactly easy either.

Last of all, at first clone-and-modify is enough to feel interesting. So you go very quickly, because you care little about the result. But after a few dozen times doing that, you're done, and you want to expand the parts you care about. That creates more barriers to get over, more months where progress is slow because your ambition is big enough to no longer follow the easy path. More months where problems are on the content development side, not the runtime. That part is always difficult. Scope is deceptive.

I think the potential for a game to provoke some new legislation is very real. The quantity of people changing their use of time, space and infrastructure so suddenly is unprecedented, and even if it fades over time, the chances of more like this one are high.

It seems to be part of our habit in mathematics to first make many discoveries using brute-force and large enumerations, and then later extend the results with more sophisticated methods if we can find them. For one practical example, if you were doing a lot of computation in the 1960's you might carry around a book of trig functions, or a slide rule, but after microprocessors came about a pocket calculator could do all those functions with better precision. With proofs, many questions are proven up to some number n, which is only further extended by feeding the algorithm into a powerful computer. But occasionally we discover a way of reframing the problem so that it can be solved with relatively little computation.

I believe programming has some analogous quality to it: It's much easier to solve just one problem and gradually find ways to generalize it.

For the manufacturer, it really does make a difference to their bottom line. The "software tie ratio" of console games in the 360/PS3 era was modest - somewhere between 3 and 8 according to this graph [0]. Getting unit cost down matters a lot when you aren't selling a lot of additional content, and the hardware got optimized around whatever game developers could soak up the most.

As such it was conventional for game consoles to have fast-but-small RAM. The reasoning is that console games mostly bottleneck on the rendering of a scene at acceptable framerates, vs. simulating all aspects of a complex scene or achieving maximum detail as a movie would. Since ROM cartridges were fast and optical allowed data to be streamed in "fast enough", there were plenty of ways to achieve the right effect under tight RAM conditions. One exceptional case where tight RAM did not play out well is the N64's 4kB texture cache, which imposed a large burden on the entire art pipeline(if you wanted a high res texture, you had to resort to tricks like tiling it across additional geometry).

Today what is demanded from a console is much more in lock step with every other consumer device - they do more computer-like things, they can multi-task some and scenes are doing more memory-intensive things so they're more well-rounded, and get more RAM.

[0] http://vignette2.wikia.nocookie.net/vgsales/images/c/ce/Esti...

The answer is: it depends. They will silently bend the "TRC" a little if there is a business case for releasing something now and not later.

But most of the requirements center around nitpicks of software polish: Specific words and phrases used to discuss the device, loading screens must not just be a black screen, the game should not crash if the user mashes the optical eject button, etc. These things add a level of consistency but aren't the same as "solid 60hz" or "no input lag". The latter sort of issues can be shipped most of the time, they just impact the experience everywhere.

Installing a bouncer means following technical documentation and having a server free. The first requirement kills the interest of people who want a single app install. The second kills the interest of people who want the service free and run by a third party.

These are not enormous barriers but they were enough to put me off of setting up Quassel on a VPS for a few years. Now that I've done it I don't want to go back, of course, and I don't see it as a huge chore to do it again. But that's what's making it "not actionable" - the perception that this is going to end in a nightmare of configuration files and Stack Overflow searches.

Historically, most governance switches between "business as usual" and "urgent crisis" without much gradient. This gives the appearance of stability most of the time as most of the political effort in the business as usual scenario is behind the scenes, trading horses, serving the high bidders, driving a wedge on an issue to create a new support base, or shutting down challengers. But when a crisis hits, everyone's plans go out the window and chaos ensues. When it finally settles, there is a new order and a new set of policy issues, not always for the better.

What we have at this moment, across many nations, is a set of crises that none of the existing governments have the resolve or imagination to solve. That's why the parties are tearing themselves up - they are realigning everything.

At ground level this manifests as partisan politics in part because the remnants of the old platforms are in do-or-die mode; with no stable middle to appeal to, they have to pick a place to move to, and it is going to be left or right of their old position.

IME, having competed undergraduate studies in economics, it has a huge indoctrination blind spot in that as typically taught, the theories are presented as hard rules and students generally aren't exposed to more than one economic theory in depth. Study time is spent in a performance of mathematical theatre, extrapolating broad notions of how society behaves from simplified models. Some of it has useful explanatory power - especially micro economic theories that have plenty of experimental backing - but just as often there is a design constraint of "our options as policy makers are x, y, and z because those are what are in our model." And this is not probed so actively at the undergraduate level - to do the homework and pass the tests you have to answer "yes, of course z is the best policy, because our textbook model says so." Which, I suppose, is like high school history and its tendency to use a singular narrative of cause and consequence, but with some symbols thrown in. It is deceptively universalizing.

Have some DSP resources:

Richard G. Lyons, Understanding Digital Signal Processing [0]

Gareth Loy, Musimathics: The Mathematical Foundations of Music (volume 2) [1]

r8brain-free-src (high quality sample rate conversion algorithms) [2]

KVR's DSP forum, frequented by actual pro audio developers [3]

[0] https://www.amazon.com/Understanding-Digital-Signal-Processi...

[1] https://www.amazon.com/gp/product/026251656X/ref=pd_cp_0_1?i...

[2] https://github.com/avaneev/r8brain-free-src

[3] https://www.kvraudio.com/forum/viewforum.php?f=33

To put it another way, the British Empire had a "merchantalist" foundation - maintain a positive balance of trade and surplus material assets by forcing its colonies to engage in trade on preferential terms - while the U.S. has been "free trade" oriented in its imperial years, with balance of trade being less important than retaining GDP.

Both have imperial dynamics, but for the U.S. the important part is being the "world's policeman" as it comes with the authority to destabilize regions and install puppets where their sovereign governments may act against U.S. interests. With this more limited administrative footprint, they're free to focus on use of violence and propaganda, while taking up domestic market policies that benefit net importer businesses and thus justify maintaining the empire.

Where people say that the Pax Americana is ending it is in part because the dynamic has grown more multipolar since the end of the Cold War, with a diverse group of nations asserting their interests without being overthrown.

This correlates with my personal experience. Lifting is a good idea, but my optimum for it is perhaps once a week, else I fall into overtraining. The rest of the time when I want to exercise mild cardio seems more beneficial.

The 90's game was Quiz and Dragons by Capcom and it was arcade only.

Basically, you have three components of the future organization that get "architected" early on - how it sells things(marketing, sales, support), how it makes them(engineering, manufacturing, services, etc.), and how people in the organization are treated(hiring and management). These things need a design to them, or at least a rough strategy, and they have to cooperate in some way. Once you have a design in place, then you have your work cut out for you.

It is possible to make viable businesses by leaning on any one of those three elements. You can find the anecdotes: "I sat in my basement making weird computer art and it turned out internet people fell over themselves to get their hands on it", or "I pitched something that I made up while in the waiting room and they funded me to make it", or "We were a bunch of talented school friends and decided to go into business together without knowing what the business was". Those are all at the extreme ends. A balanced approach is also possible - you make a little bit, then you try to pitch it to some people, then you try to convince people(perhaps even the same people you pitched to) it's worth working on. Step by step you go from "we don't know what we're doing or know what's going on or who should work on what" to "we've solved all the major questions of this market and have a team that delivers good value."

The way in which you execute on these plans should ideally stay in line with how you feel comfortable doing business - your philosophy, your ethics, your motivations, etc. There are plenty of ways to cut corners and do wrong, or to try to lead when you aren't actually a good fit, and this may stop you from pursuing an otherwise worthy concept. Entrepreneurship isn't a job title or even necessarily about business so much as it is an extension of the act of poking at things and people and seeing if it gets some gears turning.

So, in any case, the validation is good, but the most important thing a company needs to continue operating is to close deals - hence there's always an undercurrent of "build up your pitch, build up your leads, product later" to a lot of biz advice. You know you can execute on the technology again - you already did it once - so that's not a big issue, as long as your technical ambitions stay in line with the original work. But progressing on the sales front is a big deal, and with the client work you're at a generous "0.5". A clear next step is to distill everything you learned from working on it into a better, more saleable pitch, and build up contacts and leads. You may want to get someone already in the industry to do some of this work, but at no point can you expect to be completely hands off.

It's both player count and "weakest link" syndrome. Games more like TF2, where weak or out-of-position players don't necessarily break a team, don't grow as toxic over the long haul, even if you're playing them competitively. But all the MOBA-style games have feedback loops that require everyone to play at a minimum standard or the game is definitely lost, and that just isn't conducive to a good experience in online/pub games.

You might not succeed at 100%, but you can remove "classes of error" by adopting particular styles or techniques backed by formal analysis. That's one of the biggest appeals of compiler technology - it can encode an understanding of patterns proven to detect failure, and in so doing lower your resulting bug count.

A soft renderer wouldn't fit in 4096 bytes, too. The overwhelming preference of the demoscene when doing PC filesize compos is to lean on OS provisions in order to free up space for more algorithms. Hence you have demos that use files in C:\Windows as source data. Likewise, you have demos for older computers that require aftermarket RAM upgrades and employ preprocessing techniques that require modern computing resources. In unrestricted compos modern game engines get employed these days, too, and while many of those entries suffer the downside of having a low entry bar, good work has been made too.

Pointing at the GPU as a particular cheat or a make-easy button is not relevant to the conversation, in this light. Having a Gravis Ultrasound was also a cheat back in the day ;) It's all fairly arbitrary stuff, and in the end, the point is to present something cool running on the hardware and within the nominal restrictions, even if you get tricky to do so.

Modding basically recoups the investment into making a game's community - an individual can present their result to an existing player community directly, with a brief forum post, and a small website with some images or video to advertise. That is enough to build a small empire on, going by the most popular examples.

That's different from the typical lifecycle of a commercial game, which has a deeper level of marketing work to do before it can even consolidate a playerbase. There isn't a "Unity modding community", per se. There is a community of Unity developers, and players of individual games made in Unity, who have no broader associations. A game transitioning from the mod sphere of an existing game to an independently produced commercial title still has to overcome this gap, and most of them don't make it over the line.

The advice is sensible, nevertheless. If you can extend the schedule to focus on the core elements of the design as a "R&D" process where the majority must be thrown away, and only scale it up towards a shipping product as the concept proves itself, you minimize the risk of the budget being wasted on a flawed concept. Modding scenes, game jams, and micro-budget productions all have the benefit of weeding out most of the really early, risky design experiments, without wasting enough of people's time or money to care.

Even when conceiving the marketing for a larger production, the same advice works. The "trial balloon" or "landing page" method, etc. You still do design thinking when you market, but it's design on the topics of "how do we build a funnel" or "how do we make this a franchise." Still very easy to spend a lot of money on making a splash without getting the blueprint right.

Human-size applies to many activities, too. You only get so much time in the day, so "someday" can be put off no matter how long you wait. You never become so exceptional that all problems are within your comfort zone as if you were an overpowered game character. Long term, you can only sustain about 4 hours of max effort on a difficult, out-of-flow mental task like a hard coding problem. You can never entirely brush aside your ordinary failings just because of your accomplishments elsewhere.

Likewise kick scooters. Fast and quiet enough to make pedestrians think "you are like a bike and I should treat you like one," but in fact far too slow for roads and unexpectedly agile on sidewalks.

Basically, all the vehicles that sit in the intermediate gradients of speed/acceleration are in a position for their simple existence to offend everyone else.

The "19" figure is mythical - just google "average age of soldiers in Vietnam" and you'll see that the real figures are known to be younger than other recent wars, just not so extreme - around 22-23 years old depending on the exact statistic you're working from.

That said, the Paul Hardcastle song "19" is still pretty good. [0]

[0] https://www.youtube.com/watch?v=b3LdMAqUMnM

Use your calendar to structure the whole day, including some fun things, some chores, things you want to practice, and required events. If you have the whole spectrum of activity bundled together it becomes easier to let go and follow the plan than to get distracted and lose your pace.

I would say Pong approaches easiest for a game with real time graphics, though.

The difficulty of Pong depends to a large extent on how real you try to make the physics. For a classic-style implementation you flip some state bits to test a different axis depending on movement direction; all angles of travel and reflections are defined as a small LUT. The most complex test needed is the paddle boundaries.

Relying on LUTs and state machines to avoid complex behavior is the cheat that defines a lot of the early arcade games, however tutorials tend not to teach them in this way and just immediately dive into trig functions and AABB tests.

Not particularly more or less than other fields requiring similar creative adaptivity. If you ask a programmer to do commoditized tasks and punch the clock, then yes. If you ask them to engage themselves at their highest level of intensity and give them the environment and schedule to do so, then you get something very different per person, something potentially worthy and unique but hard to grade on the curve. And as we all know, organizations tend to need more of the former.

Many folks looking for a Perlin-like effect end up using the diamond-square(or "midpoint displacement") algorithm, which has a similar look but a somewhat simpler implementation:

For each segment take the midpoint of the linear interpolation and add noise at a smaller magnitude. Recurse in until you are at the desired scale. In 2D, flip the sample points between a "square" pattern and a "diamond" pattern each time to avoid a boxy tiled look.

The biggest downside of this method is that it's much less flexible about scaling: to get more resolution you have to double each dimension.

In a real-time application that has to run on constrained hardware, the most interesting use of a GC language is as part of a compilation/configuration process for the actual runtime code or assets.

This is the approach of e.g. Naughty Dog's old GOAL language: it isn't doing Lispy things in the engine code, so much as using Lisp as a very powerful macroassembler. This approach is potentially advantageous over having a batch process to compile and upload to the device since it presents some important groundwork for doing "live editing". The performance of the shipped application is effectively unlimited, since the user code has so much control over the resulting output.

The main downside is that the resulting app isn't designed for portability, being so oriented towards the machine code rather than an abstract layer: Getting the portability and the live-editing functionality and the performance is a considerably harder problem to visualize, but production C++ game engines are doing it now.

Don't describe it as "fast". Use "latency" or "throughput". RC is a useful building block for making real-time latency guarantees, and for many apps that is more important than peak throughput.

W/R to "What If's", I think the big one is "What If Atari Were Stronger/More Focused". They tried to grow into a "manufacturing conglomerate" rather than a "consumer design" company. It misused their original branding and culture. For this the Warner acquisition deserves a large share of the blame, even as it seemed necessary for financing the VCS launch. Either way, by the time the company was at its most profitable, it was already rotten from mismanagement.

Had they found a path towards a more contemporary-Apple-like management style, and some foresight for the third-party situation and the console lifecycle, they would have broken away from the scattershot focus, released a good, DRM-protected, backwards-compatible update to the VCS in the early 80's instead of the half-baked 5200/7800 efforts, insulated themselves from the arcade crash with original console software, and starved Nintendo's air supply at retail.

They might have even still released computers, just of a different sort - perhaps they would have kept Jay Miner's team and had an Atari-branded Amiga, with a console version released soon after(c. 1985-86) instead of 8 years later(CD32 - 1993).

There are an exceptionally large number of design parameters in "fun". And it's not enough to be fun to be commercially viable - there has to be a hype factor(premium) or a monetization strategy(f2p) built into the product too.

All of this is best combat with a lot of feedback, and a lot of kinds of feedback. It's challenging to parse all of the information and stick to a certain focus, since the incentive to play your game over others is not clear or obvious.

I am liking the look of this language. It looks very modern, and neither a retread nor outlandishly experimental or hacky.

What it would need to start feeling viable:

More documentation about implementation details, e.g. runtime environment, memory allocation model. "Ground-up" engineering info.

Some key libraries for a target application domain - web, gaming, etc. The "best option for X" approach.

Ability to deploy Stanza into other environments: Source to source, an easily implemented bytecode format, etc. The "parasitic" approach.

In agreement.

I started using a rule of "use the language's primitives first" to guide my use of DRY. There are many ways in which you can "reduce repetition" by introducing a generalization abstraction, something that in turn couples lots of code to a master definition: Generics, high arity functions, and inheritance are three such temptations. Doing that, in turn, accidentally models the whole problem before the spec is mature.

But if your discipline is "I'll use more built-in types and simple data structures, I'll keep more of the code inline, I'll let this class get bigger and I'll make some duplicated simple, fixed-function code paths," you don't get trapped by that. Sometimes I end up with the same simple math function duplicated across two different modules because I needed it for completely unrelated algorithms: That isn't pretty, but it's not a gross failure.

The opportunities to make a really useful abstraction for a novel problem often take time to ripen, and until that point you might as well assume that the code necessarily involves a "spaghetti" mindset. You don't want to pay the cost of reworking the abstractions unless you have to - it presents a huge hazard to maintenance and it means the attempt to generify failed.

But I think coders do get caught in a "clean code" mindset now where it needs to look both pretty and succinct, 100% of the time, and that leads to pushing the functionality out of the function body and into "ravioli" code.

I think Go is a good language, of the hot ones today, for learning this kind of engineering-centric focus because it actively discourages trying to whittle down the code to the succinct one-liner. Unfortunately by the time I encountered it I already had this figured out(perhaps years later than I should have).