HN user

Ogre

505 karma
Posts1
Comments165
View on HN

There used to be a site called Forgotify that would only play songs from Spotify that had zero listens. So each song played, of course, removed that song from the set that could ever be played by Forgotify. Doesn't look like it's around any more, sadly.

I'm with you, came here to ask this too. This is how I would have read it:

"Crack engineer" someone who is an excellent engineer, I feel like this goes back to at least the early 20th century, certainly long before gaming culture.

"Cracked engineer" a damaged person who is an engineer

Shrug. Language changes all the time!

Accelerando (2005) 2 months ago

The Merchant Princes series is fun, and I really enjoy the story of why he wrote it. It starts out as fantasy for basically the whole first novel and then some. But you can find some evidence from the start that it's really sci-fi, and by the end of the series it has dropped all pretense. It's sci-fi through and through.

This is all because he had an exclusive contract for sci-fi with his other publisher. But not an exclusive contract period. So he stealth wrote a second sci-fi series without actually breaking that contract until later.

I'm not sure if The Laundry Files was done for the same reason. It's possible. I haven't read those past the first novel. But I'm a big fan of everything else he's done.

"Moving left" is NOT an input. An input is "The controller is pushed to the left" (with perhaps a numeric value of how far it is pushed to the left). "Firing once" is similarly NOT an input. "The fire button is down" and "The fire button is up" are inputs. That is how well implemented first person shooters have worked since the Quake days (I think Quake 2 actually).

The point of the article is actually that the server doesn't validate anything. There's nothing to validate. The only data it gets from the client is the state of the controls. Then it runs the real simulation. The client only ran a prediction of what it thought the server would do. Sometimes, it's wrong and corrects itself when it gets new values from the server.

You can handle orders of magnitude more users with the same hardware if you don't have to run the game simulation on the server.

Just today I was arguing for not moving something off of Oracle. No one's really happy the thing in question is on Oracle, but it is live in production and most of the time does what it needs to. It ain't broke. Changing to "something else" carries way too many unknowns for my comfort level.

If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.

I only skimmed it, but I didn't see anyone in there who took years. They were all on the order of months. Entirely possible I missed it.

That said, adding networked multiplayer to a game is very difficult. But designing a game around networked multiplayer is not nearly as hard. Single player or local only multiplayer games can get away with lots of assumptions that completely break multiplayer, and detangling all of those assumptions is the most time consuming part of converting a game. If you do it "right" from the start, you don't ever allow yourself to make any of those assumptions and everything just works. If you know you're going to build a multiplayer game, then write it as a client server architecture from day one even if you know you're not going to play with other people for the first several months of development. Future you will thank present you.

In the 1990s, people used to write these things called plugins to add features, like support for specific video containers and codecs, to browsers. Now I guess browsers have to have everything built in or not at all. "Progress".

Partly answering my own question after mulling it over, the difference in the pre-pass is that you're not actually coming "from" an edge or going "to" one when you're doing the flood fills, you're just testing which edges are connected to any given empty cell. But I still think there might be something to this idea. The simplest thing I can think of is to do no-backwards searches out from all the empty cells on each edge and see which other edges you reach. That's potentially 6x as many searches (slightly smaller and with some early outs since the connectivity is bi-directional), but at least it's still finite and predictable and isn't who knows how many raycasts. I don't know if that's acceptable for the pre-pass or not. But I also think there might be smarter ways to do it that only require a single search from each empty cell but remember directions traversed so you know if a particular path you've reached an edge along implies visibility or not.

Maybe you can do the 6 searches in parallel, such that whenever they meet you know you've found a connection between the two edges they were coming from? I don't know if that means any less work except in cases where all 6 edges are trivially connected.

For the actual occlusion test, you have a "don't go backwards" rule. If you have to go backwards to reach a chunk, you know it's not visible along that path (but may be on a different path, which you will eventually find). Without having thought about it a whole lot, does that work for the inside-a-chunk tests too? If you have to traverse an edge facing back towards the face you're coming from, does that mean there's no visible path from the first edge to the second? And if so, would that give a meaningful reduction in connectivity?

Glitchiness of occlusion may be driver or hardware dependent. I've been using it successfully, but haven't tested on a variety of hardware. The bigger issue is the two way communication between GPU and CPU. You want your pipeline to be one way, otherwise you either have stalls waiting for results (poor or inconsistent framerates), or things becoming visible one or more frames later than they should. For some applications, the latter is acceptable. For Minecraft (style) chunks, it might mean sometimes large amounts of terrain popping in a frame or two too late, which could be very noticeable.

It seems like a combination of both might be feasible. Do something smart like this article on the CPU, which feeds into a greatly reduced set of occlusion queries, small enough to perhaps not introduce significant stalls using the first method.

However, in this article's case, he's specifically targeting the mobile edition of minecraft, where hardware occlusion is not yet universally available! So fast CPU versions are definitely warranted, and I think he's got a really good solution.

I approve of people trying to improve the editor experience. This is a good project! I have a nitpick though:

"forking the current panel using Ctrl+F is a game changer, as you don’t have to scroll away from your current code location when looking up something at a different place in the same file."

A game changer over what? Are there editors that don't let you do this? The two I mostly work in are Emacs and Visual Studio, and you can do this in both. (I'd actually have to hunt around for how to do it in VS, I use both side by side because of a whole lot of Emacs muscle memory, but it's there for sure)

