Page 2 of 26
Posted: Tue Jun 19, 2007 12:11 am
by techie775
Reading all those problems w/qfg2vga is actually interesting. I lost track how many times I got that stupid "Oops you tried something we didn't think of!" Error just from going from one room to another in the ega version.
As for the "Is it done yet?" question, I look at this as your free time, It's not costing us a thing, so we as gamers really have no right to bug you guys about it and when people do that all they are doing is wasting your time. (I know some people really have no clue but I was referring to the hecklers who are just trying to be a pain in the ass)
Posted: Tue Jun 19, 2007 12:46 am
by gamecreator
Awesome! Thanks for those!
progress of quest for glory 2 vga
Posted: Thu Jul 05, 2007 10:18 pm
by garden
well I am back again and it has been a month. How is the game going? I will check again in two months.
Posted: Fri Jul 06, 2007 4:52 am
by Erpy
We're still working out the bugs...fortunately, we're working on a batch that's "mostly" easily replicatable. (with the exception of the sample below)
985) I noticed that when you collect the elemental earth in the cloth bag, sometimes the hero's walking animation plays instead of his standing one, and it looks like he's walking on the spot. Maybe the view is not being set properly prior to his stand-up anim playing? It was in room363 (the first bend in Shmali Tarik that turns to the left). This is just a theory, but it may have something to do with the way in which you kill him. I didn't fight him in combat; I simply blasted him with flame dart spells until he toppled. Then I clicked the cloth bag on the elemental earth and the glitch occurred when the hero stood back up.
(reply)
I think what happened is the same bug that caused the crashes when picking up rocks in the desert. The bag with earth is heavier than the cloth bag and you were probably close to overweight when taking on Rocky, so as the bag of earth was added to your inventory after the kneeling down animation but before the getting up animation, updateweight() altered the view and since the getting-up animation is a low loop number (like 1 or 2), the game didn't crash, but simply played a loop of the hero's walking view. In this case, the bug should be fixed together with the rock-crashing bug in the desert.
Posted: Mon Jul 09, 2007 2:34 pm
by Haecon
I've been visiting this site since the days of the kings quest remakes.....just never bothered to join the forum....I don't know why...but what I do know is that I am beautiful no matter what they say...words can't bring me down.
I did find the wait rather enjoyable and I replayed and replayed QFG 1 to perfection...I now have a super fantastic save ready to load into this work of art when it's ready.
And Just a quick comment on "It will be ready when it's ready" I just wanted to say that; that line makes perfect sense...because after all how could it be ready when it's not ready or not ready when its ready. GENIUS!!!!
The production of this game needs only two main focuses: Cheaper & Faster!
Cheaper! Cheaper! Faster! Faster! Cheaper! Cheaper! Faster! Faster!
Anyway...Love the $hit you guys do! KQ2 Remake....Breathtaking!
Posted: Fri Jul 13, 2007 7:22 am
by Erpy
Here are some more:
-At the EOF, you mentioned disabling the iconbar while you're shackled to the wall. However, I noticed that it's still possible to make GUI 2 appear. If you save the game while shackled to the wall and then later restore the same savegame, GUI2 will be turned back on again allowing you to again press the WALK icon and make 2 heroes appear (and access the Magic GUI again etc.).
-In EOF, after defeating Walid, when the voices speak, make them appear higher on the screen. In fact, whenever the voices speak using the textbar, they should always appear up near the top of the screen at about y=25.
- When attacking a jack pack from afar, then luring them into close combat, escaping from combat, and finally killing them with flame darts from afar, I searched one of the slain bodies, and it said the I had found 0 dinars and 0 centimes. Instead, it should display a message that the enemy was broke.
- I noticed that when the griffin is blocking with his wings, you can hit him (albeit with your attack being deflected) from as far as 3 spaces back. However, if he's not blocking, then you can only hit him when standing one space back. Intentional?
- If the griffin kills the hero, then when the Death GUI appears, it shows a picture of the Terrorsaurus (or I presume, the previously fought monster). Instead, it should show the griffin.
- Should it be possible to encounter the griffin at night? Was this possible in the SCI version?
BTW, Haecon, I took your avatar down because it was really stretching the forums due to its size. Could you resize your avatar? Thanks.
Posted: Sat Jul 14, 2007 9:39 pm
by gamecreator
Always neat to see these. Thanks!
Posted: Sun Jul 15, 2007 5:30 pm
by MacGyver
Same here. This is some update I've been waiting for since the update on the main page.
Posted: Sat Jul 21, 2007 6:28 pm
by QFG2Remake
...
Posted: Wed Aug 15, 2007 7:20 am
by Alanor.
How's it going guys :) any release month fixed yet :D
Posted: Wed Aug 15, 2007 7:27 am
by adeyke
No.
Posted: Wed Aug 15, 2007 11:09 am
by Anonymous Game Creator 2
Yeah, it'll be out on the 35th of Octember.
Posted: Wed Aug 15, 2007 11:26 am
by Klytos
Erpy wrote:-At the EOF, you mentioned disabling the iconbar while you're shackled to the wall. However, I noticed that it's still possible to make GUI 2 appear. If you save the game while shackled to the wall and then later restore the same savegame, GUI2 will be turned back on again allowing you to again press the WALK icon and make 2 heroes appear (and access the Magic GUI again etc.).
Does this mean you're cheating and pretending an OBJECT is in fact EGO?
Posted: Wed Aug 15, 2007 12:36 pm
by Anonymous Game Creator 2
Yup, all the combat scenes are handled with objects, rather than characters.
Posted: Wed Aug 15, 2007 1:48 pm
by Erpy
Cheating sounds bad. I prefer the term "creative scripting".
Posted: Wed Aug 15, 2007 2:55 pm
by fluxmaster
It doesn't matter how you do it, so long as it works. AGS gives some methods and properties to characters and others to objects. Since you can't create classes freely as in C++, you simply pick whatever class works best in any given instance.
Think of it like a stunt man in a movie. The director says, "cut," and the main actor walks out on the set, but the camera keeps rolling, so you briefly see both the stunt man and the main actor on the set at the same time. Sort of like an outtake.
Posted: Thu Aug 16, 2007 12:07 pm
by Klytos
Erpy wrote:Cheating sounds bad. I prefer the term "creative scripting".
NOOOOOO!!!! Mean Nash!
Just having a go, I actually considered once that the best way to do combat in AGS would be with objects instead of characters. As long as it works, thats all that matters!
Posted: Sun Aug 19, 2007 7:33 am
by Ibanezrg82
What the hell are you talking about?
Objects instead of characters?
What the.....
Okay fine. We will have the Gyro, face off the evil wizard Ad Haggis.
A messy situation.
Posted: Sun Aug 19, 2007 10:19 am
by Erpy
If you have no experience with AGS scripting, then the object vs. character-stuff will make as much sense to you as that last line of your comment made to me.
Posted: Mon Aug 20, 2007 5:44 am
by Ibanezrg82
Understandable. Sorry about that.
Posted: Tue Aug 21, 2007 3:07 pm
by fluxmaster
Just out of curiosity, what is is about the Object class that makes it more suitable for animating combat than the Character class? Looking over the two classes, the Character class appears to be the more robust of the two, with over twice the number of methods and properties. The Object class appears to be a light-weight version of the Character class, for use with things that don't require a great deal of interactivity.
I've had the opposite experience. In writing my game, there were certain things that one would, in ordinary speach, describe as objects (since they are non-living), that I ended up implementing with the Character class, since the Object class didn't give me enough functionality to do it without writing a lot of extra code.
Posted: Tue Aug 21, 2007 4:21 pm
by Erpy
fluxmaster wrote:Just out of curiosity, what is is about the Object class that makes it more suitable for animating combat than the Character class? Looking over the two classes, the Character class appears to be the more robust of the two, with over twice the number of methods and properties. The Object class appears to be a light-weight version of the Character class, for use with things that don't require a great deal of interactivity.
I've had the opposite experience. In writing my game, there were certain things that one would, in ordinary speach, describe as objects (since they are non-living), that I ended up implementing with the Character class, since the Object class didn't give me enough functionality to do it without writing a lot of extra code.
A few things:
1) The fact that it's anchored by its bottom-left corner by default instead of by the center. This made it a lot easier to display graphics without them jumping around because of varying width. (when the combat system was first made, I'm not even sure if SetCharacterViewEx already existed)
2) The ability to directly change the graphic of an object without having to assign a view to it first and the ability to directly read an object's graphic.
3) The ability to directly change the position of an object with one command instead of two.
The battle system doesn't do a whole lot more with objects than set or read their graphic, set or read their position and on a few occasions, turn them on/off or set their baseline/transparency, so we didn't need the additional functions of the character class.
Posted: Tue Aug 21, 2007 5:59 pm
by fluxmaster
Erpy wrote:[An Object is] anchored by its bottom-left corner by default instead of by the center. This made it a lot easier to display graphics without them jumping around because of varying width. (when the combat system was first made, I'm not even sure if SetCharacterViewEx already existed)
Oh, you just gave me a great idea! I was having trouble in my game because I was using Objects but needed to have them anchored on the
right. I had to calculate meticulously the number of pixels to shift the object when changing the view to one of a significantly greater width, then figure out a way to do it without making the object appear to jump around the screen. Now I can just change it to use Characters and use LockViewAligned() (the replacement for SetCharacterViewEx() ) and specify eAlignRight as the third parameter.
Sorry if this is going off topic.
Posted: Tue Aug 21, 2007 6:17 pm
by Orion
fluxmaster wrote:Erpy wrote:[An Object is] anchored by its bottom-left corner by default instead of by the center. This made it a lot easier to display graphics without them jumping around because of varying width. (when the combat system was first made, I'm not even sure if SetCharacterViewEx already existed)
Oh, you just gave me a great idea! I was having trouble in my game because I was using Objects but needed to have them anchored on the
right. I had to calculate meticulously the number of pixels to shift the object when changing the view to one of a significantly greater width, then figure out a way to do it without making the object appear to jump around the screen. Now I can just change it to use Characters and use LockViewAligned() (the replacement for SetCharacterViewEx() ) and specify eAlignRight as the third parameter.
Sorry if this is going off topic.
English, please?
Posted: Tue Aug 21, 2007 7:39 pm
by fluxmaster
Well, basically, in filming a combat scene, you can use either human actors or robots. Erpy says robots are better because
1. Robots are easier to position than actors. Actors always want to be positioned so that their best side is facing the camera. Robots aren't so particular.
2. Robots can do stunts better than actors. Actors can only do the stunts that they've learned in acting school. Robots can do whatever stunts you tell them, and they'll do them right on the spot, without rehearsing them beforehand.
3. Robots can move around faster than actors. With an actor, you have to tell him twice before he'll move to a new position on the set, because he's not sure exactly where you want to place him. A robot will move to the correct position on the set with only one command.
What this all did is give me a great idea for my own game. In my own game, I was using wooden props for trees. But, after reading what Erpy wrote, I realized that it would be better to use human actors dressed up in tree costumes. That way, when the trees are cut down, they will fall down in the right way and not mess up the scene.