Topics

Every so often somebody takes a straw poll on their favorite interfaces, and it's my opinion that usually there are only two conclusions to be drawn from them.

1.  People generally don't like to be slowed down by verb-coins, but tolerate them for their favourite stories.
2.  There is no consensus about the rest.

Having my fingers lightly rapped for using a two-verb verbcoin last time, I'm now tempted to build a game around the good ol' 9-verb interface, or maybe a 6-verb variant (Open/Close merged, Push/Pull merged, Give removed).  It'll obviously allow for more complex and creative interactions, though at the expense of crowding the screen a little.  Although I'll miss having object/character names appear over the cursor, rather than in a fixed textbox, but this would proclude a description of the exact action being undertaken.  "Am I USING, TALKING, OPENING, or what?"

But before going this way, I'm wondering, is anyone sick of the 9-verb interface yet?  Is the 9-verb interface going to chase anyone away from playing a game?  And flipping the question around, do your expections on size and scope change when playing a game with a two-verb interface (look/interact), as there is, overall, just less to see and do in any given room?

[Project:]

Project:

Form 41:  A whimsical adventure into the depths of bureaucracy to reclaim one's misplaced life.

Details:

Okay, bear with me here.  I started this project about a year ago, kept it quiet for the most part, and got a fair bit done with it until it became clear that certain design choices that seemed clever at the time were very poor ones.  Had I consulted with others earlier, I wouldn't have succumbed to classic tunnel-vision, and had to scrap months of work.  I took a break from game-design in order to work on some other small projects, but after this long hiatus I'm finally ready to dust this one off again and see if anyone wants to help out.

The story is written and the puzzles are worked out, though plenty of flexibility exists on both fronts to any fresh ideas.

The story tells of an Eastern European immigrant who wakes to find his life turned upside down because a government error has him accidentally declared legally dead.  He must use puzzle-solving to navigate the frustration people experience in banks, doctor's offices, post offices, airports, etc.  Unlike my last game, death will be very possible, so players should be encouraged to save often and pay close attention...crossing the street against the lights, for example, will result in your being flattened.  The player must also manage their "stress level".  As our protagonist gets more anxious about his situation and limited English skills, dialog options become more elusive.  Too much stress, and he might have a full-blown freakout and need to be arrested.  The player can always drink to "reduce stress", but as he gets more drunk, may react to events in unpredictable ways (and be denied certain services)! 

In addition to the writing and design documentation that has been done, I have some scripting experience, access to a high-quality recording studio, all of legacy materials of the first iteration of this game, and the experience of the lessons learned from Last Flight of the Starship Hindenburg.

Positions Available:

I'm absolutely willing to collaborate with anyone who is willing to stay with this for a while, but the skills that this project really needs are an artist (art has always been the major bottleneck for me, and I've never been satisfied with the results) and the support of a patient and more experienced programmer.  If nobody is interested in this, then I'll probably shelf the idea for a while and work on a different AGS project.

Comments:

Interested parties can reply to this thread or contact me via PM.

Of all the thirty-or-so backgrounds I've done so far, I like this one the least, but can't put my finger on what to do differently.

I've got the feeling that the bricks are too well-defined?  The game is mostly played in 2D, except when you go to the city map, which is a detailed isometric drawing.  The building in question is a more-or-less unremarkable government building (I've removed the sign because...well...spoilers).

I'd love some pointers on how this could be improved upon.  The iso building it's based upon is below.



Thanks, in advance,

KB

http://kotaku.com/5880215/what-the-video-game-vendor-selling-hot-dogs-knows-about-life

Is anyone aware of anything that can cause a crash without any explanation or AGS-specific error message when running a dialog (with a fair amount of code embedded within)?

I want to trace the root of the problem, but this particular dialog happens to also be a rather complex puzzle and it may take some time to root it out.  I'm without any hints as to the cause of the crash.

I'm soliciting for opinions.  My current title calls for somewhere close to 50, most of which perform a single function, like working at a store, or waiting in a lineup.  Is this extraordinarily high?  They not particularly large or detailed, so it's (barely) managable from an artistic standpoint, but I'm wondering if this will have a demonstrable impact on game size or performance.

Grateful for your thoughts.

KB

I find good puzzle-design to be more challenging than the art or programming, and I'm conflicted as to whether the solution to an early-game puzzle in my current project is logical, or needs a re-think.

Drop me a PM if you've got the time to offer some advice!

Cheers.

KB.

I've been at this for far too long and I'm likely missing something obvious.  A fresh set of eyes would be much appreciated.

Coding a traffic light at a 4-way intersection (EW and NS).  The lights cycle as all traffic lights do.  Not concerned with the interval between the lights, that's easily altered.  Just want to see the transitions work.

I have unique traffic light sprites in 133 to 137.
I have a single object, otrafficlights1, that is currently set to Graphic 133.


I'm using the following code in the room:

Code: ags

