Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Snarky

Pages: [1] 2 3 ... 197
Resistance and Dune (and a fierce determination to force persuade someone to play it).

The Rumpus Room / Re: *Guess the Movie Title*
« on: 02 Aug 2015, 09:58 »
Ben X got it: Event Horizon.

The Rumpus Room / Re: *Guess the Movie Title*
« on: 02 Aug 2015, 00:30 »
Let's see, then:

The Rumpus Room / Re: *Guess the Movie Title*
« on: 01 Aug 2015, 22:09 »
Dark City?

Oh Kenneth, I'm disappointed in you...

<a href="" target="_blank" class="new_win"></a>

For the record, I'm up for bathing in whatever body of water we may find or create.

Swim the Mississippi?

The closest public pool seems to be the John P. Lyons Center (624 Louisiana Ave, New Orleans, LA 70115).

On a side note, I would like to point out that this thread was completely derailed from original topic... where is mods looking... (roll).

I think we mods tend to deal with thread derailment differently depending on context. Sometimes we shut it down, sometimes split it off into a new thread, and sometimes just allow the conversation to take whatever turn it takes. There's no hard-and-fast rule, just what seems best on a case-by-case basis. In this case the original topic seemed to be more or less concluded, but if you as the thread starter don't like the drift in topic, we can split off the later posts.

No offense to Mods, but I have a few concerns about the home page plans.

1. If it means making the AGS site design more like the Screen 7 design in some ways, I'm not convinced that's a step forward.
2. If we want to make fundraising more central to the site (and I'm not convinced that's a good idea in the first place, since I think it makes more sense to raise money within the community, and therefore on the forums), we really need to clarify who will be managing the money, distributing it, and how they will be held accountable for it. (Of course, we should do that anyway, if we start raising significant sums.)
3. I think a redesign of the AGS homepage should only be undertaken along with a redesign of the whole site. Whether this is a good idea depends on a) the visual redesign, b) the information structure redesign, and c) the quality of implementation. To approve a redesign without knowing any of these things seems precipitate.
4. Various disagreements about the plans for the engine, and with tying the webpage so closely to a not-yet-existing version rather than to all AGS actually has to offer.

