Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

From my limited experience with the Unity engine, I would guess that it has been built with a colossal technical debt that is almost intractable.

The foundations were technically weak and they started the reengineering process (DOTS) a bit late.

I've seen that before, with PalmOS and other tech stacks that were hacked together and kind of worked for a while until the competition caught up.

The zombie state can last a few years, but I am pretty sure there are cases where the whole thing can be saved with herculean effort.

View on HN

I see Unity lasting a long time. There are basically only two companies to consider if you want to make a 3D game: Unity and Unreal. Unity is so much easier to pick up for newer game developers, which means Unity will always have a funnel of new users that will help the company stay afloat. The decision to use C# is a major factor in Unity's success. Not only do you get the benefit of an existing ecosystem, and you also don't need to worry about the insanity that is C++. The biggest threat to Unity is probably Godot achieving a Blender-like success story where Godot achieves parity with Unity but is free.

New game developers don't make any money. The gaming industry, both free and paid titles, is overwhelmingly hit-driven, and bigger professional teams can more consistently deliver high quality content.

The median title on Steam earns only $3,000 in sales over the first year: https://www.gamedeveloper.com/blogs/analyst-your-first-week-...

Considering cost of development and time, the average title most likely loses money. People were basically LARPing as game developers, and throwing money at Unity for the privilege. As economic conditions deteriorate, its reasonable to expect people to stop doing that.

I agree Steam games are a difficult market to break into, but there are other ways to make money. Unity is also a nice platform if you want to produce interactive content for corporate or educational consulting projects.

Also consider the large number of places such as Hobby Lobby, Williams-Sonoma, or Home Depot that cater to hobbyist/amateurs rather than industry professionals.

As far as I know, there is exactly zero reason to give Unity money if you're a hobbyist.

Unity's asset store is a pretty cheap and convenient way to get assets if you're on a budget.

What is the median lifetime sales? Or over a 5 year window? I don't think first year is the end-all, be-all here given how being a gamedev actually works (e.g. what if I release 5 games in 5 years?) But it's possible first year sales are effectively lifetime sales on average as well.

There is a long, slowly accumulating tail but to get there you need to survive five years and five releases. And least some of those need to be more successful than the median to generate real revenue in the tail. It also comes with increased expense in terms of maintaining those games, both the codebase itself and the marketing around it. For all that you’ll probably pull in a mediocre salary for a single developer.

If your company (or personal LLC) is only making $3000/year in revenue, you can use Unity for free (the threshold where you need Unity Pro is $100K/year). So even if fewer people are doing those kinds of “nights and weekends passion project” games, it’s not likely that it’s affecting Unity’s overall revenue that much.

Right, but some of these passion projects in turn become breakout hits that breach the 100k barrier then presumably generate revenue for Unity - think of indie games that break out into mainstream built on Unity like Among Us or Valheim. If the reduction in passion project games is significant enough it might well have an impact - especially as fewer "AAA" style development houses pick Unity.

Steam is kind of irrelevant. If you look through Unity job postings, almost all of them are in the mobile market (where Unity dominates) with the rest being gambling or web3 vaporware

>> LARPing as game developers

That's harsh in my opinion. In entertainment and media there are always more people who want to do a thing than can be supported: musicians, actors, comedians, artists, etc.

Sometimes amateurs become pros. Sometimes people "LARPing" -- as you call it --make games I really enjoy. So I think its cool that people try their luck at game development even knowing most won't make a living at it.

Ya. Am I LARPing as a developer for creating OSS things that scratch and itch and not working at Oracle or some such.

Most of the people actually "LARPing" don't actually ever finish and publish their games, so you can't enjoy them.

So true! Sometimes to scratch my itches I have joined first timers- I guess me “LARPing” as a garage developer. It usually becomes clear they will never even finish a prototype.

Once I joined a team that was making a space ship combat game. All they worked on was 2d buttons, sliders, etc. Building a whole GUI from scratch for months. I stuck my head up to say maybe we could try some gameplay ideas? No it was important to get the menus right.

The median title on Steam earns only $3,000 in sales over the first year

That number is probably way overstating the median revenue. It is based on a non-random sample (hey devs, send us your data for a survey) of 75 games. Looking at a larger dataset, a majority of developers make <$1,000 (average revenue: $294).

https://www.gamedeveloper.com/blogs/what-can-we-learn-from-t...