function room_RepExec()
{
//starts with EW - Green and NS - Red
SetTimer(1, 20);

if (IsTimerExpired(1)){
  otrafficlights1.Graphic=134; // EW - Yellow, NS - Red
  SetTimer(2, 20);
}
  else if (IsTimerExpired(2)){
  otrafficlights1.Graphic=135; // EW - Red, NS - Red
  SetTimer(3, 20);
  }  
  else if (IsTimerExpired(3)){
  otrafficlights1.Graphic=136; // EW - Red, NS - Green
  SetTimer(4, 20);
  }  
  else if (IsTimerExpired(4)){
  otrafficlights1.Graphic=137; // EW - Red, NS - Yellow
  SetTimer(5, 20);
  }  
  else if (IsTimerExpired(5)){
  otrafficlights1.Graphic=135; // EW - Red, NS - Red
  SetTimer(6, 20);
  }  
  else if (IsTimerExpired(6)){
  otrafficlights1.Graphic=133; // Back to EW - Green, NS - Red
  SetTimer(1, 20);
  }  

Any ideas why the lights aren't changing at all?

Thanks, in advance,

KB

I'm frustrated because most AGS games, when the option for "side borders on widescreen monitors" is selected in the setup, do exactly that in the game.

My game(s), when compiled, and the option is selected in the setup, simply ignore it.

Does anyone have any bright ideas on what I may be doing wrong?  Is there more to it than just making adjustments in the setup?

Thanks, in advance,

KB

Just discovered this.  http://www.amazon.ca/Adventure-Game-Studio-Including-Interactive/dp/1242542868/ref=sr_1_1?ie=UTF8&qid=1320100016&sr=8-1

Does anyone know anything about this and can provide comments?

Simple lowball question for you all, not covered in the manual --

Is there any way that a GUI Background Color can be changed in the script?  I can't seem to find the appropriate command.

For clarification,

How is it that some AGS games look fine on my 16:9 widescreen monitor, and others look stretched?

I was thinking that if I make a game in 640x400, the game would look okay on 16:10 monitors, but stretched on a 16:9.  It's alright, I guess.  If I was to make the same game in 640x480, it would look like crap on any widescreen.  Nothing I do in winsetup seems to make any difference to any of the setups, and I'm running the latest drivers, so I can't anticipate that anyone downloading the game will have any more luck that I am.

How have others got around this problem?

Discuss!

It's a common thing in AGS games, but it's kicking my a** right now.

Game will be a two-button, one-click interface.  I just want the @OVERHOTSPOT@ label to be present over the object/hotspot, rather than a fixed location.

A lot of topics on this, but consensus appears to be to use SSH's Description v1.06 Module.

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=41265.0

I was hoping it would be beginner-friendly, but I'm getting nowhere with it.  I'm not sure if it's because I'm thick or the module is complex, but after staring at the code for a couple hours, I still have no idea how it works or where to go from here to get it running.
 
Is there an easier way to accomplish the same goals?  Or is anyone familiar enough with this script that they could tell me how to "switch it on"?

I'm using the Grid Inventory Module as a starting point for a new game.

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=28177.0

I wasn't bright enough to get it working from the module itself, so I tried adapting the demo instead in order to understand how it works through ablation.

In the demo, there are two inventory grids.  I only need the one, so I started by trimming all references to gInventory2 and DeathInv, while preserving the if-statement logic.  When I do that, line 386 on Module0 crashes the game.

Code: ags

InventoryItem* GridInventory::GetAtScreenXY(int x, int y) {
  GUI *pg = this.pInvWin.OwningGUI;
  int X = this.pInvWin.X + pg.X;
  int Y = this.pInvWin.X + pg.Y;
  
  String id;
  
  if (pg.Visible && this.pInvWin.Visible && this.pInvWin.Enabled && this.pInvWin.Clickable) {
		if (x >= X && x < X + this.pInvWin.Width && y >= Y && y < Y + this.pInvWin.Height) {
		  
		  int pos = (x - X) / this.pInvWin.ItemWidth + ((y - Y) / this.pInvWin.ItemHeight) * this.pInvWin.ItemsPerRow;
		  
		  id = this.itemId.Substring(pos * 3, 3);
		  		  
		  if (id.AsInt)
				return inventory[id.AsInt];
		}
	}
	
	return null;	
}

Can't for the life of me figure out what that section does.  I'm probably in over my head.

Does anybody have experience with this module, or any other grid-inventory module, that can offer guidance towards its clean implementation?

I'd really like some feedback on how the future protagonist of my next game can be improved.

I wanted to try going for something minimalist, where the player character takes up a very small space of the overall environment, not unlike what Gepard is doing for N.orth S.outh E.ast W.est.  

Oleg, featured below, emigrated to the United States from Eastern Europe, and worked part-time as a plumber before losing his job.

Do you believe there is a preferred interface-design, and if so, why?

My last game was a two-verb coin: "Look" and "Interact".  I was contemplating going further in my next title to have object interactions and observations to be one and the same verb, moving from a verb-coin to a one-click-does-all design.  I'm worried that this might limit the depth of some of the puzzles to pixel-hunts, which seems to turn off a lot of the adventure-game crowd, which is small-enough as it is.

Your thoughts?

Probably biting off more than I can chew, but is it technically possible to create a game that creates a "fog-of-war" whereby a player can only see a few feet in front of their face, and uncovers incrementally more and more of their environment as they explore?

If so, any bright ideas as to how one would go about such a thing?

Apologies if this is a repeat post...I wouldn't know without being about to use the search function...

I've hit a mental block and a coffee shortage, so I could use a fresh set of eyes.

You've got a team of 3 to 6 people.
If a randomly generated "sickness event" occurs, a new random number is generated between 0 and whatever the team size is.  The team member assigned to that number "gets sick".

Big whoop.

Now what I want is to show the effects of a contagion.  So if any team member gets sick, the chances of additional team members getting sick increases.  I've done this by changing the likelihood of a "sickness event" occurring.  Problem is, I don't want the SAME team member getting sick again, only new ones.  How would you go about coding this so you're not dealing with a ton of superfluous variables?

I'm sure it's straightforward, but I can't seem to dream up anything elegant...