Adding more "live" refreshes of the home page is a good idea in principle. Of course, part of the problem with it has typically been that people for various reasons stop updating (whether it's a blog or game of the month or whatever), and then you need to find someone to take it over, or you're stuck with outdated "live" content that makes the site seem abandoned. Perhaps Mods is the right person to ensure this doesn't happen. But it might also be good to rely more on auto-updating stuff, like e.g. displaying recent tweets with "adventuregamestudio" in them.

I would wholeheartedly donate monies your way.In fact I'm sure that the community could rally behind Snarky's suggestion.

Wasn't really my suggestion, but if CW wants to devote a few months to AGS I would certainly chip in. Would be good news for the engine!

I understand your reluctance to "make any plans on payment", CW, but maybe if you think of it more as a stipend that would enable you to devote the time to it, not as a salary or contract that comes with an expectation of specific deliverables? No telling how much we'd raise, anyway, but it would be at least some compensation.

Where did they state that? I think it's still pretty open water. I know one of the devs probably wouldn't say no to being paid to fix things. And CW's quote above

In general, I think it is safer to assume that AGS will never be fixed. Fixing its core flaws requires a lot of time to plan and design. Some of these would require to just rewrite half of the engine maybe. It all requires time, and not just total summed up time, but a period of time when a person can focus on the task from start to finish without anything else distracting him for several months.
Otherwise, it will be limited to small changes here and there, as we do now.

is literally screaming "budget = this could happen". It wouldn't be particularly hard to raise someone 20,000 to take 3 months off to re-write AGS from the ground up (or whatever is needed/necessary, you can't just say it won't work/happen without exploring it!)

Crimson Wizard in particular explicitly said no to being paid here:

Of course, if there's a developer who's familiar with the AGS codebase, who has some ideas for things to fix, who is a proven coder we can trust, and who would be willing to devote their full-time efforts to it for a few months, then sure, it's worth giving it a go. I'm not sure it would actually be that easy to raise 20,000 (GBP? USD? EUR?), but if someone wants to have a go at it, nobody's stopping you.

If the devs don't have the time to implement the features, offering some cash doesn't really help. You can't assume someone is willing to give up their job to live off community donations.

The Rumpus Room / Re: *Guess the Movie Title*
« on: 30 Jul 2015, 17:33 »
Isn't that Rachel Weisz again? Uh, Dream House?

This, combined with a small wizard meant for the player ("in your saved game, have you spoken to the merhant? Yes/No"), would be a workaround to "recreating" lost game progress after applying a patch.

Mmm, that seems unnecessary. If you're storing game state in your own, custom format, you can just ensure that updates/patches are backwards compatible, able to read and restore old savegames.

(The explicit answer to your question is at the end, but if you feel in over your head, this explanation might help.)

It's not actually particularly difficult, it's just that there's no built-in support for it, so you have to write it all yourself, and computer programming is fiddly. It's a little surprising that no one has made a module for it, but slider puzzles have a pretty bad reputation among many adventure fans, so that could be why.

If you're happy having the puzzle as a room, I would probably just put all the code in the room script.

To approach a task like this, it's often useful to break it down into a few questions or steps:

Q0. How do you actually want it to work, in detail? Particular requirements might affect the best way to write it.

-Is the empty slot (in the solved puzzle) in a particular position, e.g. the last slot?
-Is this definitely just one puzzle, or is it possible that you'll have several different slider puzzles in the game?
-Is the puzzle fixed in a particular location in the game, or is it something the player carries around with them and can attempt anywhere?
-Do you want animations (pieces sliding), or is it OK for them to just jump from one slot to another?
-Do you want to move pieces by clicking on them (easy), or actually have players use drag-and-drop gestures to slide them themselves (harder)?
-Do you want to be able to slide multiple pieces together? (Hardly necessary in a 3x3 puzzle, I'd think.)
-If players leave and come back, should the puzzle remain as they left it, or reset?
-Does the puzzle always start in the same state, or should it be randomized each time?

(Most of these don't make a huge difference to this particular approach, but some answers might require a different solution.)

Q1. How can we get AGS to display what we want and respond to relevant user actions? (In this case, display tiles in different arrangements, and move them when clicked.)

A. Several possibilities, including making the tiles room objects, or buttons on a GUI. In each case, the interaction is most easily handled by using the OnClick event. (This implies that the code starts out knowing which tile was clicked, but not automatically which slot it is in.)

Q2. What do we need to keep track of to make the logic of the puzzle work? What datastructures do we need?

A. Basically, we just need to know the arrangement of the tiles. A plain array of tile indexes (whether as ints or pointers to the objects or buttons) will do fine. Also, while not strictly necessary, it simplifies things a bit to explicitly keep track of the empty slot.

Q3. What are the tasks we need to be able to perform in the puzzle? What are the things we need to be able to deal with?

A. Here are some useful features we need to make a slider puzzle:
-Set up the puzzle in some arrangement; usually this is handled by a function called init()
-You might want to be able to randomize the initial state, but we can leave that for later; to do so, you might have a function called randomize()
-Display the puzzle on screen (arrange the buttons or objects to match the model of the tiles in our array); this is the displayPuzzle() function above
-Check if a particular tile can move
-Move a certain tile into the empty spot
-Check if the puzzle is solved; this is the isPuzzleSolved() function above
-Display the final piece

Each of these functions is essentially some test or update of our variables (the array of tile indexes and the variables to keep track of the empty slot), or our objects/buttons, as the examples in the previous post demonstrate. It's a bit tedious to write, but shouldn't be too difficult, as each task is pretty simple, individually.

Q4. So how do we link those functions together and trigger them to happen at the right time?

A. You can see that if we have all these functions, it's not that difficult to wire up the whole puzzle. We just need to run the right ones when particular events happen:

-User enters room (puzzle starts): init()/randomize(), then displayPuzzle()
-User clicks on a tile: check if tile can move, if yes, move tile and update the display, then check if puzzle is solved, if so, display final tile


Mr. OUXX posted while I was writing. I'm sure his solution is good - in fact, probably better than this - but here's an alternative approach. Since they are quite different, don't try to combine this solution with his, but choose one or the other.

You want to know how to script the whole puzzle? It's going to take a good deal of code, I'm afraid.

I'd make the puzzle board a room, and add the pieces as objects. I'd have an array that kept track of the logical state of the puzzle, and update the positions of the pieces based on that. I'd use the Tween module to slide the pieces and to fade in the final piece when the puzzle is solved.

Here's a quick outline: Set up the room and the pieces (as objects). Make the first piece (in the solved puzzle) object 0, and so on, in reading order.

We don't want to do all the logic just based on screen coordinates: it's much easier if we have a model of the puzzle rows and columns. But because AGS doesn't have 2D arrays, we'll have to do a plain array and do the mapping to rows and cols ourselves. Then I'd have a couple of variables to keep track of the empty slot.

Code: Adventure Game Studio
  1. #define PUZZLE_COLS 3
  2. #define PUZZLE_SIZE 9
  4. // Puzzle state
  5. Object* puzzle[PUZZLE_SIZE];
  7. // Empty slot
  8. int emptyRow;
  9. int emptyCol;

Then you need to fill the puzzle with the pieces in jumbled order and set the empty slot position. I'll skip that part.

You also need to display the puzzle, so that what players see is synchronized with the logical state of the puzzle:

Code: Adventure Game Studio
  1. #define PUZZLE_PIECE_WIDTH 28
  2. #define PUZZLE_PIECE_HEIGHT 26
  4. int puzzleX = 50; // Set this to the top left X-coordinate of the puzzle
  5. int puzzleY = 70; // Set this to the top left Y-coordinate of the puzzle
  7. void displayPuzzle()
  8. {
  9.   int row=0;
  10.   int i=0;
  11.   while(row < PUZZLE_SIZE/PUZZLE_COLS)
  12.   {
  13.     int col=0;
  14.     while(col < PUZZLE_COLS)
  15.     {
  16.       if(puzzle[i] != null)
  17.       {
  18.         puzzle[i].X = puzzleX + col*PUZZLE_PIECE_WIDTH;
  19.         puzzle[i].Y = puzzleY + row*PUZZLE_PIECE_HEIGHT;
  20.       }
  21.       i++;
  22.       col++;
  23.     }
  24.     row++;
  25.   }
  26. }

Now if someone clicks on a puzzle piece, you have to check if it's adjacent to the empty slot, and if so, slide it there. I'll skip that for now, and just do the bit to check if the puzzle is solved:

Code: Adventure Game Studio
  1. bool isPuzzleSolved()
  2. {
  3.   // Check if puzzle is solved, and return true or false
  4.   int i=0;
  5.   while(i<PUZZLE_SIZE - 1)  // This assumes that in the solved puzzle, the empty space is the last one
  6.   {
  7.     if(puzzle[i] != object[i])
  8.       return false;
  9.     i++;
  10.   }
  11.   return true;
  12. }

The keywords found in that post have already put you on a watchlist.

Beginners' Technical Questions / Re: This Error...
« on: 28 Jul 2015, 18:47 »
On line 58 you have "Guybrush" instead of "cGuybrush"

I was talking to some people about the trip, and the first thing they ask me is "Oh, so are you guys big jazz fans, then?" :-\

Not convinced is broke. Why introduce more complexity to "fix"?

Pages: [1] 2 3 ... 197