Messages

Certainly for backgrounds 2d is the way to go for AGS scenes, if you're only going to be viewing a room from one angle you may as well draw it, modelling is no easier, especially if you're just doing a cel art style (which I think looks wrong for backgrounds anyway, even animation that uses cel shaded characters typically has painted backgrounds, cel shading is a compromise between quality and speed needed for animation frames).
I also think that would look better in AGS, although I'm certainly not anti 3d.
Cel shaded characters on hand drawn backgrounds like in Runaway is a much better idea, because it does save your animation time for high res characters.  If I ended up doing the character animation in TJH part 2 I'd have to do it this way, there's no way I could draw 800x600 2d animation alone.

And stuh, you can't really compare the commercial 3d game making process to one artist making 2d backgrounds.  If I was doing the whole 3d thing myself I'd say one 3d room is about the same amount of work as one 800x600 room painting, and one animated 3d character is a similar amount of work to a 2d one (maybe more to create but less to animate).  I agree you'd need the same amount of art skill to do either well, and 3d is not going to make bad art good.

I don't think you come across as a pimp at all, in fact, I had never heard of your game until that post (one reason why I didn't nominate it) so you can't have been pimping very much.  People read your post wrong that's all, it's time to let it lie though.

Oh, and I will check out your game soon.

I wrote a long post on why I think cel shading is a pointless, and not very good looking gimmick, but actually... for many of the people here it might be a shortcut to a professional looking style, and it does generally look better rendered into 2d games than other kinds of 3d.
However, if you can master 3d animation enough that your cel shaded characters don't look completely wooden you can probably 2d animate well too, they're not totally dissimilar, and good 2d always beats good 3d in a 2d engine, like AGS.

And I agree with Eric, the main advantage of 3d is the effect it can have on gameplay, something which doesn't exist in AGS "3d".

The ToaK GUI gave yOke some trouble, I drew the buttons as overlapping non rectangular shapes, not sure how he managed it, but I'm sure he'd have appreciated ths feature too.

Yes, I think you should honour all the license agreements of things compiled into the engine, not just those you use.
However, I can't see why this should be done for commercial games any more than non commercial, I don't see anything in the licenses making the distinction, so ALL games should do this really.

So, you should register jgmod, and put "OGG player is alogg by Javier Gonzalez, using the Ogg Vorbis decoder, which is available from http://www.xiph.org/ Copyright (c) 2002, Xiph.org Foundation" somewhere in your documentation.  The other licenses require nothing of you, a couple of them would like but not require a mention in the documentation.

Greece is close? It'll probably be closer other years.  There's usually one in Britain.

I will be there. Ã, It's about £126 to go from the UK, for anyone else here.

Yes, it really is more about that.  It's not like we haven't had under 16s at an AGS gathering before.  But at that age, unless you're well known and trusted by the person hosting the event you are unlikely to be allowed to come. You've been a member of the forums for 3-4 months, it's not really long enough for anyone to get to know you well enough I'm afraid, maybe next year, there's usually something in Northern Europe.

Actually it's been kind of seriously suggested we hold the European meeting in Greece this summer, a few people are possible hosts for that, it's sunny and not particularly expensive to get to.  The Israeli members say they could afford that too.  I also heard a couple of previously non attending Scandinavians (including Finland!) say they could possibly make that location.

I don't think it has been mentioned on the forums, so I thought it was worth discussing here.

If it ends up being in Sweden again I'm fine with that too.

Yes, it is.  Both whole sprite transparency, and alpha mapped transparency, which is what you want.  You will need to make your game in 32 bit mode to use this feature.

