I actually had to implement this myself for a project, literally few days ago.
I had almost 0 knowledge of how audio files work or how the Web Audio API works. The implementation is very barebones, not very flexible, and has no error handling. But hey, if someone will find it useful regardless, here is how I did it:
https://gist.github.com/2Pacalypse-/241c37adfff127bd5c66f3e2...
One less talked about thing when discussing StarCraft, that might be more pertinent to HN audience, is that this game was almost endlessly hackable. And I mean that in the truest sense of that word. Many a careers were launched by playing around with OllyDbg and learning to reverse engineer code all so you could create an awesome plugin [0] for the community.
Which brings me to my next point, which is that the community aspect of StarCraft is a huge part of why it remained popular for so long. As previously mentioned, there were hackers and programmers developing awesome tools that helped the scene, but also there were map makers which were essential in keeping the game balanced. One little known fact about StarCraft is that the last balance patch released by Blizzard was in 2001, at the early beginnings of the pro scene. After that, the game was kept fresh and balanced by community map makers.
Combine that with people who created websites where you could follow news about Korean pro scene (TeamLiquid has its roots here), talk with other people about StarCraft, and other people who organized tournaments and did everything else; and you get a formula which almost ensures the longetivity of the game. I wouldn't be surprised if there are people playing and following this game in 20 years time. I know I'll be one of them.
The game also had custom maps that allowed for sandboxed programming / scripting.
A lot of very clever custom maps ("use map settings" / UMS) were made.
MOBA genere spawned from a Starcraft custom map called Aeon of strife. Starcraft also had a map called "the unknown" which is basically Among Us - made years ago.
There were "turret defense" maps, RPG maps, maps where you controlled one unit and tried to dodge things (bound maps) and many other maps that just changed the balance.
In the golden times players didnt have to play the cutthroat 1:1 all the timr - you could spend days playing custom maps (archives have tens of thousands of them), custom campaigns, modes with more players like 2v2, 3v3 or 4v4, or even 8 player everyone for themself.
Apart from "difficult" maps, there was a whole community playing maps with (nearly) unlimited resources - "fastest maps" and "big game hunters" (BGH). Those maps were easier so no "ladder anxiety" by having to play the best all the time.
Starcraft 1 gave a lot of freedom to have fun. You didnt have to participate in the incredibly difficult duels. You could play a custom map, or some 3v3 with your friends - where overall skill level was lower, but fun level was high.
Killing custom maps is in my opiniin one of the reasons why Starcraft 2 failed. Blizzard wanted to capitalize on them, but didnt know how.
In Starcraft Brood War there was this game list - you could select UMS mode and pick from probably 100 open games. In Starcraft 2 you could only play what blizzard wanted you to play.
I guess Blizzard was unhappy that Warcraft 3 spawned the whole DOTA game - which was also a custom map.
Regarding hacking - many people learned java writing bots for Diablo 2.
> In Starcraft 2 you could only play what blizzard wanted you to play.
5 years ago when I played SC2 for the first time there was plenty of (iirc) “Arcade” maps which were UMS, and I’m pretty sure, community made. Are you perhaps talking about early days of SC2 when that still wasn’t a thing or? One map I was most impressed by and had lots of fun playing it, was called “Assassins”. I won’t explain what it is, but if someone took it to develop a game based on it, I strongly believe(d) that it’d be another hit game that spawned from SC
Im talking about the early days when there wasnt a "game list" where you could see the maps hosted by actual players. So the list only showed maps open at a moment.
Last time I tried SC2 arcade there was a list o hundreds of maps with zero players inside and you had to pray that some other players wanted to play the same map as you. So you would have to coordinate by a forum or friendlist to even play a game. So arcade was an empty desert.
Killing the "currently open games list" was such a antipattern... does SC2 have it now?
as far as I know it does have it, and my experience doesn’t match yours-on EU there was 20ish open lobbies (hosted by people) for different custom maps/arcades at all times. but yeah if it was like you are saying it was, I agree with your point. also, check the other reply to your comment from someone who is more up to date
Yeah. He explained it as it was in the early days. Battle.net for Starcraft 2 really destroyed the game from getting popular. It's so sad that the Battle.net from 1998 was better than the Battle.net from 2012... They implemented chat several years after SC2 released. Clans even longer after.
They released it when the online connections were terrible, then everyone left before they got good.
They deliberately hindered the release of Starcraft 2 by releasing the online experience completely unfinished. No clans, no chat (at all), no PMing, no custom games. Nothing. It was like that for several years.
At that point, with 3 years of hype for the game, people came, played a bit of 1v1 then left. It was a botched job. Blizzard died with the release of SC2.
To be fair to the team, Tor (from PirateSoftware fame) reported that Blizzard made more money selling one horse in WoW than with the entire Wing of Liberty:
Well, the horse costs only 4x less than the game. WoW has an insanely larger market cap.
It's not crazy that people bought the horse in more $ amounts than SC2's first release. It's crazy that people spent $15 on a single cosmetic.
I don't fully trust piratesoftware guy, since he does do a lot of clickbait, and isn't exactly a well known body from Blizzard. But I do reckon that micro transactions for a larger game would well outsell an old purchase model on a smaller game.
And yeah. We can only blame gamers for the way video games are now. The good games rarely get acknowledged, but the bad games proliferate continuously.
They killed custom maps by killing the search mechanism. Not sure if they fixed it now, but on release it custom games were ranked by popularity… which just creates a feedback cycle where only already-popular games would show up anywhere on the top and get sufficient players to run. With no discovery, you ended up with the first acceptable maps, usually remakes of sc/wc3 maps, dominating the list and no way for new maps to compete.
The particularly stupid thing is the map editor for SC2 is ridiculously powerful, but afaik nothing interesting came out of SC2 custom map scene.
I played this custom map called "Assassins", and it was one of the best things I ever played, I'm not exaggerating. Idk if something similar already existed, or if it came out from SC2, but I was really hoping for someone to make a real game based on it. Everything I can find on the internet is just this one yt video, but it's an older version, I didn't play under 3.0 I think - https://www.youtube.com/watch?v=TX4hpQouvKA
> Regarding hacking - many people learned java writing bots for Diablo 2.
I remember it being Javascript, not Java. I forget the name of the tools involved, but I do remember creating a lot of Javascript bindings in C or C++, so that scripting engines would have interfaces to various bits of game engine code.
What? Starcraft 2 was a commercial and critical success, selling 6 million copies. It wasn't as successful as the original (11 million), but hardly a failure. It was the leading esports game before MOBAs took over.
The modding scene as we knew it is dead, also for the FPS genre. There are several explanations: games becoming technically more complex, commercial practices, cheating being taken more seriously, gameplay being more refined, with many of the good ideas having already being turned into their own games, the indie scene going for purpose made engines rather than mods, etc...
Dota, and so LOL, is often thought of as something coming from Warcraft 3 Defense of the Ancient, but the concept really started as a starcraft mod as well.
Of lot of the gaming culture is born on the original Battle.net.
SC 1 was one of the most influential game ever created.
I remember the map “V-TEC paintball” as a forerunner of the DotA and LOL styles - endless waves with you the (battlecruiser | marine | ghost) running around making the difference. HotS, LOL, DotA all seem to trace back to those “paintball” custom maps and the creators who made terrific use of the tools on offer.
Came here to comment the same. I was making fun of my housemates for being addicted to DOTA (a MOBA game), then during a "Use Map Settings" game of Starcraft I discovered and enjoyed playing a mod called "Aeon of Strife" and shared it with my housemates.
DOTA is a direct descendant of Aeon of Strife.
I had discovered the original DOTA, inside Starcraft.
> Many a careers were launched by playing around with OllyDbg and learning to reverse engineer code all so you could create an awesome plugin [0] for the community.
My career was launched by StarCraft! I've never been to high school or college. I played waaaaay too much StarCraft in my teens, and ended up writing a bot to maintain the chat room my friends were in.
The entire network stack had been reverse engineered, criticized, and documented if you knew where to look. Eventually that documentation made it to the public.
I interviewed with Blizzard a decade ago. I heard one of the interviewers state that the community documentation [0] is better than Blizzard's own internal documentation.
I now write software to fly drones. It's fun as hell and I'm glad of ye olde Blizzard. I know some are here on HN -- thank you guys for being awesome :)
> As previously mentioned, there were hackers and programmers developing awesome tools that helped the scene, but also there were map makers which were essential in keeping the game balanced.
Starcraft came out when I was a kid, the online community of Battle.net is really what got me into programming and development.
I’ve recently started watching StarCraft games again. Lee young ho aka Flash aka the GOAT returned from the military, and it’s been fantastic to watch. Artosis is a great commenter as well.
There’s something really unique with this game, I feel no other RTS has the same depth. I plan on returning to this game when I retire, in 20 years. See you then.
SCUMS! (StarCraft Use Map Settings). These maps provided a wide array of games and I believe popularized or gave birth to a few. I remember tower defense, level up games where you and the other players explore the map and gain upgrades, a predator game where one player is chosen randomly to be the killer in a horror style hunt. Imagine, each map, possibly an entire new game, sometimes being discovered for the first time together with strangers. Such a fun and amazing time!
It's a project that few of us started almost a decade ago to ensure the longevity of this game. We don't try to emulate Battle.net at all, but instead we take only the gameplay itself and reimplement everything else ourselves.
It's a work in progress, so please let us know what you'd like to see in there that's currently missing if you do check it out.
No, but more seriously, I've found that familiarity with the codebase is more important than having it be perfectly engineered. Once you're really familiar with the codebase, you know where dragons be, and you can make changes more easily. And God (PM) forbid, if you ever find yourself with some extra free time you might even reduce the size of dragons over time.
This brings me to my final point. Any codebase that I really enjoyed working with was the one that was constantly evolving. I don't mean rewriting everything from scratch every few months, but as long as I have permission (and time) to refactor the things that have been bothering me for months as patterns emerge, I'm a happy bee.
No excuses. Code ownership is important. Sometimes it works for a team, sometimes only for individuals.
But not having to submit to core teams, architects and self-proclaimed experts of all kinds is a blessing.
I now work for an organization that discourages code ownership, and it struggles on many fronts:
1. core teams are dysfunctional
2. people find niches and stick to them
3. top talent is leaving, although pay is good and business creates real value for citizens
4. there is virtually no horizontal communication
5. mediocre ones rise to the level of their incompetence and infest the lives of others
6. and so on and so forth...
And I think the root cause of all this is lack of individual (code) ownership.
I’ve had exactly the same issues but because I couldn’t change anything without getting approval from 16.5 code owners on every PR submitted. It’s a real pain if you start modifying your coding for ‘least code owners hit’ instead of ‘best architecture’.
I like how my workplace does it -- there are rigorous codeowners and usually you only need approval from 1-2. if you do need approval from 5+, you can request a select 'super' codeowner review which will approve it for all.
I think core teams being helpful or harmful really comes down to the individuals.
The problem is at this level, most orgs don't have anyone to really judge or contest competency, so they hire the salesmen rather than the doers and when they don't, they tend to cheap out and just get inexperienced people.
Logically it makes a bunch of sense, though.
Why rebuild yet another platform? Why is your central platform bad? Usually it's not self-service, sometimes it's because it's built in cumbersome ways, other times its because it actually enforces good standards on you rather than just giving app your apps admin.
It's difficult for the person who hires the core team to differentiate between those complaints, unless they themselves both have the technical competency and the empathy to really understand the problem. They usually don't.
Point being, done well, it's great, but most folks can't do it well.
I have a part-time gig where I maintain accounting software for a former client of mine. It takes up a few months' weekends a year.
I wrote about 60-70% of it when I was working for the owner of the software. It's something where as long as the client's happy, and they get new integrations and updates on time, they could keep using it for a decade longer.
I had almost complete ownership of the architecting of the software. It's broken down into a few microservices (think database, core business logic, reporting, auth, logging etc).
The best thing I did at the time was pushing to use gRPC even though management felt it was too new tech.
The UI is in Angular, pain-free periodic upgrades. I've even rewritten some perf-sensitive code in Rust, and everyone's happy with snappier calculations.
The code hygiene is relatively good.
The only downside's that if someone else were to take over the code, they'd struggle (it's one of those things where I'm wearing many hats). I've been fortunate to be a professional accountant who moved into software engineering, so everything makes sense to me.
> And God (PM) forbid, if you ever find yourself with some extra free time you might even reduce the size of dragons over time.
Honest question, what is the company like where you can do that? Everywhere I've worked (only been working in industry for 6 years) has had such rigid agile development that even when I do find myself with free time, there's no flexibility to work on things that haven't been assigned to you and the best I can do is work on profiling/debugging tools.
Usually at smaller companies with just a handful of developers. Can be a "start-up", or just a smaller business running fine with small teams. Or sometimes in a larger company where there's a small team doing its own thing.
There's up-and-downsides to everything. The pay is usually less, and "fewer processes" often also means fewer processes surrounding HR and such. This can mean you're subject to the whims and mood swings of one person. I was once fired over a pretty far-fetched misunderstanding, but 1) they didn't mention it because "I should know myself", so I didn't really have a chance to clear it up, and 2) when I got fired they agreed it was a complete misunderstanding and that they made a huge mistake, but fired me anyway because that was the road already taken now. Great ... thanks ... It's hard to imagine that happening at a larger company with an actual HR department and stuff.
Also: a Wikipedia-esque "be bold" attitude helps. Obviously refactoring things just for the craic isn't a good idea, but if there's something that can really make an impact then I'd just do it and send a PR, regardless of what I've been assigned. Obviously "refactor everything" on your own initiative isn't a good idea, but usually there's tons of smaller stuff that really helps: "introduce new function/package that helps reduce boiler plate", "split up this difficult to understand function", things like that.
Most PMs will realize they don't have a 100% in-depth understanding of the code, and will trust you when you say it helps you do your work better. Usually it's fine as long as you apply proper judgement and don't spend too much time on it. That said, there are some places where this really isn't appreciated regardless. IMHO that's pretty dysfunctional and when I start looking for somewhere else to work.
> Once you're really familiar with the codebase, you know where dragons be, and you can make changes more easily.
This is an interesting, and often overlooked, point. A month or two ago someone asked us, the Fossil SCM maintainers, if we'd be open to them refactoring the tree to something which better matches modern sensibilities (i'm paraphrasing here). Despite its many proverbial dragons, the long-time maintainers are comfortable with it and know where those dragons are and how to defeat them (or, in some cases, sneak around them), so, despite our collective geek tendencies to prefer "perfect code," we're happier with the dragons we know than those we don't. (That's not to say that fossil's code is awful, but its structure varies significantly from what one might write today if one was to start such a project from the ground up.)
For that, there is a saying: "code as if your kids will maintain it".
But I think it does not convey the right meaning. When I code something I will have to maintain for a long time, I try to make it as simple as possible for my future, older, less motivated and weary self.
The worst codebases are written by people who landed the gig a few months before and do not expect to stay around longer than a year or two.
This is very much true. Initially when I joined the industry I used to work for a product from its inception. So I was aware of what section of the code affects what part of the product. Although I hadn't worked on all of those, I kept an eye for the all the changes that were coming in. I knew where I should look immediately a bug is reported even if it is not something related to my line of work.
Recently I switched teams and now I find myself taking up bugs that are only related to my line of work. Not being familiar with the codebase decreases productivity and wants you to rely on other people in the team for most of the time.
Your successors just hope you can only remember 3 things at once so you end up with elegant designs rather than one of those monsters who can remember "to add a new wrinkle to this feature, just edit these 25 files."
This is probably one of the pillars of good codebases, or at least decoupling the bits that you don't control as well as you can (this includes external services). I remember needing to write a wrapper around another JWT library, but because it was quite important, I aimed for >95% test coverage, some of the tests acted as documentation for how to use the code, there was also a nice README, there was CI configuration for pushing the build artifacts to Maven and suddenly even managing dependency updates became easy because of the test suite. Years later, it's been integrated in a bunch of services and "just works".
Come to think of it, things always get less pleasant once you add a bunch of complex dependencies and libraries/frameworks. Need to make a few RESTful Web APIs in Java? Something like Dropwizard will probably give you fewer headaches than Spring (or Spring Boot) and all of its inherent complexity, in the case of the former you might even need to do configuration in XML and that has honestly never been pleasant. If you need to integrate with a bunch of other stuff and want something opinionated, going for Spring Boot will make sense then, but for simple use cases it's overkill. Same for ASP.NET, Ruby on Rails, Laravel and many others, while they might be easier to use, updates (especially across major versions) and breaking changes will give you a headache and just add a bunch of churn to the project.
Similarly, if you need a message queue, externalizing that into RabbitMQ might make a lot of sense, same with storing files in an S3 compatible store, using something like Redis or Valkey for key-value storage, as well as not trying to shove too much logic into your RDBMS. Just pick whatever tool feels best for the given task at hand, instead of shaping things into what they're not (using the database for blob storage, for example), unless you have a whole bunch of constraints to contend with. Otherwise, sometimes you just get the worst of both worlds, like needing to use Oracle for a project, not having easily launchable local environments (because Oracle XE doesn't support some features), having to share DB instances with others during development and also running into weird obscure issues like DATABASE LINK queries taking 100 times longer in some cases, even when executing the same SELECT query on the remote DB works without issues.
To not go into a rant, I'd sum it up like this: be in control, isolate the things that you cannot control, pick the correct technologies, do the simplest thing that you can get away with without overengineering and think about the person who'll have to maintain, debug and grow the system in the following months and years (which might also be yourself, sans knowledge about what the code did, if you don't make it explain itself or don't comment the non-trivial stuff).
Isn't this only true if there is no physical infinity? I know it's-turtles-all-the-way-down is impossible for our brains to comprehend, but causality breaks down when infinities are involved. Another thing is that if space-and-time itself was born at some point (as they say), then talking about "before" and causality doesn't make any sense either.
But yeah, to your point, thinking that there was never "nothing", and that there always was "something" is equally mindblowing.
That is closer, but it's also not exactly correct. Now that I think about it, I don't think the English language has any sound where the letter "c" is used as it's pronounced in Croatian language. For example, the word "points" has the "ts" sound which is phonetically closest to the letter "c", but the the letter "c" is much sharper and shorter.
Edit: just as I wrote that, a word popped into my head which has almost the same "c" sound: Pizza. The "zz" sound, if you can call it that, is closer to the "c" letter phonetically than "ts". So Rimac would be pronounced something like Reemazz.
More seriously, I've been listening a lot to the mainstream pop songs on the radio during my car commute, and I don't know which carefully crafted formulas and laboratories those songs come from, but they're in sync with what my brain perceives as "good music" quite incredibly.
The way that these laboratories work—most pop songs are made through collaboration, with a mixture of people working on it that are all really good at some part of songwriting, performance, or production.
You probably have at least two writers—maybe one person who’s really good at beats and arrangement, and one person who’s really good at topline. You have a producer, who gets good recordings of all of the parts and creates a mixdown. You have session musicians, who have dedicated their lives to an instrument.
It’s great watching interviews with the people involved with this process. The best songs often have serendipitous beginnings—somebody made a beat, and somebody else says “that would go well with these lyrics I’ve been working on”. Or something like that.
It’s a lot less factory-like than one might think. If you want to see factory-like music production, travel back to the 20th century, there was a lot of it. Look at the Brill Building, or Motown, for example.
What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.
In the meantime, I have this impelemented in TypeScript in case anyone else will find it useful: https://github.com/ShieldBattery/node-interval-tree