The median is meaningless anyway, with the bar to entry being so low. If enough people publish games that no-one buy the median will be $0.

Yes, that's basically what's happening as more and more games are getting published.

2013: 551

2014: 1,631

2015: 2,679

2016: 4,466

2017: 6,251

2018: 8,137

2019: 7,841

2020: 9,609

2021: 10,696

hey where's the data from? Its from Steam or the whole game industry included mobile? I would eager to read more details, thanks.

> People were basically LARPing as game developers, and throwing money at Unity for the privilege.

If you make a game, and it struggles due to very tough market conditions, you are not LARPing as a game dev. You are a game developer. There are countless gems on steam that have not gotten commercial success, but are well engineered and well designed titles.

Yeah, no one would say a skilled painter is LARPing just because their work isn’t commercially successful

But they're LARPing if they never finish or sell a painting.

Van Gogh wasn’t a real painter?!

In terms of artist-as-a-profession during his lifetime? It's harsh, but yes.

I don't think that's a realistic definition. It all has to do with intention. LARPers, by definition, are role-playing and not actually intending to do the thing. A painter who never makes a sale or never finishes, but intended to, just failed at the task.

LARPing would mean they are pretending to paint or pretending to have made works.

I am technically a gamedev, but I am not a professional gamedev.

> throwing money at Unity for the privilege

Your company has to have over 100,000USD in gross annual revenue to pay for unity, at which point you are no longer "LARPing"...

Even if there are fewer amateur game devs in the next few years, the pool of people who've been doing that in the last few years is where the big pro teams will be recruiting from, and a lot of them are familiar with Unity and will want to keep using it (and even if you don't care about their preferences, they will be more productive more quickly in teams that do).

Unreal seems to have made great strides to make their engine more approachable by outsiders. Five years ago you had a stronger argument, these days I'm not so sure.

Although blueprints are great, once you have to touch C++ it’s not so great. Tools like Rider for Unreal make it much, much better though. C++ is king of game dev and everyone hates it. Unreal is not regular C++ and handles a lot of resource management for you, but it’s still C++.

Am I the only one who prefers C++ over C#?

You're not alone.

I’ve used C++ for near 10 years and I don’t hate it (that’s a lie I hate it with a passion), but C# is just has much more flexibility, has better error messaging, easier to integrate 3rd party libraries, better package manager, better namespaces, no header hell, no memory leaks, exceptions with useful information, reflection, and so much more. C++ has raw speed.

I want to say this, but it's honestly been close to a decade since I've seriously touched C or C++. I've used Objective-C more recently than C/C++.

These days, if I'm thinking about creating an application, I'm defaulting to C#.

...And Objective C was designed to say "[self fuck]" to C.

you've used both and still feel that way? i admit, i'm surprised!

why the love for c++?

No, c# is java done well and I can't stand java.

C++ is a pretty decent language with a few weird features.

I may be biased by programming in Qt + c++, the best UI development flow ever created

Java was designed to say "Fuck You" to C++, and C# was designed to say "Fuck You" to Java, so C# says "Double Fuck You" to C++.

And yet C++ still rules. So I guess C++ says "Fuck You" right back.

nope

> if you want to make a 3D game: Unity and Unreal

Speaking of which, whatever happened with iDTech?

Bethesda/Microsoft bought them and took it off the licensing market, but it also seems questionable to me if it had a future there anyway, because they seemed to have gone all-in on large but totally static environments with Rage, something which has not changed with Doom. That's not something that really works for many games.

Looking at the family chart you can see that the last version that was widely licensed was idTech 3 - from 1999: https://upload.wikimedia.org/wikipedia/commons/8/85/Quake_-_...

The big risk to products where better UX is a differentiator is that it's easy for competitors to catch up and you need to keep moving. I tend to agree that Unity will be around for a while, but I'm not sure it will keep its same prominence. It's losing its first mover advantage.

God I would love for Unity to offer a Swift (no GC, fully type safe, compiled, fast) API with a rethought API surface. And have only one renderer to choose from instead of 3 with all different features.

I’m not sure how much of a performance hit ARC traffic would be. Though I think at least some of Unity’s DOTS systems really on structs instead of reference counted objects so it shouldn’t be a problem there.

Swift structs should work for that too. But also DOTS is like years away from being ready it seems like. Basically hacked into the engine and language and kinda over complicated and confusing at the moment.

