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 ... 177

Living room:

Let me know what you think.

Reminds me of this:

Engine Development / Re: The Custom Speech API proposal
« on: 17 Dec 2014, 12:34 »
Nice work!

My only experience with custom speech has been for animated text (primarily to progressively type out the text typewriter-style, but I've also experimented with things like flashing, shaking or changing text). If I understand this API correctly it wouldn't be able to support that, but it might very well be that it falls outside of what it's meant for, and that my requirements not suited to a built-in API.


(I certainly hope this isn't actually an AGS game, or all the moderator action in the last few minutes has been pretty abusive. Like "American cops against random black dude" abusive... :-X)

The Rumpus Room / Re: AGS ANTHEMS Vol. 2
« on: 15 Dec 2014, 22:58 »
Damned if I know. The lyrics seem to be some kind of stream of consciousness ("airplane leaves Seattle / now landing in Düsseldorf / .../ tape roll picks up radio noise / bike ride on rainy gravel"). The end is sort of wistfully hopeful: "I walk barefoot in a store / take an icecream boat, I'm in love / Before, I was grumpy and cross / Perhaps I can be happy here." (Of course, in Swedish it scans and rhymes.)

The SN&B song is... rather more straightforward. :=

I think most experienced adventure gamers will be familiar enough with left-click-interact/right-click-look that they're unlikely not to realize it's available. For newbies, you could add a tutorial (some of the Blackwell games do this), and perhaps make one of the first puzzles depend on looking. (The most obvious way, and in my opinion one of the best, to do this is to only make a certain hotspot available after examination. For example, you examine a desk and find a hidden button. In this case you should probably give a clue if the player simply tries to interact with it.)

The Rumpus Room / Re: AGS ANTHEMS Vol. 2
« on: 15 Dec 2014, 13:33 »
I love bob Hund! Their best song however is without doubt "det skulle vara lätt för mig att säga att jag inte hittar hem, men det gör jag (tror jag)." (can only find live recordings of this one on youtube, and they don't do the song justice).

My favorite is probably "bob hunds 115:e sång," but I'm not an expert on the band by any means. I only had one EP of theirs + whatever played on the radio. "Det skulle vara lätt..." is on Spotify, anyway.

I'm one of the people who hates right-click-interact/left-click-look (it's contrary to the basic, standard semantics of the two mouse buttons in practically every application), so I'd strongly urge you not to go that way. Also, I don't buy that people skip looking in Primordia because it's on the right-click (personally I always look at everything, unless the game is particularly, pointlessly verbose; I imagine it's more a matter of individual differences in play-style), and I don't think switching the buttons around is going to make much difference to people's look-inclination: for myself it might even make me less likely to look, since if the UI annoys me I'd like to minimize the number of interactions.

Anyway, it's pretty easy to make it configurable, so if you're convinced it's a good idea I think you should at least give players the option to switch from your default, terrible mapping to the standard one.

The Rumpus Room / Re: AGS ANTHEMS Vol. 2
« on: 15 Dec 2014, 00:02 »
As a young lad I had this one on a mix tape, and listened to it on my walkman while biking around delivering newspapers all summer ;-D:
Ash - Oh Yeah

A couple of others that probably only make sense to Scandinavians:
Bob Hund - Düsseldorf (I always associate Sweden with summer, and the rattling at the end reminds me of a boat)
Sterk Naken og Biltyvene - Sommerlykke

Hmm, so CallRoomScript(), uniquely among script functions, blocks until a queued dialog is run? That is an interesting trick.

I assume you absolutely need this to be a dialog (i.e. you're using multiple-choice branching), because otherwise you could just write it as a series of character.Say() commands.

The conventional way to continue a function after a dialog is as Khris describes here:

Remember, you can call functions directly from inside your dialog script as well, you don't need to do it indirectly with CallRoomScript().

First of all, I really question your overuse of on_call() and CallRoomScript(). There's absolutely no reason to do that from another room script: just call the method you want directly! CallRoomScript is only needed to run room code from dialog scripts or the global script, and even then you can often use ProcessClick or RunInteraction instead, or simply use a global shared variable to let the room know the game state and any particular code it needs to run when the room loads.

CallRoomScript is bad because it makes the code unreadable and hard to debug, and (the way you're using it) relies on "magic numbers" ("if 1 do this, if 2 do that" etc.). In the very few cases where you do need to use it, I would strongly suggest you replace the numbers by meaningfully named constants or enums, so that instead of "CallRoomScript(0);" which you need to know on_call() by heart to understand, you would at least have something like "CallRoomScrip(RUN_PUZZLE2COMPLETE);" which gives you some useful information.

OK, for your specific problem: well, you call all of these commands from the "Enters the room before fade-in" event, so what did you expect to happen? If you want the actions to happen after fade-in, put them in the "Enters room after fade-in" event handler!

I suppose it depends on what sort of code you're writing. If it's just normal adventure game events and actions there's no reason you can't write them in the global/room scripts, but for "systems" like the UI, inventory, or if you have specific dialog customizations for example, as well as for minigames, I would always write it as a module (or if it's a very simple job at least as a helper function) straight away. At its most basic a module is just a separate place to put code, so it's no more work to do so. You don't have to write a complex API with everything wrapped up into a struct and so on.

I think you're misunderstanding the terms, springthoughts. It's not (directly) about code quality, i.e. that "green code" is better than "red code"; rather it's about separating what you want to do from how the computer should go about doing it. There's already a word for that: abstraction. You wrap all the nitty-gritty of how something works up into a function or a module, and provide an interface to just do it without worrying about the details.

Glad that solved it! I don't understand all the rules either, I just have a vague feeling that certain things are likely to break. The upshot of what Monsieur OUXX is saying, for this particular situation, is (I think) that this won't work:

-from a dialog script
-call CallRoomScript()
-which runs a script that calls player.ChangeRoom()

You might be able to do any two of those things (I'm not sure), or do ChangeRoom() for any character other than the player, but not all three in one go with the player character.

I'm returning from a dialog (with CallRoomScript(10); )

I would strongly suspect this is the problem. You're calling CallRoomScript() from within a dialog? Try what happens if you call it from a room script event instead. If it works, you can move the call outside of the dialog (by wrapping the dialog call in a function, ending the dialog and then calling your room script).

Platforming isn't inherently opposed to the "essence" of KQ (remember that #&*@! bean stalk in the first game). It's really too early to judge whether it will be a proper KQ game from just this trailer.

Anyway, even if there are examples of series that try to jump genre (or significantly change their style or mechanics) unsuccessfully, there are also plenty of ones that have managed it, from (World of) Warcraft to Paper Mario to Sim City/The Sims to GTA, Metroid and Duke Nukem upon going 3D, to X-Com, to Resident Evil.

A game isn't good just because it sticks with the same mechanics, and isn't bad just because it doesn't.

There used to be an article somewhere by Yahtzee about how he would draw and shade rooms in a style pretty similar to this, if anyone can track it down.

I'm sure there are, but I can't think of any with source available off the top of my head.

Further to your questions:

1. Not sure if Mr Ouxx is familiar with the Planescape dialog system, but I don't think those modules will prove very useful (certainly not the icon-based ones, and isn't KADS more or less superseded by the new built-in custom dialog system?). Having had another look I do think it's quite doable, but there's no denying it will take a bit of scripting.

2. The bit I thought would require extra coding is any "tile logic," i.e. if you want to make sure characters are always standing in the middle of a tile, can only move to adjacent tiles, if you have area effects (e.g. spells, explosions) or similar things that are measured in tiles, etc. All of that would be relevant in an RPG, but if you're just using a tile editor to create background graphics for a regular adventure game, it should probably be fine.

1. Hmmm... Probably. There are a few challenges, having to do with poor built-in support for scrolling text windows and limits on text length in a window. These you can probably work around. It could also be a bit difficult to integrate the dialog selection with the text window, though I believe the most recent AGS builds have features that might make it easier. It will require some scripting, but unless there's some roadblock I'm forgetting it should be doable.

2. Probably not. Depends on exactly what you expect. You'll have to define the walkable areas and walkbehinds, obviously. And for a decent-size map the image would be pretty huge, so that you'd probably want to split it up into several rooms (both to cut down on loading time and memory use, and to simplify the scripting in each room).

3. No, I'm pretty sure there isn't. You might be able to convert one of the formats Chat Mapper outputs to something AGS can import, though. Otherwise there's an AGS Dialog Designer app that has some of the same basic features.

4. How do you mean? You can save a game project to source control, but certain resource files (the sprite cache in particular) are saved in a binary format, and if different people edit the game in parallel this can lead to unresolvable conflicts. There's no built-in git integration in the editor AFAIK.

The bottom line is that although it's technically possible to make an isometric RPG in AGS, it's not what the engine was designed for, and it's probably not the best tool for the job.

Editor Development / Re: Help file... here we go again.
« on: 05 Dec 2014, 01:32 »
Maybe we should split this into separate threads: decision and discussion ;)
Otherwise I guess we might never get started - and the help file situation is really not the best.

Yes, sorry I brought it up. I thought the decision part was a no-brainer, if as you say:

To sum things up, there's just one usable Help Authoring Tool: it's Sphinx.
Moving over to Sphinx isn't hard, as Alberth already provided a conversion tool and did the conversion.

In fact, it sounded like it was more or less done, and just a matter of fixing some small issue and then committing it to the repo (or whatever the git equivalent). I see now from the pull request and sample HTML output that there are still some rough edges.

At the moment the AGS help file is huge and rewriting it from scratch would be a tremendous task. It will need to be split up, but it can wait.

We wouldn't want to rewrite it from scratch anyway, would we? I think some parts could be better, but it's very much a matter of incremental improvements.

Moving all the documentation into the actual source code (my opinion) would make things even worse and waste countless hours, although I'd like to hear CW's and Guroks take on this.

Whether or not it's better in principle, I'm less and less convinced myself that the benefits outweigh the hassle.

Pages: [1] 2 3 ... 177