Hello, my first post here. 1st off wanted to say how cool AGS is. Just happened upon it a couple of weeks ago and was quite gobsmacked. I work in the game industry and a lot of tool programmers in the industry could take some important lessons from how AGS has been approached... Congrats, I'm now officially hooked!
Anyway, since I do not yet have a solution to someone else's problem, have a problem of my own, or have some screen caps from our AGS game ready to post, I'll start with a few things I've noticed that could be improved. Sorry if some have been suggested before, or if they are already implemented and I've missed them...
* Views and other non-deletable main types referencable by string instead of the explicit index? e.g.:
cEgo.ChangeView("walk1");
Might be some speed issues doing a string compare each time, but then how often do you change the view of a character? Not every frame hopefully, so should be ok? As well as making the script more readable, and specific views easier to find, this would allow them to be deleted without nerfing the scripts I assume?
* A drawable null area around the rooms in room hotspot editor etc. Allow the user to put down a point in this border to make it easier to draw a line that goes through the entire screen. At present you have to aim precisely at the edge pixel.
* Walk-behinds "Set Walkable area", a walk-behind can be told to only affect only one walkable area. This would allow for walking over hill brows unless there's something I've not thought of...
* Walk-behinds "Set peak-line", only a base-line OR a peak-line could be specified for a walk-behind. A "peak-line" would do the reverse, and hide the character only if they're below it. This would be useful for the above hill brow thing (tho it could be worked around without this by setting the base line to be at the bottom of the screen thus on that walkable area ALWAYS walk behind.
* Test Game to automatically ask to close the script window, and then run the game. Having to close the script window manually, and then reclick test-game is very irritating, and the time adds up when retesting regularly...
* Support for sprite pages please!!! Sprite pages would be completely awesome, save a lot of time importing sprites into the editor.
* A quicker way of adding frames to loops. Selecting a range of sprites and it filling out the loop would be great.
* Support for externally accessed sprites. Being able to replace sprites on the HD and re-run the game would be well funky.
* Setting origin point on views. Being able to set the point on the sprite that you consider 0,0 would be great for easier lining up sprite interactions and such.
Some others that are doable as modules, and so are less important, but would be cool for newer users nevertheless:
* Linking objects to characters - I've wrote a module for this but only supports 1 char and one object at the moment. May redo it with 2.71 assuming I can now have an array of pointers in a struct, but being able, for example to allow for someone new and non-programmer savvy to be able to, for e.g. push a step-ladder across the screen, would be very handy. (As a side note, I found I had to do a linking system was because the character movement and object movement speeds didn't seem to tally as the help suggested... tho I may have being missing something)
The way I have it set up:
ELM_BindObjectToCharacter(cEgo, oTrolley, 10/*xOff*/, 0/*yOff*/);
ELM_UnbindCharacter(cEgo);
-------
That all aside, AGS is great stuff and it looks like it's realizing your ambition to bring back point-and-click games to the masses. thanks for this wonderful tool, and thanks for keeping it free!
I'll be sure to release all my modules and plug-ins once they've been tested in our game enough.
Oh and hello everyone :D
lemmy101
Just out of curiosity you wouldn't be Nemu64-Lemmy would you?Ã, :o Oh and good luck with your game sorry I can't comment your suggestions but I'm sure someone will soon...
1 - You can actually name views and use things like
cEgo.ChangeView(WALK1);
2 - The whole "drawing" system is very simplified, and that's been remarked on. Mostly, everything stays as it is because you can also import a mask and/or use a magnifier program for fine-tuning.
3 - While it's not a bad idea, it can be easily arranged by having more than one walkable area/region and a couple of Walkbehind.Enable/Disable commands.
4 - Again, not a bad idea, but as you say, not that hard to work around.
5 - You could get used to Ctrl-T. Less time-comsuming, and it doesn't work unless the window is closed.
6 - I don't know what "sprite pages" are, but you do know you can import GIF files and also tiled sprites, right?
7 - You mean like selecting the sprites and right-clicking and "Assign frames to loop"? It's there.
8 - That's more advanced, but possible. Check out "dynamic sprites" on the manual.
9 - Dunno what that means... hopefully someone else does. :)
10 - Again, I don't really see what you mean, but I'm curious.
And hya. :)
Woah, well turns out a fair few of my gripes have work arounds anyway :) cheers for the response:
1 - You can actually name views and use things like
cEgo.ChangeView(WALK1);
-- Cool stuff, I'll definitely use that. However that's an enumeration, is it not? if so, it still means that views cannot be deleted due to the indexes changing (am I understanding that right?)
3 - While it's not a bad idea, it can be easily arranged by having more than one walkable area/region and a couple of Walkbehind.Enable/Disable commands.
--Excellent stuff, I'll have a play with those commands. thanks!
6 - I don't know what "sprite pages" are, but you do know you can import GIF files and also tiled sprites, right?
--tiled sprites, as in you can have a single image which each frame on, and use that in-game?
9 - Dunno what that means... hopefully someone else does. :)
-- Sometimes you need to make a sprite area bigger than the actual image. For e.g. if a few frames of the anim extend quite a distance (e.g. where a character/object travels within the sprite animation). Thus sometimes you end up with a lot of blank space around the sprites, or inconsistant spacing around the sprites. Being able to set your own specific offset, for e.g. setting pixel 16,31 on a view would define that as the point the character can be truly said to be in. char.x, + char.y would take these into account, and would give/set a location relating to a part of the sprite you specify (bottom of feet for a character, end of cable on a dangling light) instead of them all being (i think) the centre bottom of the sprite by default.
So on a lightbulb, for eg, I'd set the origin to the end of the wire it's hanging off. Then by setting the x, y I am setting it to the exact point the wire connects, making it easier to place, and also to allow easier lining up of another sprite, for e.g. a character wanting to grab hold of it (not that they would want to grab a lightbulb, but you get my point).
10 - Again, I don't really see what you mean, but I'm curious.
I was trying to get a character to push a trolley object in a room. I tried:
cChar.Walk(x, y, eNoBlock, eWalkableAreas); // speed is 4
oTrolley.Move(x, y, 4, eBlock, eWalkableAreas)
and...
oTrolley.Move(x, y, 4, eNoBlock, eWalkableAreas)
cChar.Walk(x, y, eBlock, eWalkableAreas); // speed is 4
however the object would dart along really fast ahead of the character. Best I could do was putting the object speed to 1, which was close, but not exact.
As I said, Iv'e wrote a module to allow you to link an object, with an offset, to a character, and that object will move along with the character. It's not perfect yet, and I want to make sure it's bug free, and at that point I'll post it here.
Cheers for the replies!
And hya. :)
Quote from: Mason on Wed 11/01/2006 14:31:03
Just out of curiosity you wouldn't be Nemu64-Lemmy would you?
Nope sorry :)
Hello, and welcome to the AGS forums!
Quote from: lemmy101 on Wed 11/01/2006 16:06:01
1 - You can actually name views and use things like
cEgo.ChangeView(WALK1);
-- Cool stuff, I'll definitely use that. However that's an enumeration, is it not? if so, it still means that views cannot be deleted due to the indexes changing (am I understanding that right?)
Effectively, yes. This is one reason why there is no option to delete views.
Quote
3 - While it's not a bad idea, it can be easily arranged by having more than one walkable area/region and a couple of Walkbehind.Enable/Disable commands.
Dealing with hill brows is more complicated than your suggestion anyway, because once they are over the summit, the character actually walks back down on the same walkable area as they walked up on -- therefore some manual fiddling with disabling the walk-behinds is required.
Just to clarify, the way to enable/disable a walk-behind is to use SetWalkBehindBase; there are no WalkBehind.Enable/Disable methods.
Quote
--tiled sprites, as in you can have a single image which each frame on, and use that in-game?
Yes, when the sprite import window is open, after you select the file to import from, a "tiled sprite import" checkbox appears -- tick it, then you can import several sprites based on the one image.
QuoteSo on a lightbulb, for eg, I'd set the origin to the end of the wire it's hanging off. Then by setting the x, y I am setting it to the exact point the wire connects, making it easier to place, and also to allow easier lining up of another sprite, for e.g. a character wanting to grab hold of it (not that they would want to grab a lightbulb, but you get my point).
Yes, I can see the usefulness of a suggestion like this, it's something that may well be added at some point.
QuoteI was trying to get a character to push a trolley object in a room. I tried:
cChar.Walk(x, y, eNoBlock, eWalkableAreas); // speed is 4
oTrolley.Move(x, y, 4, eBlock, eWalkableAreas)
These will move at different speeds because of the anti-glide mode for characters, where they only move when the animation frame updates. This does not happen with objects.
Your suggestion for some sort of AttachObject feature is a good one. A temporary workaround is to put some code in your repeatedly_execute_always function to continually adjust the object's co-ordinates based on the character's.
Thanks for all your suggestions and input :)
7. I don't use test game anymore it's way too slow. Copy acwin.exe into the game folder, then set up a shortcut to acwin.exe in the windows quick launch part of the tool bar. And you have instant testing without waiting for sprites/game etc to save.
1.) Just to clarify: When you give a view a name in the view editor, AGS makes this name a defined term that you can use instead of the view number. Each time you use this term in script, it is later automatically replaced by the actual number of the view when the game is compiled.
So if you name a view FLYING, for example, you can use
player.ChangeView(FLYING);
instead of directly supplying the number of the view.
The name can contain numbers, but that has nothing to do with the actual index of the view.
Could AGS ever have a GoSub command or DIM arrays?
^ AND I ROFL'D.
that WAS a joke, yes?
Elliott, instead of mocking him, you could explain to him why you think they are not needed.
Quote from: Rap4Life42o on Thu 12/01/2006 15:33:17
Could AGS ever have a GoSub command or DIM arrays?
GoSub and DIM arrays are methods of calling functions and declaring variables in Basic languages. AGS already has this functionality, but they handled differently. I'll assume you've seen these on Visual Basic 6 for example purposes.
Calling a subroutine (function):
VB:
Sub HelloWorld()
Console.WriteLine("Hello World!")
End Sub
Sub Main()
GoSub HelloWorld
End Sub
AGS: (edit: cheers khrismuc)
function HelloWorld()
{
Display("Hello World!");
}
function Main()
{
HelloWorld();
}
DIM array:
VB:
Dim MyArray(50) As Integer;
AGS:
int MyArray[50];
-----
So as you can see, you don't need those two keywords in AGS.
Hope this helps...
Cheers,
lemmy101
PS: Love the background art on your site. They yours?
Here's the correct AGS code:
function HelloWorld() {
Ã, Ã, Display("Hello World!");
}
function Main() {
Ã, HelloWorld();
}
PS: It's not his homepage, afaik this domain belongs to Neole.
Quote from: khrismuc on Fri 13/01/2006 10:19:46
Here's the correct AGS code:
function HelloWorld() {
Display("Hello World!");
}
function Main() {
HelloWorld();
}
PS: It's not his homepage, afaik this domain belongs to Neole.
??? my head hurts. The dangers of having a net connection on a different computer to what you're commenting on. ;D Yeah that's C/C++ code I gave you there, sorry.
I know loads me, honest! ;)
I think in AGS void is also supported, but if there're not any real reasons just use function (same as using int).
I thought GoSub commands move from the script to another part of the script and then jump back to where it was?
Quote from: Rap4Life42o on Fri 13/01/2006 14:59:35
I thought GoSub commands move from the script to another part of the script and then jump back to where it was?
That's what GoSub does in BASIC, AGS is based on C/C++ syntax which has NO GoSub. Instead that's what a function call does in AGS.
AGS and BASIC are two different languages...
It's like saying "I thought Bonjour was English for hello?" It does mean hello, but it doesn't mean hello in English, it means hello in French.
In AGS you don't need to GoSub, it is implied by you typing the name of the function (i.e. the other part of the script) that you want to go there, and that after it has run jump back to where it was.
lemmy-
* Support for sprite pages please!!! Sprite pages would be completely awesome, save a lot of time importing sprites into the editor.
I used to do things this way too (the hard way) and then I realized that making your animations as gifs is INFINITELY easier to deal with. If you don't have built-in animated gif support in your program just use microsoft gif creator or another freeware app. In the long run it saves time since you don't have to put each frame side by side (or vertically).
I think what he means by sprite pages is what some game companies do is, you give them a sprite sheet and through code the program grabs portions of it to make an animation. Usually they look like film strips
Instead of me having to split it up. the program does.
It's handy if you want to do a quick colour replace or something but personally I think GIF import is the single best feature ever for things like this.
Quote from: MrColossal on Fri 13/01/2006 17:09:12
I think what he means by sprite pages is what some game companies do is, you give them a sprite sheet and through code the program grabs portions of it to make an animation. Usually they look like film strips
Yeah, I definately think this comes down to personal preference and/or the software you're using to draw your sprites. For example, all my sprites are done in DPaint Animation, so having to save out my frames as an image sequence, and run an action on them in Photoshop to crop them and then perhaps compile them into a GIF animation is a bit of chew on when I could just give a single page (which I tend to have anyway as I'm working) and be able to type in the X and Y dimensions of the sprite when I import and have it automatically cut the frames out.
However, I have to agree with Lemmy that being able to store your frames externally and have them compile in at the point you test would be amazing as it would free me up to make small changes to my animations without having to bother the person putting them in. I just update the files I want and wait for the next test.
Oh - and hello everyone :)
QuoteI think what he means by sprite pages is what some game companies do is, you give them a sprite sheet and through code the program grabs portions of it to make an animation. Usually they look like film strips
My reply was addressing that very issue, Eric, which is why I said it's easier to make the animation as a gif rather than store them side by side or vertically (what you call film strips). I used to do all my work that way and, in fact, my game engine loads in images in this format and sections them to create an animation (using x or y offset and number of frames as a guide). However, as I got into doing animations and saving them as gifs I realized this was a much more streamlined and convenient way of handling things since I don't have to redo the frame list over again if I do a small edit- which is tedious. Eventually I'll probably add an animated gif loader to my engine but that's when I stop being lazy :( .
I didn't know you were talking about your own engine, since he's speaking of AGS which can't do what your engine can do.
Quote from: CaptainBinky on Fri 13/01/2006 17:16:43
However, I have to agree with Lemmy that being able to store your frames externally and have them compile in at the point you test would be amazing as it would free me up to make small changes to my animations without having to bother the person putting them in. I just update the files I want and wait for the next test.
This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.
However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.
If you're going to do that, this is my suggestion:
Have a data repository with a path that is specified in the editor and a checkbox that says whether or not to use it. Then in the editor the sprites and backgrounds/walkable areas/regions etc have a relative path to the graphics, plus the clip rect, transparent colour/pick point, etc.
Sound and music could go in the repository too.
Finally a bake button that imports the new graphics (or a checkbox to autobake when you compile, otherwise the compile just uses the graphics on disk without importing them).
This way you can use the uncompiled game on multiple machines with different directory structures, and so on.
It might be interesting to have an option for the compiled game to use the repository (with the repository path relative to the executable or specified in the ini file) so that artists working on graphics could see them without having to know how to use AGS. One would have to be careful not to release this version to the general public though.
Quote from: Pumaman on Fri 13/01/2006 22:23:55
This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.
However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.
This would be great to have. The best way I can see it working would be to seperate "Test Game" from "Distribute Game". Distribute game would go through all the motions of importing all images etc and storing them in the exe as you do now, where in development using Test Game would run it with dynamically loaded gfx. Best of both worlds.
Tho this all depends on how it's implemented in code and may not be as straightforward as that.
Quote from: Pumaman on Fri 13/01/2006 22:23:55
This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.
However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.
This would also be very useful for team development. If sprites don't have to be embedded in the binary game source files, one person can work on coding while other(s) can work on the graphics. When some graphics is changed, it'd be very easy to update. This would ease communication between team members.
To take the idea a step further, I wouldn't mind if room graphics (and areas, regions, etc.) would be stored on the disk as separate files, too. That way, room graphics could be easily updated without the need to reimport the graphics.
When specifying room graphics, a separate file could be used to specify the background, each hotspot, each walkable area, each region, etc. This is what happens now, anyway, just the graphics is stored in the binary source file, not as a separate graphics file. This would mean a lot of files, but it would also be very flexible. (And the current implementation could be kept; in the room editor, a checkbox could be used to switch between the current way and storing data in separate images for each room. So very simple rooms could use the current implementation, complex rooms could store everything as individual files.) I hope it's not too confusing as I explained it. :)
I appologize for not getting into this discussion sooner but I have been away from home and internet challenged since Christmas.
1. Anyway I like the idea of being able to reimport sprites from their original locations. However, using a single directory as the repository is a bit problematic and inconvenient, IMHO. If the repository were a collection of sub-directories instead of a single directory then I think it would work much better for a greater number of people.
2. I also think it would also be useful to display the first N characters of the original filename next to the sprite number and/or the full name as a tooltip or property.
3. Perhaps the sprite number could be assigned to an enumerated value constructed from the filename and repository folder.
4. I also like the idea of doing the same thing for room graphics. In addition to the backgrounds I find that many sprites are drawn for specific rooms. In this case, wouldn't it maKe sense to keep these spites in the same folder as the background for which they are drawn?
Hope something comes of this, it's something I have thinking about for a long time.
Quote from: RickJ on Sun 22/01/2006 20:24:19
1. Anyway I like the idea of being able to reimport sprites from their original locations. However, using a single directory as the repository is a bit problematic and inconvenient, IMHO.
Yeah - what I had in mind was that your sprites (and rooms - any asset in fact - sound, art, anything at all) would effectively be pointers to disk locations so that you can organise your assets however you like, and then they'd all get sucked in at compile time. Obviously this means that there's nothing to prevent you being extremely disorganised, and some sort of error checking will be required should you delete a bunch of assets required by the game. However, this all just comes down to personal organisation.
Edit by strazer:
Use the quote tags:
[quote]
This will be quoted
[/quote]
Yes, I think some sort of system that automatically "sucked in" all the files at compile time would be much more feasible to implement than the engine being able to load the image files from disk -- since the game file formats would remain the same, and the engine wouldn't need to contain code for reading JPG, PNG, GIF and so forth which would really bloat its size.