Not ARC per se but the message dispatch mechanism was the biggest hurdle to high performance Objective C. The solution was easy : drop to C. Not really the best options for ease of approach :)

C# on Unity is very different then what you expect. Different base class library, stack instead of heap objects, heap arranged to allow fast iterating over them. It is C# but it is not your typical .NET. And .NET done right is in the performance region where other aspects kick in (like network or UI bottlenecks).

My only .NET experience is Unity and it’s not great.

Honestly, ARC in a game engine sounds miserable. Circular references are a common occurrence in game development.

I mean the #1 issue with Unity performance is GC pauses which are very easy to create. Swift of course has tools for dealing with circular references. I’d certainly take the trade.

There's a ton of mandatory reference counting in almost every contemporary graphics driver. I also hate reference counting overhead, but it really isn't as big of a deal as you're making it out to be unless you use it for stuff like references in render passes.

There's nothing wrong with reference counting. Manual reference counting using a technique like pointers into a generational array is fine. When the reference count goes to 0, release the generational memory. Any dangling pointers can handle the null value returned when trying to read the generational memory. That's a totally fine solution to reference counting.

My issue is with automatic reference counting. It's just way too easy to hold on to a reference accidentally, especially now that lambdas / closures are an essential language feature. I don't have much Swift experience, but I do have a lot of Objective-C experience, and it's just way too easy to accidentally capture self or some other value. In game programming, there is very little concept of ownership. Everything exists as peers that can modify each other. This leads to a high likelihood of reference cycles.

I have not found in my own game programming experience that there's a whole lot of pointer soup, except in temporary scopes that can use stuff like arenas (indeed, this would be pretty terrible for performance) and there's usually a pretty clear ownership structure to be found (ownership may be muddled in a logical sense, but this isn't that relevant from a memory management perspective). Perhaps this is because I'm using a language that doesn't mandate reference counting though, so it's easy to do stuff like just build up temporary references into arrays etc. when necessary...

And have only one renderer to choose from instead of 3 with all different features.

So you want a fourth renderer? :)

> There are basically only two companies to consider

today.

Unreal has Blueprints that are superior to all Unity's visual scripting solutions, so if you're a beginning indie dev, you don't need to write code at all.

If, however, you're a professional game developer who tries to get his game to run 60 FPS on a 6-year old phone (not a hypothetical example, I've led a project that had 60 FPS on iPhone 4 in 2016 with Unity), then you WANT the C++ and engine source code.

I've been working with Unity since 2009 and hope to never touch that giant flaming pile of shit again in my life. Having moved to frontend development still, I'm very happy to work with tools that mostly work, and if they don't, you can actually dig in and debug them, with healthy development culture that actually encourages you to do so.

Sorry for the emotional rant; 10 years of Unity experience (not really though, I've done other things in this time as well) do that to a person.

Not my experience at all. I prefer Unity over Unreal.

Hopefully Godot can make some progress there once 4.0 is out. They're making some very large changes that are supposed to drastically improve 3D performance.

I think that's where Godot is headed. The Godot editor is so much more enjoyable to use, the docs are good, the script editor is nice, and the node system makes it really simple and fun to iterate and build stuff. Very lightweight and beginner friendly. I would be surprised it Godot + Blender don't become the future pipeline for indie devs. But they do have a ways to go. 4.0 is showing a lot of progress.

I know most won't take that seriously, but GodotEngine is a pretty nice alternative. Godot is kind of the Unity of Unreal. Meaning it is the runnerup but is picking up the pace quite quickly. And from also working with Unity my personal experience is that the stuff in Godot is a lot more logical than how it's done in Unity. This is of course a personal preference but it feels like Godot has a lot more "eat your own dogfood" going on

I've seen this from both the developer and consumer side of things. The legacy design of Unity encouraged truly terrible code designs which translate into sub-optimal performance on modern hardware.

Performance and tooling have historically driven game engine licensing. There's a reason why Unity has a noticeable lack of presence in so-called triple-a gaming. Believe me, if performance was "pretty good" and tooling was "excellent" then every major studio would be using Unity. Instead, they're overwhelming using Unreal or they're using their franchise engine that they've built over 1 or 2 decades similar to id Software whose engines used to be the direct Unreal competitor.

As a consumer, I cringe when I run game that is "powered by Unity". They nearly always feature extremely slow loading and sub-optimal framerate on top tier hardware. In contrast, an id or Unreal engine game will run at 4k 60fps while looking beautiful.

On another note, Unity's market has always seemed to be indie and double-a studios. I would expect a recession to cause many who would have "taken a year off to make a game" to change their minds as investments or savings drawdown.

A lot of studios are starting to pick up Unity. It’s not that Unity can’t make AAA games, it’s that most of the workforce is used to C++ and Unreal style engines. Most A and AA games are being made with Unity nowadays. Unity started getting popular in mobile dev where it’s still king and now those devs are slowly moving on to bigger better games.

Fun story: once I decompiled some mobile game written in Python I think and they shown Unity logo on loading screen

They may not qualify as AAA, but Hearthstone, League of Legends: Wild Rift, Kerbal Space Program, Cuphead, Gwent, Genshin Impact, ReCore, Ori 1 and 2, Hollow Knight, Fall Guys, Pillars of Eternity, Call of Duty Mobile, Subnautica, Firewatch, and Valheim are pretty big games; some indie hits but many are produced by major studios.

For one thing, I think the "powered by Unity" branding is a problem, because you only see it on games that couldn't afford to actually pay for Unity and therefore have a larger chance of being poorly polished.

Half of these games run like absolute trash though.

Anecdote: Dyson Sphere Program runs at a buttery smooth 60 fps, and it is written in Unity.

...at least, until you start building the actual Dyson Sphere. ;)

