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 believe programming has some analogous quality to it: It's much easier to solve just one problem and gradually find ways to generalize it.

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...

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.

Comments URL: https://news.ycombinator.com/item?id=12077675

Points: 2

# Comments: 0

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.

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.

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

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.

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.

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.

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.

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.