Fun fact: we (Naughty Dog) actually had Crash Bandicoot running on SGI workstations in high resolutions using (I think) OpenGL back in 1996. You had to use the keyboard to play, though. :)
That blog post series is highly informative and interesting, and goes over a lot of cool technical specifics. I highly recommend reading it to anyone who hasn't.
Hey I'm mainly a lurker on hacker news and haven't posted yet, but I just wanted to let you know that Crash Bandicoot is what got me into video games and probably technology in general when I was a kid. If it wasn't for that game there is no way I would have taught myself how to make video games or eventually become a programmer myself. Thank you guys so much for making such an awesome, influential game!
I remember getting a VHS tape from Alias|Wavefront as a PowerAnimator demo or something and there were you guys from Naughty Dog demoing Crash on Indigo2s!
Maybe Andy forgot to mention it; it's been a while since I've read the whole series.
The code was C and lisp so it didn't really require any effort to port other than replacing the rendering pipeline. And we used the SGIs to pre-render every frame anyway, to precompute the polygon sort order. (The PS1 had no Z-buffer, so you were stuck sorting polygons at run-time if you didn't do something clever.)
So we already had the rendering pipeline ported. Obviously you couldn't save your game to the memory card, etc. -- some stuff didn't work. But the game was playable (albeit very frustrating with keyboard controls).
That blows my mind, I always assumed it did have a z buffer. So what did you guys do to remedy 'z fighting' triangles? My interest is; I wrote a 3d renderer in Java using fillPolygon() many years ago, and used polygon sorting in place of a z buffer. Z fighting was of course a problem.
Some day I will write this up for real, but without going into detail, here's a summary.
The camera in Crash was on a rail. It could rotate left, right, up, and down (in Crash 2 and beyond, at least), but could not translate except by moving forward/backward on the rail. This motivates a key insight: if you're only rotating the camera, the sort order of the polygons in the scene cannot change.
This allowed us to sample points on the rail and render the frame at each sample point ahead of time, as a batch job, on the SGI using a Z-buffer. (We may have done the Z-buffer with software; I don't remember.) Then we could recover the polygon order of each frame by looking at the Z-buffer. And, even better, at run-time we could simply not render at all those polygons that weren't ultimately visible in the pre-rendered scene. This solved both the sorting and clipping problem nicely, and made the look of the game closer to 3K polygons/frame vs. the 1K polygons we were actually rendering in real time. (Many polygons were occluded by other polygons.)
The trick, though, was what exactly to do with this sort/occlusion information. In a nutshell, what I did was write a custom delta-compression algorithm tailored to the purpose of maintaining the sorted polygon list from frame to frame, in R3000 assembly language. Miraculously, this ended up being quite feasible because the delta between frames was in practice very small -- a hundred bytes or so was typical. And if a transition was too heavyweight (i.e., the delta was too big) we'd either sample more finely in that area or tell the artists to take stuff out. :)
One thing nobody talks about but which is obvious in retrospect is that without a Z-buffer you're pretty screwed: sorting polygons is not O(N lg N) -- it's O(N^2). This is because polygons don't obey the transitivity property, because you can have cyclic overlap. (I.e., A > B and B > C does not imply A > C). This is why virtually every game from that era has flickery polygons -- they were using bucket sorting, which has the advantage of being linear time complexity, but the disadvantage of being wrong, and producing this flickery effect as polygons jump from bucket to bucket between frames.
I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
I had to make an account to say this, please do the write up! I've been fascinated by crash ever since playing it in the 90s and had that reawakened after reading Andy Gavins blogposts.
Hearing how you managed to squeeze all this stuff out of what sounds like it was an experimental platform for 3D is just amazing.
Seems like that scheme doesn't necessarily solve z-fighting, unless your method also split overlapping polygons something akin to Newells algorithm.
>>I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
We didn't split polygons, and you are correct that this doesn't provide an absolutely perfect solution either. However, it does in practice eliminate the flickery polygons, because the polygon ordering is far more stable than it is with bucketing.
And you can actually see a difference between Crash 1 and Crash 2+ if you pay close enough attention. For Crash 2, Stephen White cloned the PS1's renderer in software for the SGI so that it was pixel-for-pixel accurate. He did this in like two days, thereby earning himself a place in my top-5-programmers-I've-ever-worked-with list.
If you look closely during Crash 1 while you're moving Crash, you can see sometimes see what Andy not-so-affectionately called "crispies". These are pixel-size flickery bits caused by the subtle difference between the SGI's renderer and the PS1's hardware renderer. Just the difference in the way the two implementations rounded fractional coordinates showed up in the game.
What stood out to me was the graphics in Crash bandicoot series. They always looked very good compared to other games which has the weird jumpy textures and very rough looking meshes.
I must say going with very minimal texture on Crash is intriguing. FF7 also uses very little I believe during combat, they all look like color shaded mesh but it clearly looks good on Crash.
All these development stories from 90s is fascinating, especially because there's a fond childhood attachment to the PSX.
On one of the Playstation Underground Magazine discs there are entire series on the development on Crash Bandicoot. These are truly a gem. Myself having watched the entire series.
Yes, exactly: Crash was flat-shaded (not textured), and I believe it was Jason (Rubin) who made that call.
Crash also benefited from the (at the time) novel rendering model that Andy, Mark (Cerny) and Jason developed. This basically allowed any vertex of crash to move anywhere in the animation sequences -- which was huge, because it allowed Jason to approximate traditional squash-and-stretch even on that limited hardware.
A hypothetical trojan horse doesn't have to use the network itself. It could just hide some essential data and/or plant a vulnerability for a later attack.
The air spin attack was definitely just a Mario jump sound with the pitch adjusted.
It seems to be a 1:1 copy of Mario 64/Galaxy mechanics but without any of the aesthetic charm. Inspiration's good and all, but straight up copying isn't. That's just insanely off-putting to me.
That's really great as most advanced examples for Unity are at a high price. Most free projects on the web are quite simples. It can be a great starting point to make a 3D platform game.
the classic game "Descent" was written by Parallax and published by Interplay. The split-up remnant of Parallax owns all of the assets -- the ship name and artwork, the name of the evil corporation, the music, the robot artwork. Interplay owns the name Descent. Anybody can make a game that flies like Descent (Sol Contingency and Geocore are both trying to), but only an Interplay-licensed company can call their game "Descent", and only a Parallax-licensed company can put in the "Pyro-GX" and the "PTMC". And there seems to be some distrust between the two companies.
This has led to a fair bit of complication for the Interplay-licensed Descent:Underground game (currently on kickstarter -- https://www.kickstarter.com/projects/descendentstudios/desce... ). A lot of fans are asking "where's the pyro?" Well, they can't have the pyro, because they don't have a license for that part of the game. They can make a ship that looks fairly similar and flies identically, but it has to be identifiably visually different and have a different name.
This statement surprised me. Is it really true? It appears that there is conflicting precedent:
"The first approach is from the 2nd circuit "The Subtractive Approach" (Altai, Nichols) and the other approach is "The Concept and Feel Approach" (Ruth Greeting Cards, Krofft)"
> I am curious to know what would happen if someone decided to clone the exact level design of a game but changed all the audio/visual assets.
This actually happened quite often in early generations of computer games and consoles. Super Mario Bros had quite a few clones where all that changed were the visual assets.
More recently, there are many examples of this happening on the iOS App Store and other venues with a low barrier to entry.
I seemed to recall such Mario clones as well. Nintendo is quite protective of their IP, so I have to think that they must have threatened legal action. Does anyone know? Is there precedent for legally protecting the layout of a level?
I think the clone I'm semi-remembering was a PC game. Regarding your second question: There were very many unlicensed Nintendo games. I don't know how many of these Nintendo fought. They very famously battled Tengen over this issue in the courts.
But they are patentable (or at least elements of them can be). Konami successfully sued[1] the makers of In The Groove, a Dance Dance Revolution clone. I know parts of Mario Kart are patented[2], so I wouldn't be too surprised if parts of Super Mario 64 are patented as well, given that it pioneered the 3D platformer genre.
Pure speculation: It's possible Super Mario Sunshine(2002), Super Mario Galaxy(2007) and other Mario-like 3D could have "refreshed" any patents from Super Mario 64.
>"1. A dance game apparatus comprising: music output means for outputting one piece of music from at least one stored piece of music; a floor panel having a step-on base section; said step-on base section comprising a top panel and a support member which supports the panel; detection means for detecting a stepping operation on said step-on base section; said detection means comprising stepping sensors interposed between said panel and said support member at mutually opposing positions of said panel; said stepping sensors comprising longitudinally extending conductive sections having a longitudinal length, one of said conductive sections being moveable laterally relative to another of said conductive sections at any one of a plurality of positions along the longitudinal length of said one conductive section to effect contact with said other conductive sections at any one of a plurality of corresponding contact positions such that said stepping sensors detect stepping on said step-on base sections at plural locations corresponding to said plurality of corresponding contact positions, guidance means for performing a stepping operation instruction to said step-on base section in time with said music; measurement means for measuring a time deviation between the timing of a stepping operation instruction and the time at which the fact that said step-on base section is stepped on is detected by said detection means; and evaluation means for providing a higher score the smaller the measurement result." //
FWIW the Mario Kart patent you cite refers to methods of controlling NPC in order to provide strong rivals, avoid bunching of NPC in racing games and provide variation in race orders despite relatively fixed characteristics (acceleration and top-speed). None of that prevents you having cars with the same styles, having the same tracks, having the same end goals, having the same range of pickups and such - it only relates to specific algorithms for providing competing computer controlled cars/NPC.
The game's actual source code would be under copyright, but presumably you could re-write a game and exactly copy its gameplay and that wouldn't be copyright infringement any more than writing a poem using the same meter with different words as a famous poem would infringe.
> any more than writing a poem using the same meter with different words as a famous poem would infringe
This is clearly a rabbit hole of exceptions and ifs, but this somehow doesn't apply to music as well, based on the recent judgement over Blurred Lines (the song).
APIs are copyrightable? I don't think so. Oracle lost, after all.
However, on the primary copyright issue of the APIs, the court ruled that "So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical." The ruling found that the structure Oracle was claiming was not copyrightable under section 102(b) of the Copyright Act because it was a "system or method of operation."
That ruling was overturned on appeal. From the same Wikipedia page:
_The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable._
The sentence "games are not copyrightable" isn't particularly meaningful. That does not inform what is or is not protected. The link in question does not say that games are not protected. It says, and I quote, "Copyright does not protect the idea for a game". Keyword: idea. The idea is not protected. The expression is.
What is a game if not an expression of an idea? I would not call the idea for a game a game. I would call the expression of an idea a game. Therefore I would consider games protected by copyright. At least in casual conversation. When speaking in legal terms there is a lot more nuance.
If you re-created Mario 64 from scratch but art swapped every asset with something original you would get bitchslapped in court. Hard. The layout and configuration of levels is not an idea. It's an expression of an idea. If you want to make a different level using different assets but using the same mechanics of Mario 64 then that is probably acceptable. You're making your own expression.
It does get a little tricky if you start copying the physics of Mario 64 precisely. There are lots of platformers. Why copy the exactly moveset from Mario 64? Why meticulously reverse engineer the physics of jumping from Mario 64? Copy too much and you run risk of losing a copyright suit as demonstrated by Tetris.
A set of rules. Such rules are potentially eligible for patent protection. They are not eligible for copyright protection.
> On one hand you can say that games are not protected. Tetris however is. And has successfully been defended us such in court.
I suggest you read the actual text of the Mino decision, which rests heavily on visual elements, not gameplay. I also suggest you not put too much stock in the decision of a single district court judge. District court decisions are not binding precedent. Especially ones obviously written by a judge who either doesn't understand what the functional elements of a game are, or was looking for an excuse to find for Tetris.
> The layout and configuration of levels is not an idea.
For you and I to have a meaningful discussion we would need to not use the word game. I'll just leave it at that.
At least you agree with me that layout and configuration of levels is protected by copyright. At least I assume you believe that assets are protected. You don't specify.
All of these waters are largely untested. It doesn't take much discussion to hit them. Good luck.
In the context of this discussion, "game" should probably be read as referring to a particular software implementation of a game, like the game Super Mario 64. Not like the game of chess.
It's actually very important that games themselves aren't copyrightable. What if Doom (or whoever did the first FPS) had a copyright on FPS? There was an interesting article on HN a few months ago about the history of game lawsuits. basically, gameplay is not copyrightable, but characters, assets, etc. are.
Surely it's the 'level' of reproduction that counts? You're argument is like "what if Stephen King had a copyright on characters flipping out and attacking their families" - clearly, that would be ridiculous and no-one would argue in its favour. However, if someone made a scene-for-scene remake of The Shining with different actors, most people would think some sort of copyright permission would be required.
I'm not sure if you understand the video game industry, but literally every popular game is a clone of something that came before it.
EDIT: This is obviously not true for some X where X is a base case of a popular game genre (e.g. Portal, Donkey Kong, Wolfenstein 3d), but it's generally true. Mario 64 is just a 3d platformer at some level, which is why it's so easy to clone.
The games on the right certainly are the originators of the games on the left; in fact, in both cases, the developers of the game on the right were the very team which followed up by developing the game on the left.
I like their response to the person who suggested not open-sourcing it:
"Most closed source things will likely be useless in 5-10 years unless constantly updated, and even though not likely. Once opensourced, however, it can endure. You get tired of it, feel it is done, or just need to move on, someone can always come in and make sure it works on new systems. "
Yeah, I seem to remember a very similar project (resurrecting this game in HD) being DMCA'd to hell and back a few years ago. Has Nintendo eased up in recent years?
He's not trying to resurrect the game though, he just wrote a character controller so you can implement mario-like control in your game and showcased it with assets from the mario games. Still, I expect Nintendo to come calling any day now and demand that he remove all assets he ripped out.
When that happens, I suggest he call it Dangerous Dave Controller.
It's a cool project with a lot of effort in it. One gripe though...
"Everything is just as you remember, except some really minor stuff that nobody cared about like red coins or the Wing Cap or the Big Bob-omb."
Chain Chomp is missing and lots of people cared about him, and there is a TON of environmental detail missing too, causing the level to look very empty.
"Haha I was mostly kidding about the Wing Cap. It’s actually one of my favourite parts of the game! But the time it would take to do the code and animations would just have been too much extra. Same goes for the other moves, since it took awhile to do each animation. I tried to make sure all the essentials were in first and foremost. Glad you liked it!"
> ...minor stuff that nobody cared about like red coins...
Wahhhhhhhhh!(?). You needed the red coins to get the star! Who DIDN'T care about the red coins?! I'm not a completionist, but getting the red coins in Mario64 was actually a fun challenge and not some tedious badge task.
Couldn't get it to run under Chromium or Firefox on Linux. Even reset Chromium (since I rarely use it) to defaults. Nudda, blank. Does anyone know what this requires?
I really ask, why the people do remakes (and mods) of games and risk to be taken down for copyright violations. I think, it would be much more sensible to invest this creativity into creating new games that aren't burdened with copyright pitfalls.
This clearly shows that people love copyright violations. Why aren't they at least consequent and lobby for far more liberal copyright laws. One says "put your money, where your mouth is". I say "put you lobbying, where you HN upvoting is".
I noticed an issue with the music : There is a monotone guitar riff in the background that clashes with the main melody at times. Listen carefully and I think once you notice it, it will not stop bothering you.
The background music is “Nostalgic Fortress”, copied directly from Nintendo’s Super Mario Galaxy 2.
I hear the guitar riff in the left audio channel, but I don’t notice it ever clashing with the main melody. It plays varied chords most of the time. When it is monotonous from 0:39 to 0:55, the note it repeats is always a note in the underlying chord, so I still don’t perceive it as clashing.
@jrushing, this might be the greatest thing ever? Though idk if I trust the author yet. I might try it on a blank computer so no important info gets stolen, just in case ;)
See http://all-things-andy-gavin.com/video-games/making-crash/ for more making-of details.
EDIT: And they were running 200Mhz MIPS CPUs - blazing fast!