It worries me that he's not actually aware of the features available in the editors he's trying to improve upon.

It's likely coming to PC as well. It was announced last year without any console attached. At E3, it was at Sony's keynote, but it wasn't announced as an exclusive. On the other hand, they haven't explicitly said it will be on PC either, it's just an educated guess.

Surface Pro 3 12 years ago

For MacBooks there's these things: http://hengedocks.com

I had one for an older laptop. Worked fine, but I didn't use it much just because I wasn't at my desk at home very much.

I can't speak for all games, but this sort of visualization is something I believe to be common in large AAA games, and is something I've had (and continue to have) in the small subset I've worked on. On the other hand, it's always been custom code (like the engines themselves) and I would guess not something a lot of smaller studios would feel justified spending time on until they needed it. I don't know if that's true. I've found that just providing some simple easy to use debug line and shape drawing that lives outside the rest of the rendering systems means people will use it for this sort of thing all the time. After a while there'll be a bunch of useful visualizations built up and if none of them do quite what you want, it'll probably be easy to modify an existing one.

I do think Unity and Unreal both probably provide a lot of tools in this department, so the situation outside crazy developers still using custom engines is probably a lot better than I think it is.

Also, it's almost certainly true that way more time goes into mundane, repetitive game testing than you thought. The QA budgets for AAA titles are quite large, and a lot of that testing work is horrifyingly dull. Methods like this post outlines help a lot, but there's no substitute for actual people getting paid to try to break your game.

Something you can do with components if you set some strict restrictions is do static or runtime analysis to determine which sets of components are disjoint in terms of systems that access them. For example, if the combat system only needs access to combat components, and the builder system needs pathing and inventory components, then those two systems can run completely in parallel.

One place this is likely to break down is the transform (position) component, but one strategy for that is to differentiate between read-only and write access. Lots of systems need to know where things are (const access) but few need to change where things are (write access). All the systems that can deal with const access can still run in parallel.

The trick here is you have to strictly enforce all this. You CAN'T have a method for getting an arbitrary component from an entity, and this may drive you nuts. Instead you have to have each system specify ahead of time exactly what components it needs and how it uses them, and then hand them those components, and only those components. As soon as you let someone write "entity->GetComponent(Physics)" in leaf code, you've lost your ability to analyse the dependency tree.

For a lot of games, the other problem you're going to run into is that one or two systems are going to take up most of your time and every other system is just going to sit around waiting for those anyway. Usually those are physics and rendering. Which you might be happily avoiding by making a dwarf fortress style game!

I have a coworker who's got a "toy" engine at home that does all this and some other fairly amazing tricks. He says he's going to open source it, still waiting on that. Sorry for this pointless tease, just wishing he'd hurry up out loud.

Powersnap was amazing. I seem to recall it was usually able to figure out what font each program was using and only had to search for letters for that specific font, and only fall back to a bigger search if that failed. I might be misremembering, but regardless, it was essentially as fast as any copy-paste today, in an environment where many programs weren't even written to support it.

Even though it solved a problem we don't usually have today (this story notwithstanding), it was still one of the most amazingly useful programs ever.

I thought it was kind of hard to take the article seriously after that. I know it's the guy's real name, so I feel bad about this (as bad as I can feel for someone with an awesome name!), but it doesn't change that it sounds like something from a comic book. A fusion scientist named Omar Hurricane? Come on! Next thing we hear is there's been a horrible lab accident involving high powered lasers and lead scientist Omar Hurricane has died. Only he hasn't really, he escaped death and and went into hiding, avoiding public shame while also training to use his new found weather controlling laser eyes. But for good or for evil? Is Mr. Hurricane a villain or a hero? Buy the next issue to find out!

It's really not much like Lode Runner at all. Lode Runner itself was a "clone" of Space Panic much more so than this is a "clone" of Lode Runner. In both cases, there is clear inspiration drawn from the earlier game, but they are very much original works.

I wrote a shareware Lode Runner clone on the Amiga 20+ years ago. Mine was definitely a clone, no bones about it. Spelunky is barely related.

I work in Orange County, not far from the airport (and even closer a few years ago) I did the napkin math on commuting from Arizona every day at one point, and it definitely worked out. I would've saved money doing that.

Of course that presumes that my sanity has no value, but I'm not certain how much worse it would have been than some people's driving commutes.

Phil Plait's (Bad Astronomer) review(1) on Slate is based on the actual movie rather than the trailer. The summary is that despite some big problems with the science, it's a fantastic movie and you should go see it. I agree with him, I saw it yesterday and loved every minute of it. I'm able to both recognize that it's not scientifically accurate and still enjoy the hell out of an otherwise well written, acted, directed, and beautiful film.

(1) http://www.slate.com/blogs/bad_astronomy/2013/10/04/ba_movie...

That's true, but the OP said "Typical DVD-quality SD bitrate". DVDs use MPEG-2 encoding, but there are much better codecs available today, such as H.264, which can achieve equivalent quality at substantially lower bitrates.

Opinions vary on what the "best" bitrate for transcoding DVDs to H.264 is, and it depends on what your content is too. In a quick search I found people claiming as low as 500kbps(+128kpbs for audio)[1], which is half what the OP uses, all the way up to 2500kbps[2], double his figure. All of which leads me to believe that 1.25Mbps is a pretty reasonable napkin number.

[1]http://forums.macrumors.com/showthread.php?t=842536

[2]http://www.networkedmediatank.com/showthread.php?tid=6867