Patrick Wyatt, a Blizzard and ArenaNet veteran, writes about making Warcraft, StarCraft, and Guild Wars, including bugs and netcode.
Commenters call it a gold mine of first-hand game development accounts and recommend the StarCraft and 'Whose bug is this anyway' posts.
So few Mac games make it down the transom that I do take note when they show up on Steam's list. Ultratron was one of them, though I didn't buy it because it didn't seem like something I'd be into. Whether or not the game deserves to be a blockbuster, it indeed stinks when hard-working developers don't have much of a net or runway to finally craft the next big indie hit.
That said, there still seems to be opportunities to break out for developers of all sizes. Recent success stories that come to mind:
* Faster than Light, a space sim just made for Star Trek fans...it reached $200K on Kickstarter -- 2000% of what they had initially asked for -- and it still seems to be selling well. I just bought it last week and it has ruined my free time (http://www.ftlgame.com/)
* Block Fortress - a ingenious mishmash of MineCraft, first person shooters, and tower defense. These developers (apparently, four brothers) also made the great Heroes and Castles, a first person tower defense game. And both of these games are dirt cheap with totally reasonable/optional IAP: http://foursakenmedia.com/
* Ridiculous Fishing - a casual iOS game made by some all-stars of iOS development, including Vlambeer and the guy (Zach Gage) who did the awesome SpellTower, one of the iOS games I've played the longest: http://www.ridiculousfishing.com/
* 10000000 - A match-3 dungeon game for the iOS that the creator made in his spare time as a labor of love...it caught fire when a TouchArcade editor discovered…
My point was you didn't establish a causation anywhere. We have lots of software written in OOP, yes, but you didn't (and can't, really) prove that it wouldn't have been written without OOP. There are and have been APIs that work just fine without OOP, so it doesn't seem like not having OOP was barrier to entry. FFmpeg is doing fine without OOP, by the way, and so is Linux.
Here is how I can read the last few decades - software started becoming more and more popular, and in the beginning of the 90s people jumped on the OO hype/bandwagon (and haven't let go ever since). Now, OOP done wrong was worse than procedural done wrong, but since the hype and koolaid were so strong, and the fast-growing market really needed the software, programmers have just plowed through, DESPITE OOP. Classic Starcraft story, jump to "Game engine architecture" - http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft . My point being, you can release software even when you get held back by OOP.
Another thing that you failed to do is comprehend my message. Of course we have a lot of OO frameworks, since OOP is the most popular programming paradigm. If functional were the most popular then you would have a lot of FP frameworks. You're using argumentum ad populum, basically.
> And when I open some C-based project's code the first thing I usually expect and see is some homegrown linked list and/or map implementations (of SIGSEGV fame). I know, there are tons of libraries that offer them, but in my experience of "hey, that server crashed, could you figure out what went wrong"-type tasks, they're very rarely used.
Fortunately, C++ developers just always use the STL because it is considered the bastion of all that is good in collection classes:
http://www.codeofhonor.com/blog/avoiding-game-crashes-related-to-linked-lists
http://engineering.adap.tv/2012/03/29/why-we-use-c-without-using-stl-or-boost/
Don't get me wrong. I love C++ and use the STL by default, but it's all too rare that I look at a decent sized C++ project and see anything different from what you'd expect if the project were written in C.
I added browser automation capabilities to sandvault [0], a MacOS sandbox, to allow AI agents to control Chrome browser from within the sandbox, which makes coding & testing websites from within the sandbox much easier.
I'm using sandvault+Claude to rebuild my personal blog, Code of Honor [1], because I got tired of WordPress. The site includes search functionality, and articles are automatically syndicated to Mastadon, BlueSky, and Twitter.
I wrote a Claude skill to automate testing of iOS apps [2], and it found issues in one of my released apps [3].
[0]: https://github.com/webcoyote/sandvault
[1]: https://www.codeofhonor.com
[2]: https://github.com/webcoyote/AppTestCircuit
[3]: https://www.codeofhonor.com/blog/finding-bugs-with-an-automated-ai-test-agent/
What you are looking at is corporate environments; the studios of the past (Ex: Westwood and Blizzard) had a small headcounts, and people were direct decision makers.
The story of Starcraft 1 is quite interesting as the devs copied the Warcraft 2 code and began changing it quickly[1](https://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft).
> StarCraft was originally envisioned as a game with modest goals that could fit into a one-year development cycle so that it could be released for Christmas, 1996 > Warcraft II had only six core programmers and two support programmers; that was too few for the larger scope of StarCraft,
No boardrooms of PMs, and Directors, and VPs, and execs, chiming in every decision, leading to fast turnarounds.
Some great anecdotes here about the development of pathfinding in starcraft 1:
https://www.codeofhonor.com/blog/the-starcraft-path-finding-hack
> But the biggest thing holding back StarCraft was unit path-finding.
> It wasn’t that the path-finding was totally broken; in most cases it worked quite well. But there were enough edge-cases that the game was un-shippable.
> Game units would get stuck and stop on the battlefield. Often they would go through elaborate efforts to find paths, inching forward or looping around but not making progress, and sometimes getting wedged and unable to move further. Entire task forces would get bogged down in what looked like the afternoon commute.
previous HN discussion: https://news.ycombinator.com/item?id=5252003