The "powered by Unity" is only required by less expensive Unity subscriptions so it's boarder line anti-branding. People think Unity sucks because only low budget games advertise that they're made with Unity.

It is not limited to games that use free versions of the engine. I can't think of a unity game aside from the couple of mostly 2d games like Ori and Cuphead that weren't crappy.

Crappy is a matter of taste, but there's Unity games with fans: https://www.reddit.com/r/gamedev/comments/shx6ku/engines_use...

I meant that they ran like crap. Didn't want ti say that they were bad games, some of my favorite games are made in unity(ksp), but I really wish they weren't.

I'm curious which engines you'd rather they used. Unreal, godot, something else?

Yeah, mostly UE4/5. Godot may be a good 2d engine, but nothing more than that for at least until 5.0.

> On another note, Unity's market has always seemed to be indie and double-a studios.

That's part of Unity's market, but it's bread and butter are mobile free-to-play games.

Counterpoint: Windows works with 30 year old code, and somehow managed to manage their piles of tech debt and still work. Still a huge % of the market.

Because microsoft dominated a market segment with mostly no competition for long enough to make people dependent in a way that users couldn't simply choose an alternative. There are idiosyncrasies in windows usage that users think are normal, but are actually legacy behavior which can't be changed because it could break other peoples tools. This makes windows users not only locked on the platform but also expect those misbehavior if they try to change. Also consider that depending on the hardware, software or services you use, there is NO alternative to windows.

I don't think the same is true for Unity.

Also, yes, the user experience is not that bad, especially these days.

I love using Linux and Unix in general, but the legacy idiosyncrasies there are kind of worse.

I'm kinda sad that we have really ended up with essentially two operating systems or families of such dominating. Unix/Linux/BSD and Windows... Both with their own issues and historic loads...

I feel that we could do so much better in modern age if some of the things were just let go, but trenches has been dug and nothing will likely happen.

Uhhh ... macOS is exactly what you're talking about. It's unafraid to let some things just go. They just said during the State of the Union this week that Obj-C and UIKit were legacy tools, and that the future is Swift and SwiftUI. They said it, and I promise you they will deliver on this. I predict that within a decade Apple will truly deprecate UIKit and AppKit and stop any new app from using it. Microsoft has never been able to do that.

Isn't it still a Unix derivative? Still have bash or something as cli?

Macos still uses the darwin kernel which is a bsd. Still ships 'terminal', default shell these days is zsh.

Ouch, I was not aware of that.

Deprecating Obj-C will probably also deprecate support for C/C++ support.

I never used Proprietary Apple tech stack, when I made games for iOS it was C/C++/OpenGL and these days Vulkan with MoltenVK

If they deprecate native code, they are going to lose a lot of devs.

Never going to touch Swift with a ten feet pole.

Nothing is deprecated, they just recommend Swift and SwiftUI for new apps. And while they could deprecate UIKit in ten years or more, C and C++ won't be deprecated any time soon, they just starting working on Swift and C++ bridge too.

Swift on iOS still has support for C/C++ interop via bridging headers. I imagine that would be preserved even if Obj-C was deprecated as a broader iOS runtime. Eliminating C/C++ in one fell swoop would be disastrous.

They will try, but a decade is far too brief for that to happen. Swift was introduced eight years ago and there are still plenty of apps, especially ones belong to large corporations, that contain Objective-C legacy code. Including Apple's own apps. Maybe once SwiftUI gets its Swift 5 moment when there's a release that's stable enough going forward.

I wasn't saying Objective-C would get deprecated; I said AppKit and UIKit. That's what I predict.

And I’m saying it will be as difficult to deprecate those SDKs as it will be to deprecate ObjC, if not harder.

> still work

Yeah, by only ever adding new layers of crust and never actually changing the Old Code, at least if the GUI is anything to go by.

Have you ever looked at the source code of the NT kernel? (there have been a few leaks over the years)

Windows is indeed full of old and new crust, but the foundations are actually not bad, NT is a pretty good kernel if you ask me.

The quality of Microsoft engineering is often underestimated, mostly because it is all over the place, different teams, a huge amount of technical debt, but in my opinion some key pillars have been built well enough and maintained, and they also managed to deal with the crust and survive without falling into the classic trap of the second system syndrome.

Related HN link on Dave Cutler and his work on creating NT. https://news.ycombinator.com/item?id=18977868

Just ordered a copy of the book "Showstopper"

It’s a great book!

Windows NT learned from DOS, Win 3.1, and Windows 95 though. They had 4 generations or so before they made an operating system that was stable and maintainable.

Windows NT is the brainchild of Dave Cutler. Cutler was one of the tech leads on VMS. He was only hired away from Digital when they shitcanned his “Project Rainbow” follow up to VMS.

Windows NT was in development before 95 and Windows 3.1 became successful while NT was actively under development.

It did not so much learn from Windows 3.1, TBH, but did learn from OS/2. And from VMS and RSX-11, which Dave Cutler worked on in the past.

The windowing system in the initial NT release did look like Windows 3.1 though.

If you’re talking about the Windows OS itself, the OS kernel is very good and has pretty solid foundation. Windows NT was based on VMS which was an excellent cutting-edge OS of the time.

It's a bit of a stretch to say it was "based on VMS."

Yes the core initial engineers and leadership that started it were ex-DEC engineers.

But if you listen to Dave Cutler's interviews and read about it you can see clearly that some concepts were borrowed but much of the thinking was from scratch. He took the chance of starting a greenfield project to make something far more current.

In particular NT was designed from the ground up to be multiprocessor and multithreading friendly, which is not the case for VMS.

Secondly NT was designed to host multiple OS "personalities", VMS not at all.

Finally NT was designed to be portable between ISAs and they spent years making sure it worked equally well on MIPS, PowerPC, Alpha, x86, and then amd64.

NT the kernel is awesome. I just wish they'd shipped a better userspace from day one.

Imagine if Microsoft had shipped NT with a proper Unix-like shell environment in the 90s and not the crap "command.com" and WinCRT.dll garbage. What a better world we'd live in.

That would be true if Microsoft would have stayed with DOS as foundation.

But they knew the shaky foundation and built NT which is a very good and that decision is probably the main reason Windows is still around.

They were also smart enough to parallel development with Windows 95/98 -- creating two mostly compatible operating systems for different segments until the need for backwards compatibility and the power of the hardware made it possible to obsolete the DOS line.

> Windows works with 30 year old code, and somehow managed [...]

I don't think Microsoft has any particularly secret sauce here, they just have a good reason to keep it going and the money to do so. Many other cases the money just isn't there.

And don't under estimate the herculean efforts Microsoft goes through, or eat least used to go through, to keep old programs running. It goes far beyond what I would have ever imagined had I not talked to some of the people involved with it. We're talking having the OS detect specific versions of specific programs (e.g. old versions of Quicken) and hot patching specific APIs with bug-compatible behavior so they don't break with an OS upgrade. Microsoft definitely takes backward compatibility seriously.

