Hello to everyone. I have a question that was stuck in my mind for years.
Why was it more easy for Sierra On-Line to create a game engine (A.G.I) for the King's Quest I (since the engine itself would be written in assembly language) rather than just code the game in assembly?
The only reasons I can think of is the ease of portability and making easier the process of creating another (and another) game. Sierra was creating a game for a technically "advanced" machine of the era, so, Sierra was not thinking about portability in my humble opinion. And how would they know if they were to create another game for the PCjr? So, I believe, these 2 reasons were NOT the real reasons.
So, why? Was it really more easy to create a game through a game engine? Why was that? Can someone explain it in simple english?
It is very strange for me.
Btw, I am a total noob in programming and game engines...
I'd say they were just looking at the future of computer games and realised that a game engine allowed them to do so much more the next time around without having to reinvent the wheel...Whether they got another licence on the same label or not did not matter...They knew that whatever they created would give them the experience to further develop their games...
In Wikipedia, it says: "The project (King's Quest I) was too complicated to write easily in assembly language, so Sierra began developing a scripting engine that would greatly simplify programming of the game."
This sentence does NOT "contain" nothing about future games to be made. It talks about the one and only game, King's Quest.
:)
Yeah, there are definite advantages to an adventure game engine, even for just one game. (This is what Ron Gilbert found when he started working on Maniac Mansion, as well. If I remember correctly, he got bogged down for some weeks or months trying to code the game directly, before he gave up and built SCUMM instead.)
It's a bit hard to explain if you don't know anything about coding, but I would emphasize these points:
- Assembly language is absurdly low-level. You can only really add and subtract numbers, copy a value to another value, and check if something is zero (and jump to another instruction if it is), and maybe a couple of other things. Doing anything meaningful at all (even something simple like "draw this graphic on the screen") takes a lot of assembly code. Once you have something more powerful, you want to do as little coding as possible in assembly, because it takes a lot of time and is difficult.
- A lot of the code in an adventure game is repetitive. For example, there are lots of rooms, and all rooms have a lot of things in common. There are characters, and characters can do certain stuff (like walk around). In text-parser games (like the early Sierra titles) you can enter text, and it has to be interpreted in certain ways. You don't want to have to code this over and over again for each instance, so you'll write some piece of code that can handle it for all cases. That's the start of a game engine.
- Programming a game from scratch (in assembly or some low-level language like C) is difficult, and you really need to be a trained programmer to do it. If you coded the game directly, the game designer (if she doesn't know how to program, and I don't think Roberta Williams did) would need to sit over the shoulder of a programmer and explain what she wants all the time. Working in a scripting language is usually much more intuitive, and game designers, animators, artists etc. can pick it up pretty quickly and do a lot of the scripting themselves.
- With a game engine, it's quicker to update scripts and resources (graphics, sounds, etc.), because you don't have to recompile the whole engine/game code. That could take several minutes (or even more), depending on the complexity of the engine/game and the speed of the computer; with a game engine that will typically be reduced to a matter of seconds. That makes a big difference if you're constantly adding new bits to the game (a new script or animation, for example), then want to test it before you move on.
Maybe another way to think about it: If you're trying to paint an image, and the only tool you have is Notepad (and a compiler that can convert a text file with a series of numbers into an image file, or to a computer program), would it be easier to "paint" the image by entering the right numbers into Notepad, or would it be easier to start by making a simple painting app that would allow you to paint on a canvas and see the results in real time? For very small and simple images (like a 16x16, 16-color icon), it's probably the former. But once you get into something more ambitious, it'll save you time in the long run to have a more convenient and powerful tool to work in.
You only have to build the engine once. It handles all the tough scripting and now you can use a set of commands to easily perform tasks (walkto x,y). Now the designer can focus on the creative part and have flexibility because the hefty engine design is behind them.
So if even only for one game it saves time (probably) in the end.
Snarky beat me. Read his ;)
The answer is that if you had coded the game in assembly, then it would already be the engine.
For example, KQ1 has about 60 rooms. You could write 60 different pieces of code to draw rooms and have a character move around in them, but that would be horribly inefficient. Instead, you write a generic piece of code that handles a room, and re-use it 60 times with different data. You apply the same for characters, objects, and input: a simple generic class that can be reused as often as you need in the same game.
...but that's precisely what an engine is. As soon as that's functional, you can also replace the rooms by other rooms without affecting anything else, and ta dah! You have King's Quest II. It's nothing but smart programming.
Note that LucasArts did exactly the same: when designing their first adventure game, they first wrote the SCUMM engine. Every well-written game with multiple locations will be written as an engine first.
Yes, but you're applying principles of abstraction that were very far from universal at the time. In the early 80s, the very notion of structured programming (e.g. Pascal and C), with well-defined, reusable functions, was still pretty cutting-edge. Object-oriented programming was a relatively obscure notion mostly confined to academia. It wouldn't have been that surprising if Ken and Roberta had e.g. hard-coded the list of words their parser could understand as part of the KQ game code. (I'm not sure how they developed Mystery House and their other text adventures. Perhaps they already had a text-parser codebase they reused.)
I think the big distinction here is whether the code that defines the gameplay is written as part of the same codebase and in the same language as the code that handles the basic generic operations, particularly if the two are intertwined in some intimate way. In some games that's the case (Flight of the Amazon Queen was written that way, I seem to remember reading), but most games tend to impose a pretty clear-cut division between engine code and game code.
Of course, an engine written with one specific game in mind will be (overall) less flexible and more customized than a more generic engine like AGS.
Thank you ALL for your well written and very explenational answers. My apologies for my bad english. I think I got the point although I am a total noob in coding. See ya. :)
Quote from: Snarky on Thu 05/11/2015 16:23:29
Yes, but you're applying principles of abstraction that were very far from universal at the time. In the early 80s, the very notion of structured programming (e.g. Pascal and C), with well-defined, reusable functions, was still pretty cutting-edge. Object-oriented programming was a relatively obscure notion mostly confined to academia.
Well, Infocom did it four years before King's Quest, and with a better parser to boot :)
Here's an interesting writeup of the genesis of King's Quest: http://www.filfre.net/2013/07/the-unmaking-and-remaking-of-sierra-on-line/ (http://www.filfre.net/2013/07/the-unmaking-and-remaking-of-sierra-on-line/)
If you dig further into the backlog you can find the very roots of Ken & Roberta, back to before Mystery House here: http://www.filfre.net/2011/10/ken-and-roberta/ (http://www.filfre.net/2011/10/ken-and-roberta/)
This discusses many of the technical aspects of the game's development, including the suggestion that the engine was fully intended to be re-usable for future games.
Quote from: ThreeOhFour on Fri 06/11/2015 04:21:00
Here's an interesting writeup of the genesis of King's Quest: http://www.filfre.net/2013/07/the-unmaking-and-remaking-of-sierra-on-line/ (http://www.filfre.net/2013/07/the-unmaking-and-remaking-of-sierra-on-line/)
Very interesting. I didn't actually know that Sierra was already an accomplished publisher with strong ties to IBM before they started KQ. That goes a long way in explaining their architecturally sound engine-first approach to writing KQ.
http://www.ign.com/articles/2014/12/01/igns-year-of-adventure-all-our-point-and-click-adventures
They might have wrote about it in one of IGN's year of adventure articles... even if they didn't, its a fun read :)
Game engines can make things easier to use for creative people, causing them to waste less time with source code and more time with artwork.
Game engines can make large projects easier to share tasks among larger teams.
It can make sense to write a game engine for only one game. this easily happens if you looked at all existing engines and none was sufficient for your project.
Just a couple of things to add to what ever one else said. Back in the day compiling C or ASM could take an hour or longer whereas a script could be immediately executed.
Also the games industry is not the only or the first to utilize a domain specific language and IDE. PLC and DCS come to mind in the area of industrial control.