Adventure Gamers - Forums
You are here: Home → Forum Home → Gaming → Adventure → Thread
Post Marker Legend:
-
New posts
-
No new posts
Currently online
Devs/Sequels jump to a modern outlook
A parser interface has a different range of actions for the player. I don’t mean “type a command and press enter”, but “Pick Up the Phone Booth” or “Play jig on trumpet”.
A point’n'click game has a few (or maybe even just one, in the case of Myst) actions you can perform on each in-game object.
But sure, if we’re being pedantic, you don’t point the mouse and click, and in some contexts that distinction really matters. I was just reacting how you said you “can’t understand how some people could make [the] mistake [of calling Grim Fandango a point-and-click game]”. So I’m trying to explain the thing you said you couldn’t understand. I don’t expect you to agree with me, but if I’ve managed to do what I tried to do, you should understand it by now.
I get your point, but “behind the scenes” those would work more or less the same. You would need to define an object somehow in the code, and then have a set of actions that can be done to that object.
Just because you have a seemingly unlimited number of options to try in a text adventure doesn’t mean much, if there is only one option that will actually advance the game. And anyone who has played text games knows that the most actions attempted only produce “I DON’T UNDERSTAND” or some similar message about player trying to do something that hasn’t been programmed. In the early LucasFilm games the line between text adventures and point-and-click was very thin, because the user interface had a set of action verbs, like open, push, etc. So the only real difference was just that, how you enter commands.
We combine two lines of code into one, making the code more efficient.
How many lines of source code a program takes up is totally irrelevant to how efficient the program is unless you are coding in assembly language (which no games are anymore). In a high level programming language a compiler would probably convert the two examples you gave to the exact same assembly code and machine code.
That’s debatable, I would guess that in most cases it would set the value to whatever is the default when introducing a variable without any given value, null or something, and so there would be two things the computer would do: set value to default, and then set value to whatever is given. Combining those into one command doesn’t save much time, less than a second in any case, but still it probably does. So as an example, it’s valid in many, not necessarily all, cases.
We combine two lines of code into one, making the code more efficient.
How many lines of source code a program takes up is totally irrelevant to how efficient the program is unless you are coding in assembly language (which no games are anymore). In a high level programming language a compiler would probably convert the two examples you gave to the exact same assembly code and machine code.
That’s debatable, I would guess that in most cases it would set the value to whatever is the default when introducing a variable without any given value, null or something, and so there would be two things the computer would do: set value to default, and then set value to whatever is given. Combining those into one command doesn’t save much time, less than a second in any case, but still it probably does. So as an example, it’s valid in many, not necessarily all, cases.
As someone who works on a compiler:
Russ is right, no compiler would bother initialising the data to one value and then setting it to another unless you explicitly turned off optimization. And many languages wouldn’t bother setting a default value anyway. It’s possible in a scripting language which is interpreted as you go, rather than compiled in advance, a change like that might make a difference, but even then it’s not a given.
But although the specific example is flawed, the rest of what you said was correct - if you can find a way to do less work in one part of the program, that can compensate for having to do more elsewhere.
Russ is right, no compiler would bother initialising the data to one value and then setting it to another unless you explicitly turned off optimization. And many languages wouldn’t bother setting a default value anyway. It’s possible in a scripting language which is interpreted as you go, rather than compiled in advance, a change like that might make a difference, but even then it’s not a given.
But although the specific example is flawed, the rest of what you said was correct - if you can find a way to do less work in one part of the program, that can compensate for having to do more elsewhere.
OK, I try to stand corrected, even though the example was more or less something that I was taught back in the day. It can also be that compilers these days are smarter than they used to be.
Of course most of my (admittedly limited) programming experience comes from scripting languages, and in those cases simply reducing the number of characters in a script could make or break the functionality of the whole thing. I still get annoyed when I think back how I was trying to find out the maximum, and of course undocumented, character limit by adding and removing characters one by one and seeing if the thing worked or not.
But I think this is getting a bit too technical, as the whole point was to demonstrate how changing the structure of the code can improve performance, which I think we all agree upon.
Since we’re talking about Syberia 3, here’s some of the patch updates posted by the Microids dev team on their website.
You can see how much work they did on both performance optimization and gameplay.
Patch 1.2:
Corrected crash when the game launched
Improved performance
- On some machines only, the game was a bit jerky throughout. We corrected this problem.
- For players who are still having issues with the smoothness, please contact our support team. http://support.syberia3.com/
Added C++ Redistributable 2010 & 2012 installation
Improved how achievements are unlocked
- O spirits, are you there?
- The scriptwriter’s nightmare
Improved voice/sub-title synchronization during certain cut-scenes (all languages)
Corrected a problem with the hospital lobby camera, which occasionally locked
Added a phrase by Kurk during the attack by the monster on the Krystal.
Corrected various display bugs on the Krystal (clipping, etc.)
Corrected various bugs in the theme park. Sometimes the stairs were a bit of a problem
Improved and corrected atmosphere and lighting
Corrected a bug where the music stopped when you went back to the main menu
Improved and corrected text in Polish, Korean, and Czech
Extended game compatibility with PC controllers (dual sticks)
MajorPoint and Click Update! Patch Note 2.0 PC [14/06/2017] MAC [19/6/2017]
Greetings all. We are continuing to take your feedback into account while working hard to give you the best possible gaming experience. With this in mind, we’re getting back to you today with a highly-anticipated patch that adds a Point and Click mode, so you cango through the entire game using only your mouse. A lot of you have been asking for this; now it’s here. We also added a few gameplay improvements and some minor bug corrections.
Controls:
-Addition of a Point and Click - “mouse only” - mode:-now the player can click on the spot he or she wants to move to
-all interactions can now be 100% completed using the mouse-We’ve corrected a visual bug where the interface wasn’t displaying the right keys for using or interacting with objects. The keys arenow correctly displayed.
Gameplay:
-The cursor has been revamped to make it easier to see in all circumstances (including on white backgrounds).
- We’ve added a visual indication in the form of a rotation icon during the knife tutorial on 3D object manipulation.
Audio:
-We’ve corrected a bug that occurred when the player finished the game: the music would stop during the credits and on returning to themain menu. The music now plays properly.
- We’ve corrected a bugin the German version of the game: in some cases, dialog was cut partway through. All of the dialog is now played to the end.
Text:
-We’ve corrected some of the text in the German and Spanish versions to make the translation more accurate.
- Correction of a bugthat stopped some sub-titles from being displayed
Optimization:
-Improved framerate in the following level: Hospital
-Improvedframerate in the following level: Bridge Over the River Balatom
You are here: Home → Forum Home → Gaming → Adventure → Thread