Ultimately software becomes medicine, not human or veterinary medicine, but computer medicine. You have all this code, but you can't read it all and can't check if it's right. Then you end up with tumors in the code (Blas Mena came up with this concept) and they can be benign or malignant, and ought to be contained. Tumors can be 500 lines of C#, ballpark, in a 15000 LOC codebase.

Yes LOC, lines of code, is a bad metric--compared by Bill Gates to weight on an airplane--but at the end it is still meaningful to the complexity--mass of an airplane.

So the whole game in software companies is at some point taking Human Growth Hormone and growing fast, and inevitably getting some tumors, but hoping they are benign and contained. Or they can spread and the software dies.

Unity is the #1 game engine used today. It started from nothing and bypassed Unreal. That's a very impressive feat. Also, it is so much easier to use than Unreal. So I don't see the problems you are talking about.

Alluding to this, at what point can such a huge company say that we have technical debt and that we'll be focusing on refactoring and making the base solid instead of releasing new features?

When a company finally gets there, we will let you know.

They are kind of doing that with DOTS and ProjectTiny, while still improving/maintaining the legacy base and adding features.

https://unity.com/dots https://unity.com/solutions/instant-games

But they have been working on this for 5 years now, and it is still "experimental", also the community response has been kind of lukewarm, many devs don't really understand why this is necessary.

I read that the dots team went dark over a year ago. People are speculating that the whole thing was either canceled, or they are planning to release a completely separate game engine rather than try and shoehorn it into the GameObject model.

They have made fun about being relieved that XNA had only been a framework rather than an engine. MonoGame http://www.monogame.net might actually outlive Unity in the end. In any case, the Unity founders will be millionaires.

But Unity isn't just used for games.

Sure, there are Excel games too.

I don't get your point.

I assume the poster is implying that although Unity is used in things outside of gaming, the vast majority of users and development are/is in gaming.

Unity is for games. Without the games market, a company like Unity can't exist. Unreal Engine is used for dataviz and media production projects, but it's business is games.

His point is that if Excel lost the business world, the fact that people do things like write games in Excel will not save it, and he is asking you to understand that the assertion that Unity is used for more than games is roughly analogous, which it is.

Most of their revenue comes from other activities, another commenter mentioned this: https://news.ycombinator.com/item?id=31932162

My point was that it is comparing an engine to an engine + more. I do agree that the engine is central, but it is much broader than games.

That isn't what that commenter is saying. What he's saying is that engine licensing isn't the bulk of their revenue, other non-game-revenue-dependent services are. Those services are _game_ services that happen to not be tied, like the license of the engine itself, to the published game revenue.

That commenter does say that most of their revenue doesn't come from the engine, because that's what the numbers tell you. It's also what I just said, I just summarized it to engine + more.

Please don't claim it's similar to making games using Excel, it really isn't. But it explains why I didn't understand what he meant, so that's something at least.

You said "unity isn't just for games."

What I am trying to tell you is that the revenue breakdown you are using to justify this statement doesn't actually say that. What it says is that due to unity's pricing model, the bulk of the revenue they are making isn't all engine license revenue (which is both game and non-game), it is other services, almost all of which such as voice chat and asset store are strictly game-related.

In other words, Unity may be more than games, but they are entirely game dependent. It doesn't say that revenue is non-game.

I read the link before I posted it, you don't have to repeat it. My point still stands and Excel for games is still not a correct analogy.

Monogame is missing a lot of features if you're wanting anything but the basics in 3D (it's still very good for 2D games). I tried hard to use it instead of Unity (for over a year), and only recently switched to Unity because I wanted to add VR support, and forgot just how much easier doing 3D in Unity is compared to Monogame.

Like I was fighting Monogame on model rendering, textures, shaders, cross-platform (never could get a high-res 3D working for the Mac version), anti-aliasing, etc. Everything 3D was being a pain in the ass to get working, and my progress was very slow.

After one day of porting my assets over to Unity, doing some tweaks in the editor, and importing a few assets from the Unity store, and my game already looked better than it ever looked in Monogame (still working on porting the rest of the game).

It should be said that I'm not an expert 3D developer, I'm much stronger in 2D, but have been trying to do more in 3D lately, and that may be part of why I struggled with Monogame in 3D. People who have no issues coding in OpenGL or DirectX directly probably won't have as many issues as I did.

any information with the PalmOS story? I'd be genuinely interested in that!

Did you also build one of the top two game builiding engines of the world or just ranting?

Reply on news.ycombinator.com