Hacker News new | past | comments | ask | show | jobs | submit | ludr's comments login

My late-nineties elementary school computer class was mostly devoted to learning about and building a project in Hypercard on the school's Mac Classic fleet. The project was to build a "house" of our own design with each room being a card or collection of cards - and to allow movement between them by clicking on doors, windows, etc. like a LucasArts adventure game.

It wasn't expected that your house be based in reality, so some people went further with this than others by adding animations or hidden-object like game elements. I remember it being a lot of fun and something that seemed accessible to everyone regardless of experience with computers.

I hadn't put it together until right now, but I wonder how much that experience influenced my eventual educational and career path (among many other factors). It really was my first experience with creating something interactive on the computer, not quite programming in the way I do now but getting those same gears turning.


Myst was just that - a HyperCard stack (actually many of them).


Under schedule pressure that's certainly true, but subsequent products will often start by taking a skeleton of a previous one. In this way tech debt could live on for many additional games unless it's addressed.


Is this actually true? The engine lives for multiple games, and the tooling is often reused as-is, but do games start with existing projects, or do we add new technical debt through the cleansing baptism of copy-paste?


What year are you asking?

In 1982: all games were written from scratch. You might copy the good parts from a previous game, but there generally wasn't much: poor abstractions meant the game logic and UI was mixed together (in their defense, on the limited CPUs of the day you couldn't have made proper code separation work, and of course the limited CPUs also meant you couldn't create such complex systems where it mattered.)

As games entered the mid 90s games started to get releases, and game engines came out. However each release was treated like an all new project even if some code was reused. Games would customize the engine in ways that wouldn't apply to the next game. Bugs in the engine would be worked around by ensuring that part of the game could not be reached (thus resulting in games that you could never get the 100% complete stat as the engine knew you didn't go through some locked door without a key). Some of the core engine was reusable, but for the most part the engine and game were tested as one.

Sports games tended to be the first to figure this out: every year was a new release of essentially the same features, but different player stats. As such it is becomes obvious quickly the game engine maintenance is a cost, there were few new features (until the next console offered better graphics). Most other games were latter because part of the new game was engine changes to support it, so it was hard to find a stable core to the engine.

Gradually games have seen more and more value from separating the engine from the game. As this has happened engine changes are no longer for one game, but for the possible use by all future games. Part of this is game designers have figured out the right abstractions, things that previously would have looked unrelated and thus change different areas of the engine are now seen as variations on a theme if you squint just right - and we know how to squint

Of course there have always been, and probably always will be one-off games written like 1982. When your game is small this is okay.

Different game companies have reached this at different times. Infocom had mostly figured out their reusable engine in 1982.


Underneath it says "& be nice to people".


Does the text size imply the priority?


uhh, don't know what beach you guys are working from, but I appreciate a strong 'Work hard' vibe, myself.

You want a chilled out work-to-life ratio, there's a number of places out there for you. Hell, some of them are startups. But part of the appeal of working at a startup is that you gotta get shit done.

Work hard and be nice to people. Not a bad thing to see on your wall.


But part of the appeal of working at a startup is that you gotta get shit done

Agreed, but it's a bit gauche to hang a sign on the wall stating the obvious. Unless you're running, say, a kindergarten class.


I believe this is mentioned in Logicomix.


Wow. I completely forgot about Logicomix: http://www.logicomix.com/ Never got round to reading them. I might just do so tomorrow :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: