Messages

Dropped off a follower

Spoiler

I took Kendra back to her dad's place.  Joey and Rosa both tell me I am supposed to check on her, but I can't seem to enter the building.  The door is locked and I get no response when I use the buzzer.  Joey says the 5th floor is out of range. Nor can I gain access to the fire escape--Joey isn't interested in the alley, and the gate is locked.  The walkthrough I found said I was just supposed to follow Kendra and doesn't mention any puzzles to get back in.  Is this a bug or is there another way in?

[close]

Last Chapter:

Spoiler

Tied to a rock, troll and varg are dealt with but don't seem to be able to do anything.

[close]

This is beautiful.  I really enjoyed A Tale of Two Kingdoms and Quest for Glory is still one of my favorite adventure game series.  I think if anyone can pull this off, you guys can.

I just watched the voice acting preview and the voices are pretty good, but the animations were totally out of sink with the voices, which broke immersion for me pretty bad.  Will this be fixed in the finished product?  I hate nitpicking about this since everything else about this looks so great.

I'm not seeing the advantage of pixelation with your art style.  It mostly just makes your backgrounds look slightly less good.  I'm with Ghost, if I read him right.  Do the sprites in a style that is sort of sketchy, in the way your backgrounds are.  More traditional game sprites (even cartoony ones) are probably going to look out of place.

I like the general look.  Good use of contrast/lighting that is often neglected in in sketchier cartoons.  Though some areas look a little flat, still.  Not a good enough artist myself to tell you how to fix that.

EDIT: The use of thick, fuzzy outlines is the thing that looks the worst in the low resolution, I think.

Step 1: Get an idea while you are in high school.  It's pretty epic.

Step 2: Think about it for 1 (one) decade, until it ceases to resemble itself.  This is for the best; you weren't as original as you thought you were, in high school.  But now it's even more epic.

Step 2a: In the meantime, take introductory classes in everything at community college, except the subjects that might lead to a career outside academia.  This information will help...somehow.  Try to avoid thinking about opportunity cost.

Step 3: Start coding a new and complicated interface that is going to be awesome.  Stop when the code is getting too convoluted for you to keep track of anymore.

Step 4: Spend several days making some sprites.

Step 4a: Now for some walking animations!

Step 4b: This is time consuming and boring.

Step 5: Make a detailed plan complete with mini deadlines that you can complete by the end of the summer.

Step 6: It's time to start world building, but don't go into too much depth here - just the bare minimum so it looks like your game is taking place in a place.  You will fill in the rest later.

Step 7: Come up with a name for one of your secondary characters.

Step 8: None of these sound good.  Construct a language from scratch so you give your secondary character a name with some sort of logic behind it.

Step 8a: Start with the phonemes.  Those are important.

Step 8b: Now move onto basic morphology.  Consider doing something with gender and case.

Step 8c, d, e, f...  But it is all so fascinating.

Step 9: Summer is over and now you have schoolwork to do, but maybe if you stay on top of things you can work a little in the evening.

Step 10: Great!  Finally a free moment.  Time to watch television on the internet.

Step 10a: If inspiration does hit, consider starting over on those sprites.  They look a little off in retrospect.

Step 11: Repeat.

EDIT: But I did complete the Secret Santa Generator.  That's something, right?

Hard to place, but you haven't made me believe in the shadow under the edge of the ledge leading to the cave.  Is there an overhang there or something?

I really like this picture, though.  Especially the pool.

I think the only reason to do 1 is if you have it synced to music or some other time related thing, but that doesn't actually save it from being annoying.  You need to make the player believe that it has to be that way to do what you are trying to do.  Easier in talky games, probably.  I agree that being able to skip the whole scene is a decent compromise here.

I am a slow reader and miss a lot when text goes too fast, so I always tend to default to 2.  If 3 is slow enough that I can comfortably read it every time, odds are half the time I will be treating it like 2, anyway.  I don't know what to say about what should be the default, but I think 2 should always be an option.

I would make a struct for character stats and a struct array for enemy stats.  Or if you want to make something more flexible just make one struct array for all of the above.  All the stats you want will just be variables in the structs  Using stats to solve puzzles is pretty simple.  Just do what Khris said.  How to do stat progression and how to have character and monster stats interact in battle and so on are going to be a bit more complicated and will depend somewhat on the specifics of what you want the game to play like.    Though for something along the lines of Quest for Glory, you probably don'r need anything super complicated/well developed.

For battles basically what you need to do is have the game figure out whether the hit connects, and then how much damage it should do.  Take the damage off of the health, and then check to see if anyone is supposed to be dead yet.  Might be worth looking at some other game systems for stuff like that.  The biggest questions you'll have to decide are: Can characters and/or enemies move freely in battle?  Are battles real time or turn based (or some combo like Final Fantasy's ATB or whatever it is they do in KotOR, Dragon Age)?  Can there be more than one combatant on either side?  Do battles take place in a separate screen or in the normal gameplay world, and does battle constitute a different mode than normal gameplay?

1 on 1 turn based battles with no character movement that take place in a separate screen/game mode are going to probably be the easiest to program.  The way the first Quest for Glories do it which is basically that except real time shouldn't be that much harder--just need some timers thrown in.

For Quest for Glory style state progression you might want to give each of the stats separate variable (hidden or not) for "experience till next level."  Have certain actions/events in game or in battle take however many points off of that variable.  Then when it reaches a value equal to or less than zero make the stat go up by 1 and add some value to EXP till Next value like "(stat) * 100" or "100 + 2^(stat/2)" or whatever equation makes for the smoothest/most reasonable increase.  Keep running the check and repeating the process (via a while loop) until EXP Till Next is greater than 0 again.  The idea here is that each level for the stat becomes harder to attain than the last, but also some action which give a lot of experience with that stat/skill have a chance of making it go up more than once in one go.  This is just one way to do this.  You could do something with increasingly difficult probabilities, for instance, or you could employ a more standard level up system where all the stats have a chance to go up when the character  levels.  Or you could just hardcode stat increases like "climbing the tree ten times increases climbing by 1" or something like that.

These are just ideas and I haven't put anything in script form for you.  It sounds like you have some programming experience, so I would read up on how AGS handles structs and arrays in the manual and then kind of fiddle around from there until you figure out what you are doing.

That's more or less right.  I probably wouldn't take the actions away unless it would be immersion/world/story breaking to have the player do them again, but they'd be greyed out or something.  The effect would be pretty much the same.

This is sort of specific question that might have more general applications, but it pertains to a game I'm working on.  Wasn't sure if it would be better to post here or Adventure Talk and Chat.  Feel free to move.

Basically, I am making a game that features Context Menu GUI.  Clicking will perform a default action, while clicking and dragging will bring up a list of all the actions that can be performed on an object/character/hotspot (some things can be taken, pushes, talked to, some things can't, etc.).  Separate submenus for conversations and actions involving inventory items (haven't decided yet how to handle using inventory items on eachother.  Perhaps I will have huge a list of all possible options come up under the inventory submenu you can access by clicking on the main character, or maybe I'll make a separate inventory screen like in other games--input on this appreciated).  Right click walks.

For people who don't like novel interfaces or whose mouses don't click and drag well, I intend to include a Windows Mode that will perform the same actions but behave more like windows, with right clicks bringing up a menu whose options can be selected with an additional left click, double clicks for default actions, and single left-click to walk.

There may also be abbreviated versions of the system that come up when having the player walk around or perform certain actions would break the story.  And I was thinking I would allow use of the mousewheel to cycle through the default options, though I'm not sure if that would be worth it.  Mostly, I just want to minimize as many of the inefficiencies in the verb-coin/pop-up menu style of interface as I can, without sacrificing the flexibility of the context menu.

I made a test game a while back with a sort of proof of concept version of this GUI.  I found myself sort of naturally designing a lot of puzzles that involved selecting the same options multiple times, for different responses, and something also the discovery of new interaction options.  It seemed to flow naturally, but the problem was it was obvious to me that players who could not read my mind would probably not be able to guess when selecting the same option more than once would yield new results and when it would not.

My best idea so far to get around this, aside from simply avoiding that type of puzzle, is to highlight options that haven't been tried yet, including ones that have been tried but haven't been exhausted.  Options that will not yield new results would then be some other, less eye-catching color, though still selectable for players who want recaps, where such makes sense.  If actions elsewhere in the world make it so a previously exhausted action will yield new results, it will light up again.  I might even do something to the mouse-over graphic to indicate when a hotspot has actions that haven't been tried yet, to save players time.

The one problem I see with this system is it seems to undermine a certain type of puzzle.  Namely, timing puzzles and other puzzles that rely heavily on the circumstances under which an action is performed but not the action itself.  Take the classic puzzle where a character looks away briefly allowing you to pocket some small item that they don't want you to take.  If the option to take that item instantly lights up when they look away, that gives away the solution to the (in this case really obvious anyway) puzzle.  It makes the puzzle easy for the wrong sort of reason, and the whole point of that type of puzzle is that it creates an alternative to the "Just click all the options" puzzle solving that I think this GUI system may already lends itself to.

One thing I thought might be a good workaround is to make a distinction between new variations or continuations of an action vs. new results from the exact same action performed under different circumstances.  If you've already tried to take the item, the TAKE ITEM option won't light up again just because its owner looks away, since both times you are attempting the exact same thing, but you will still get a new result.  By contrast, if you are supposed to push the same statue three times to knock it over, it will stay lit up after the first push, because the player and player character would reasonably see themselves as continuing the first push, or trying again, but harder. Since there is a logic to the distinction, and the player should be paying attention anyway, it doesn't seem unfair.  But I worry that the distinction won't be obvious enough, and players will think I'm just using the highlighting system to trick them into  thinking the real solution won't work.

My thinking is perhaps if I could communicate this distinction between, say, action and context early on in the game, then it might not be as much of a problem.  But I'm not sure how best to do that without relying on outside texts or egregious fourth-wall breaking.  But would this be enough?

The third option I suppose would be to have a third color for actions for which new attempts may or may not yield new results, so that players would know to keep trying them, but not when.  This has the advantage of not relying on the player picking up abstract conceptual distinctions but I worry it would still give away too much.

I'd love to hear thoughts on this specific quandary and the one about handling inventories.  I'd also love to hear feedback on the interface as a whole.  Any drawbacks or advantages I might have overlooked.  I know this is in the critics lounge, but I wouldn't at all be upset if it developed into a general discussion of Context GUIS.  As I said, I wasn't sure if I should put it in Adventure General.

If anyone wants to see it, I could also post the proof of concept.  Though it has some kinks and I haven't worked on it in a while.

Hope it's not too late to post in this thread.

In my experience a lot of endings in games feel a bit lackluster.  Maybe I "spoiled" myself as a teenager playing triple A JRPGs with their flashy three hour boss battles followed by 40 minutes of FMVs and dialogue showcasing the fates of everyone and their mom, as it were.  Not that I want that for Adventure Games (or RPGs for that matter, although sometimes it worked pretty well).  Too many games, though--especially Indie adventures--end rather abruptly.  A tiny bit of post-climactic dialogue, some narration summarizing the fates of the characters, maybe a little slideshow if we are lucky.  Sometimes this is what is called for.  Adventure games tend to be fairly short with small casts, and don't necessarily call for a lot of denouement (i.e. winding down).  Still I think endings are important.  It's what you are leaving the player with, after all.  I'd like to see them treated with as much care and enthusiasm as any other key element.  I don't like parroting the "show don't tell" mantra, but I think it's relevant here.  Give us some more scenes.  Maybe some playable bits, even.

In my experience games (especially Indie games) with multiple endings tend also to be the games whose endings are the most spartan.  Obviously, there's a good reason for this.  Optional content is more work and well integrated optional content with real consequences is A LOT more work.  The result is that multiple endings tend to detract from each other, unless people are willing and able to put in a lot of extra hours.

I loved the Vacuum, and I think it's a great example of nonlinearity done right on a budget, but it definitely suffers from this.  So do Ben Jordan, A Tale of Two Kingdoms, and Primordia, in my opinion.  It happens in commercial games, too.  I was underwhelmed with Indigo Prophecy's endings, relative to the spectacle that was the rest of the game.

(I actually think it sort of worked in Resonance, though.)

I think in many ways multiple endings actually work better when they are an afterthought.  A game with one satisfying ending can become a game with one satisfying ending PLUS a few frivolous nods to optional puzzle solutions (like Secret of Monkey Island) or a game with one satisfying ending PLUS a few "failure," "what if," or "opt-out-early" endings for kicks.  I rarely feel like these really detract from the overall experience (although arguably the climax may not be the best place for them).  It's sort of like playing King's Quest games to collect the cute death animations.  I felt like the JRPG Chrono Trigger accomplished this fairly successfully (on replaying, you could challenge the main boss at different points in the story for a number of brief, sort of quirky endings that fit loosely with the game's time travel theme, but there was one really complete ending that you got for playing the whole story plus the major end-game sidequests, though it had some variations as well).

Obviously neither of those fulfills the full promise of a game with "multiple endings" or "real consequences for your choices."  For creators of those types of games, I recognize the choice between somewhat lackluster endings or putting in exponentially more work on an already complex product is not an easy one, and I certainly don't want to see these works disappear from the indie adventure scene.  But for games with a strong, more or less linear story focus, I think extra endings should be developed only inasmuch as they do not detract from the main ending.

Some scattered thoughts:

Not sure this is really an ethical issue.  Maybe if it was a commercial game that you were going out of your way to market as new and innovative and then the vast majority of puzzles were repeats of ones from your earlier released games?  That could feel like a bit of a rip-off.

That said, there is an aesthetic issue.  You don't want to reuse material so much you get predictable--especially with something like puzzles where half the fun is figuring them out.  The ten years old thing helps, because people who play your new game are less likely to have played the old ones (especially recently), but if they enjoy your new game, some of them might be more inclined check out your earlier titles, so if they are still available online, people might still find the old puzzles.  Some people might feel retroactively ripped off.  More people will probably just feel clever, though, like they've discovered a special little secret.

If the puzzle was especially clever or memorable when you made it the first time, you might risk undermining the artistic integrity of the earlier work.  Depending on how much you still care about the original, that might matter, or it might not.

On the other hand, with some subtle (or for that matter not so subtle) lampshading you might be able to get away with reusing the puzzle as a nod (or even a thematic allusion) to an earlier work.

Most adventure game puzzles are fairly derivative anyway.  Depending on the focus of the game, this can be entirely forgivable.

Sometimes when people reuse tropes and content it feels like branding or continuity building.  Other times it just looks lazy.  If you reuse a puzzle try to make sure you know exactly why you are doing it.  Own the thing.  Or re-own it.  Don't do it too often, and most likely people won't notice or care, and a few might even like you for it.

Hey awesome.  I ranked!  Good round, everyone.

Whatever happened to this poor fellow, he didn't see it coming until it was too late.

The Wizard?

Interesting.

It wouldn't be difficult to add a function to number and scramble the Santa list, anonymously or otherwise, for purposes of a White Elephant.  Is anonymity of order actually important in White Elephant, though?  Since it doesn't matter who draws what number in a fair game of White Elephant, and since you don't need to know who you are shopping for in advance, the only advantage I see of using a program like this over a hat drawing is if a) the White Elephant is being played long distance (as it is easy to keep number drawing anonymous when people draw for themselves) AND b) you don't want people to know the order of turns (because otherwise even at long distance a participant with a dual role as a coordinator can easily draw numbers for every one else and just post the list).

Since it would be so simple to add such a feature, I wouldn't mind doing it, but I would like to know that people would actually use it.  Otherwise I might anyway for completeness sake, but it'll be a low priority.

Snake -  Thanks.  Well, it's good your people are on top of things, anyway!

Ponch - Awesome.  Let me know how it goes.


Also.
I'm 99.9% positive that the way I coded this means that any errors still present will not ruin Christmas (that is to say, I am quite certain that everyone always gets presents), but if anyone discovers otherwise through use of the program or by fiddling with the source code, I would greatly appreciate hearing about it.  These things are very important.

Hey everyone.  I whipped this up for my own family Christmas celebration this year and thought I would tidy it up and share it.


The Secret Santa Generator


The Secret Santa Generator is a simple, free application designed to generate a list of Secret Santas without revealing who is getting gifts for whom.  Think of it as drawing names from a hat.  Just input a list of everyone participating in your Secret Santa gift exchange, and the Secret Santa Generator will create a simple .txt file for each of the Santas, telling them who they are going to get gifts for.  This has a few key advantages over the age old hat drawing system:

* The Secret Santa Generator works without every participant having to be present for the drawing.  Are your friends and family scattered throughout the country or even the world?  Do busy schedules make it near impossible to get everyone in the same place at the same time?  Just use e-mail, instant messengers, or social networking services to send each of the Santas the .txt file with their name on it.  As long as you don't look in the files you won't know who is getting what for whom.  No need to involve an objective third party to draw names for you.  The corollary of course is that whoever is running the generator has to be someone who can be trusted not to peek.

* The Secret Santa Generator is faster.  When you draw from a hat, there is always the possibility that someone will draw their own name and then you will need to start the whole process over again.  However, the Secret Santa Generator can run up to 1000 drawings in a fraction of the time, and it will never let any Santa draw themselves.

* The Secret Santa Generator's special Rules feature allows you to control who can be a Santa for whom.  Don't want couples drawing each other?  Worried about personal grudges landing someone with a crappy gift?  Want to play favorites and rig things so you can get gifts for someone you really like?  You can do all these things by making Rules that tell the Secret Santa Generator not to allow certain people to be Santas for each other.  Use your own discretion.  This is of course another reason why running the generator is a responsibility best left to trustworthy individuals.


You can download the Secret Santa Generator at the  Game Page.  Note: Don't extract it to Program files or anywhere that requires special permissions to create or edit files, or the .txt generating function won't work.

Instructions are available in the ReadMe.

You can also get the source code here here.  Be warned, though: it is fairly simple, but there aren't many notes.

Enjoy the holidays.

Brainstorm.

Have a line at the bottom of the screen that says what action you are going to do (like in Lucas Arts games).  If the teeth are held over a human character, change the label to something like

"Talk" to scientist

With "talk" in quotation marks.  But when you click, Merrick will just bite the guy.  Sort of lampshade the icon ambiguity.

I don't know if there is room for random, non-time substantive brainstorms in this project, but:

If we're going with the vampire and probe idea, perhaps there could be some rooms that use artificial, non-UV lighting that allow both the probe and the vampire to move freely, though perhaps both experience sub-par functionality in these rooms.  There could even be a puzzle where the vampire has to figure out that the light is safe before entering it.