PS is no more complicated than PSP, really, besides having a few more features you can probably ignore.  Most people start on PSP because it has a free (shareware) download, I did, it was good, I used it for many years, then switched to PS, which is actually a better program for me.  (If you ever have to use it for a while you'll probably start to agree)
The keys are non standard? Is there a standard set of keys for graphics apps?  If there is Jasc certainly doesn't use them... the PSP interface is mostly a clone of the PS one, they are virtually the same except for keystroke differences.

PS has a much nicer brush engine, for painting I'd never go back to PSP.  For anything else I do they're mostly interchangable, except PSP is slower on large images.  If you don't do much tablet based painting, and are mainly a pixeller, I'd say they are about the same.

Tanker: I don't think you need to read books and tutorials, you'll pick it up.  It's worth getting used to layers from the start though.  Whichever app you use.

Guis don't have to have static regions, if this is for your NWN GUI I'd suggest using the gui system.  You can move around buttons in script, and if you want to hide buttons just move them off the visible area of the gui.  I built a sims style GUI this way, unfortunately I have lost it... but it was much easier that using overlays would have been.

Your NWN GUI, which I assume this is for, sounds kind of similar, but has a sub gui folowing the same principal.  I'd look at the actual GUI system before trying something more complicated, it's probably more than capable of doing what you want.

I don't think more overlays is the best solution to it even if you couldn't do it with the gui system,  a few more drawing functions would be nice, and I don't mean rawdraw... functions that only draw on the current frame, like game maker has.  Actually I have made a plugin that allows you to do this (someone is making a game that needs it) but it crashes currently... I'll take another look at it.

Thanks Gil.

I updated it, should work in all colour modes now, and there is a function to turn it on and off.

(No of course there is no problem hosting it, Rui)

Perhaps the source could be useful to someone as an example, very similar to the template though.

I am not sure if it'll ever be useful to anyone, but I made this this evening, and here it is.

If you've played old Sierra games, or some modern low res games you've seen it.  This gives you the 160x200 background/character effect, keeping 320x200 guis and text.
"Why can't I just scale my graphics to do this" you might ask, well there are a few problems you might not thing of right away, one major one that ruins the effect is the way the character can seem to move half a pixel, which looks very wrong.  This forces all pixels into the right grid.

Here is a shot of Ghormak and Helm's 'Gladiator Quest' which used the plugin, instead of PC EGA this was emulating the C64 multicolour mode:


It just does that graphics resolution, not other AGI game things, such as parsers or keyboard control, if you want any of these you should script them yourself .

Also, in the event that you do use this you'll probably get some bugs, I promise to fix them if I can.

Edit: uploaded a working screenshot.

If you join the AGS IRC channel, #ags on Quakenet, and type:

Roger xdcc send #160

and also:

Roger xdcc send #161

then you'll get the games.
He can delete his links no game can hide from Roger's archive!

2.7 has added support for script modules.

There are still some things in C++,  that'd be nice to add to the scripting language, but I think we have most of them... I've tried scripting a lot of unusual things in AGS, there's not much that you'd need C++ for.  And I don't expect that 2.7 has the last improvements to the scripting language we'll ever see.

Perhaps a feature that imports a sequence of images into the sprite manager and also puts them into an animation loop would work best.

Well, you'd make an array, of 200 strings, or however long you wanted it to be, along with an int, keeping track of your position in the array.  Make a function called displaySpeechRecorded(int charid, string line);  Give it a body with something like "positionint++; if(positionint==200) positionint=0; speechArray[positionint] = line; DisplaySpeech(charid, line);" in it

In your game you'd use that function instead of the usual DisplaySpeech, unless you didn't want it to be recorded.
speechArray would contain the last 200 lines spoken then, going backwards from speechArray[positionint], wrapping around to the array size-1 at 0.  You could, with that, make a GUI that has code to display the last X lines, with scroll buttons.

If you wanted you could add something in that function to write out the text into a file, as well.  For long term recording of speech.

Game scripting languages are often designed to have limited features, to be easier, they are most often designed to be used by non programmers.  If you had to write your AGS scripts in C++ we'd get games creating memory leaks and buffer overflows and all the other problems you can get when using C++ without care.  In my engine I'm using something with similar features to AGS script, which IMO is about the right tradeoff between safety and features.  You can do almost anything in AGS script that you would need in a traditional point and click adventure, and that was what it was designed for.

Why do you think making the AGS language be C++ would be easier for CJ? C++ compilers are very complicated, and the language is just not designed to produce scripts to be embedded in a pre built engine, I guess you're asking for some headers and that give you more access to the AGS engine, and then you'll compile your game with a C++ compiler, into a dynamically linked library or something.  95% of people would not be capable of that, and I personally wouldn't bother because the scripting language is just more suited to scripting AGS games.

Another advantage of bytecode compiled scripting languages, they can be cross platform with no need to recompile.  You can run an AGS game in the linux or DOS engines as it is, with the game logic done in C++ you'd have to make three versions, and keep your code cross platform enough to allow you to do that.

I'd certainly prefer the current way over giving someone a set of C++ headers and libraries and a compiler and getting them to write the game that way.  If it's not too much trouble to CJ it wouldn't hurt to let people do this, but I think the current plugin system combined with the scripting language is more than adequate.

I think this would be quite nice, AGS has animated gif import, but that limits you to 256 colours per sequence... if AVI support would be hard at least the ability to import a numbered sequence of images would be nice.  That might be better, in fact, considering AVI doesn't support alpha channels (afaik), and many people's sprites use them.