Messages

[textures]

I'm not sure whether this is the problem, but colours with lower indices (at least #0-15) are supposed to be "reserved", so you may not be able to do whatever you want to them. For dynamic palette entries, it's advised to have them taking higher indices(which also in general is better for organisation, so you can have all the fixed colours taking the lower indiced slots).

I have re-checked it with setting color id's to "room", and nothing changes. For some super-weird reason, only the first slot in the palette is ever shifted.

Same happens with SetPalRGB:

SetPalRGB(0, 42,42,42) works.
SetPalRGB(1, 42,42,42) and subsequent slots, don't.

Neither Direct3D nor OpenGL support paletted mode natively (because both are working with textures rather than bitmaps). The solution that was once suggested is to create a mixed mode where the in-game gfx manipulation would be performed in 8-bit software mode, but the final output made through one of the "advanced" renderers (converting final 8-bit room image on fly). However, no one has got to make such mode yet.

Since AGS 3.4.1 both hardware renderers actually run 8-bit games, converting all sprites to 32-bit, but support is only formal, because some graphic aspects may be lost and dynamic palette cycling does not work either.

So AGS uses native Windows software rendering? GDI? Or is it Allegro's?
I remember dabbling in SDL and Pygame a while ago and it had 8bit surfaces you could draw onto and then manipulate as needed, including drawing to 32bit textures.

Anyhow, lot's of cycling effects can be "imitated" by brute forcing it as animated objects, but actual shifting/cycling is more performance-friendly and can be really breathtaking when used skillfully, like these images by Mark Ferrari - not a single animation frame there, only static images.

Hi,

I was experimenting with 8bit 256 color graphics as of lately and have run into a few issues.

First, palette importing. When importing from bmp file it all goes well, but when importing from a pal file, the palette rgb values have some weird offsets, appearing much higher than 255, and throwing an error in AGS.
I'm using ProMotion app for palette export, it may be that the problem is on its end.


Next is the palette cycling. I admit I've never used it in AGS before, but this kind of behavior is really odd... For example, when using CyclePalette(0,15) function, I understand the palette indices from 0 to 15 should *all* shift one color value every tick, right?
In my case, only the index 0 shifts until it reaches 16 then wraps. Indices 1-15 remain static.
Example:

If I use anything but 0 as function parameter, ie. CyclePalette(1,255), nothing happens.
I'm on AGS 3.4.2 alpha1, but I remember similar thing happening few versions ago too. Tested so far on two machines, one desktop with nvidia gpu and one Intel Atom tablet. Both running Win10.

And finally, since 256-color graphics are only supported in software rendering mode, does it make sense to use it at all? I vaguely remember reading about people having issues with software renderer, and not having a fallback option doesn't seem like a great idea. In any case, 8bit graphics is only relevant for palette manipulation, everything else works the same in 32bit mode anyway. But palette manipulation IS a great feature to have.

------

EDIT/SOLVED: If you're one of those forum searching people from the future (Hi people from the future! Did you come here in a flying car?) the full explanation is in the post #16.

erm... itch.io anyone?

It's just like Steam, only completely different.
In a sense that you get all the benefits of Steam, with almost no drawbacks. And no exposure, but that can be argued over even on Steam, so yeah...

Yeah, I'm aware of those guys. Back in the 80s we had monthly Mickey magazine(basically, our version of Topolino, I'm from Croatia) with assorted comics by Italian and American authors. But Cavazzano always stood out with his unique art style. Romano Scarpa was great too, and of course, any story by Carl Barks.
I think it was Cavazzano who drew first CYOA-style stories with multiple endings back in the mid 80s. That stuff was addicting as hell for us kids. We used to run to the newsstand on release day! It was the start of adventure gaming before we had our VCRs, C64s, Amigas, Nintendos, and waaay before anyone had a PC. Just numbered sheets of paper.   Glory days.

Great Scott, this looks awesome!!

I noticed you're from Italy - I'm getting really strong Italian Disney Comics vibes from these screenshots! Paperino & Co. FTW!

Lack of platform support, that I understand. But complex scripting? AGS was my first foray into programming, and it took me next to no time at all to learn the basics (although it did take several years to master everything).
And personally, I think the AGS scripting language is much simpler than the scripting yours does (at least from what I can tell by looking at that little coding blurb).

I suppose it's all personal preference though. Nothing short of a drag and drop interface would make coding easier. Unless you can make it like Python. Python is awesome.
And none the less, it's nice to see something on GameMaker that allows you to make adventure games.

As for what you should do. I think the crowdfunding way might be a good idea to go, and if that fails, go commercial.
I won't be a customer, but I'm sure there are plenty of people who would love it. You just need to make sure those people know of its existence.

Regarding the complex scripting in AGS, I didn't mean the actual syntax, but the stuff that happens when going outside of the "intended" usage of the system. Think of it as delta time between starting a project and resorting to workarounds, hacks and temporary solutions, because things don't work as you think they should. This delta time is larger in Gamemaker just because it's a general purpose 2D engine.

Regarding the drag and drop, my intention was to go as far as possible from drag and drop system and more towards the "scriptwriting" system. I tried to stay away from more visual systems such as Visionaire, which are rather awesome when used as intended, but again, have tendency to drive users mad when going "out-of-the-box".
I do take advantage of Gamemaker's inherent visual nature - It's Room editor is similar to AGS and Sprite editing and support is eons ahead of AGS, but for all the "game specific" stuff, there's code.

My main influences when going with this were RenPy (visual novels) and Inform7 (interactive fiction). Both of those have very "textual" approach to game creation.

But then again, those systems use almost completely natural language and my scripting is limited by GML synatax which is a weird combination of javascript, python and... 1985-style C, I guess.
I had plans of allowing to script in both GML and more descriptive/natural language, but that soon becomes a fight against Gamemaker itself, and requires lots of man-hour wasting.

Current way of doing things with weird procedural syntax is a middle ground between leveraging the good stuff about GM and keeping everything on schedule and on budget. A non existing budget is still a budget, right?!

And nice that you mentioned Python awesomeness. I agree.  A hybrid between AGS and Gamemaker's visual approach and RenPy's Python + custom scripting approach is the stuff the dreams are made of, I believe.

I use Game Maker and I think a lot of people would love the idea of a Point & Click kit,don't know if you can pull a crowdfunding success,but if the kit was good enough,i'd buy it.

Thanks for you encouragement, I appreciate it a lot! This thing will definitely be released, I'm just trying to decide whether to polish it up as a kit, or pack it up alongside a finished game. Decisions.

PS: The reason I actually posted about it here was to see if anyone would be interested to beta test it when it gets to that phase. I consider AGS community as THE community when it comes to adventure development. Just drop me a PM and I'll put you up on the list.

Thanks for your comments, and I completely agree on the walking issue. To be honest, I'm more concerned about actor's vertical speed being equal to horizontal, as fixing that requires custom pathfinding solution. But all of that is on the to-do list. It will be done. Eventually.

But thanks again for your suggestions. It's what I'm looking for - I'm kind of dumping it here first to see if there's any interest left in point 'n' click development and to decide what, if anything, should I do with this.

Hello everybody!

Few years ago, I was working on this one AGS adventure that sadly never got finished because reasons, most of them being of financial and/or scheduling nature.

One reason I got discouraged about (although the least important to be honest) was AGS's lack of cross platform support and somewhat too complex scripting.

So, instead of idling and not doing anything I decided to try and develop something of my own.
Fast forward a few years of learning how to program in everything from bare-metal C++ to Actionscript, I went for the middle ground and choose Gamemaker Studio for this (ad)venture.

And now I got this little point'n'click framework I would like to show you.
Here's a short demo video:
(Pay attention to the bottom-left, outside of game window, where debug console prints out stuff that shows game logic in action.)

https://youtu.be/9n9pDDjvT-U

The goal was to create a scripting environment for non-programmers that would be mostly similar to movie script-writing.
For script commands, I was mostly driven by the way how stuff works in SCUMM and AGS. Actual syntax is dictated by Gamemaker's GML scripting language which sadly doesn't support dot notation, so everything is done as procedural, C-style function calls.

I kept the one-script-per-room system similar to AGS, as it seems more intuitive for non-programmers. It's like having the movie script page in front of you and everything that happens in the room is on that page.
The Real Programmers(TM) can still use separate scripts if needed, for example to define GUI layouts or cutscenes, or whatever.

The engine uses AGS-style hotspot system, and sends string messages, or events, whenever mouse cursor interacts with something, or player enters a region etc.

You parse those messages in "room scripts" through simple switch statement or by using more Sierra-like if said() function calls. Other game events can also throw messages. For example, "room entered" message is thrown on room entry and you can use it to initialize stuff before the player takes control.  Anything that can be scripted in GM can throw a message to the script parser.
This message style is actually a byproduct of the game initially intended to be fully text parser controlled, AGI style.



And here's the room script that's used in the video:

Code: ags

scr_gui_gameroom(); // Runs GUI script separately to keep this one clutter free, actor scripting only.


switch (msg_line)
{
    
    case "room entered":
        scr_define_room_gui();
        actor_set_state(Sam, state_sam_idle);
        cursor_set(cursor_walk); 
        gui_activate(gui_main_bar);
    break;

    case "look at the city":
        cursor_set(cursor_none);
        actor_set_state(Sam, state_sam_walk);
        actor_path_to(Sam, 166, 178);
        actor_set_state(Sam, state_sam_idle);
        wait(0.3);
        txtbox("The city was following the sun into darkness.");
        cursor_set(cursor_look);
    break;

    case "look at Sam's building":
        cursor_set(cursor_none);
        actor_say(Sam, "Yes...");
        actor_say(Sam, "It's my building. I like my building.#My building is very nice.");
        actor_say(Sam, "And this is a#three line#sentence.");
        cursor_set(cursor_look);
    break;
    
    case "look at large key" :
        cursor_set(cursor_none);
        actor_set_state(Sam, state_sam_walk);
        actor_path_to(Sam, 155,190);
        actor_set_state(Sam, state_sam_idle);
        wait(0.6);
        actor_say(Sam, "It's a key of some sort.");
        cursor_set(cursor_look);
    break;
    
    case "use large key":
        cursor_set(cursor_none);
        actor_set_state(Sam, state_sam_walk);
        actor_path_to(Sam,170,190);
        actor_set_state(Sam, state_sam_idle);
        actor_add_item(Sam, "large key",spr_inv_key, 1);
        prop_deactivate("large key");
        txtbox("You take the large key.");
        cursor_set(cursor_use);        
    break;
    
    case "use door":
        if flag_is("sam's door", "locked") txtbox("The door is locked.");
        else if flag_is("sam's door", "unlockable")
        {
            actor_set_state(Sam, state_sam_walk);
            actor_path_to(Sam, 321, 140);
            actor_set_state(Sam, state_sam_idle);
            txtbox("You unlock the door.");   
            flag_set("sam's door", "unlocked");
            actor_remove_item(Sam, "large key");
        }
        else
        {
            txtbox("The door is already unlocked.");
        }
    break;
    
    case "talk to door":
        flag_set("sam's door", "unlockable");
        txtbox("Open sesame!");
    break;
    
    case "talk to large key":
        actor_path_to(Sam,170,190,true);
        gui_deactivate(gui_main_bar);
        cursor_set(cursor_opt);
        conversation_start(conv_large_key, gui_conversation);
    break;
    
    case "actor entered door-to-agnes-office":
        fade_out();

        scr_actor_to_room(Actor, rm_agnes_office, 32, 180);

        if (Actor == Player) {
            //actor_set_state(Player, Player.idle_state);
            switch_room(rm_agnes_office);
            }        
    break;
    

    //inventory items
    case "item item1 door":
    case "item item2 door":
    case "item item3 door":
        actor_say(Sam, "I can't use that on door.");
    break;
}

Scripting system is based around command-queue which exists on a timeline. Each timeline has it's own command queue and is detached from others unless you instruct it to wait for certain event on another timeline.
So you can for example have characters in the background who go about their own business, until player triggers an event which interrupts them and brings them on the same timeline as the player.
You can have as much of those timelines as you see fit.
Commands themselves can be blocking (timeline waits until the command is finished) or non-blocking (timeline continues as soon as command starts). This is essentially the eBlocking parameter from AGS.

Everything is done in GML standard scripting language and should work on all platforms GMS runs on, including mobile and HTML5. It requires Gamemaker to work obviously, which is free for Windows, paid for other platforms.

Current status of the framework is functional-alpha. Most of the essential stuff is in there, save-game system is in progress and I'm considering adding support for localization where scripts get exported AGS style, ready for translation and then get imported on load.
Apart from that, it needs lots of polish and quite some bug extermination.



Since this thing has kind of outgrown itself and is getting harder and harder to maintain in my spare time, I'm on the edge of declaring it my job and going either for a crowdfunding campaign or selling it on itch.io or something. It would certainly help me with my game issues and in the process I'd be helping others create their own games.
I also have grandiose plans of developing it further into a full standalone product, but that is the topic for another conversation.


Thoughts?
Ideas?
Insults?
Torches and pitchforks!?

I discussed with CW and here is how he is sorting our options (I quote him):

There are 3 options:
1. Keep current code and improve it further;
2. Take existing engine and modify it to run AGS games;
3. Write completely new engine from scratch, which
  a) meant to run AGS games;
  b) meant to run more advanced games, but can emulate AGS games as well

I do not think dropping AGS Editor is an option, because if there is something that binds community, it is the first.
The Editor IS AGS.
Or rather the type of game creation workflow.

I totally agree with the editor point.

Could option 2 be a kind of medium way?
Keep the editor, choose an engine and tie them together?

I'd go with either 1) or 3).
The middle ground is neither here or there as you'd have to work around both the AGS quirks and that other engine's quirks. And engines do have quirks.

Regarding option 1) - It's the most feasible especially if it involves outsourced refactoring. Literally hiring a developer or company to forensically refactor the current code to a more modern, multiplatform code. There are companies out there that port old software to modern platforms. SDL2 library was designed with this exact purpose in mind, among other things.
Feature wise, it's handing them AGS 3.4 and they hand back the ported AGS 3.5. End user sees little difference except all their stuff now works on many platforms. Workflow remains the same.
The obvious question is: How much?

As for the start-from-scratch approach in option 3), this is a more of a design issue than anything else and design is a tricky subject based on my limited experience in professional gamedev world. You just can't outsource design and expect good results back. Compared to the opt.1 where you essentially know exactly what features the code should have, when you outsource the code-less design phase, it's a money pit, a pandora's box that's better left closed.
The not so obvious questions in this case are: How? Who? When? etc...

Now, in case you have modern and modular code base from opt1 then it's much easier to consider other design issues and add new features.

Sorry, kind of got derailed off the track by my own train of thought....

The initial thought probably was something in the line of your reply - ie. making AGS less the hostage of whatever software library there might be.
Oh well, I seem to be in the revolutionary mood today , sorry for the misplaced rant again.

[Script]

Just one big IMO, and please pardon my ignorance as this was probably discussed already, but it just seems too obvious not to try it out, when there's the idea of developing an all new engine.

Perhaps the whole AGS concept should be re-engineered into more modular approach?
Go against the core paradigm of the integrated "studio" concept and instead focus on developing "modules"?

TL;DR version: develop an Adventure Game Script language. Similar to SCUMM+interpreter combination. Or like ScummVM that looks into the future, instead of the past.


Long version:
Separate the whole AGS into three main modules/components:

1) Scripting Language - what game IS. The current AGS scripting language. The new scripting language. Whatever it is, it is (almost) set in stone and changed only on centennial entmoots in the forbidden forest.


2) Visual Editor - visual representation of the scripting language. Define room backgrounds, sprites, walkable areas etc... In some more refined form, this editor could allow for code-less game development (like UE4 blueprints). But in essence, all that it does is visually organizing the scripting language. It's 100% not essential.
A subset of this could be an asset packer that produces a serialized asset data for direct use with the interpreter.


3) The Game Interpreter - what makes the game run on a certain platform.
This should be heavily separated from script development, and even more separated from any particular software library on any particular platform.
Since it's all open source, it's up to particular developer to develop their own interpreter. On PC, they may use Allegro, SDL. On iOS, it's Swift. It's ScummVM everywhere else, etc.

There are benefits and drawbacks of this system.

Benefit is the smaller scope of it all. Concentrate on the scripting language itself for start and ignore the visual editor completely. Hack the interpreter in Pygame and Python for all it's worth.
Once the structure of the scripting language is set, focus on the development of "proper" interpreter for Windows written in native C++ with full-out DirectX support. After that, it's time for OSX/iOS interpreter written in Swift.
The windows interpreter works, but OSX is buggy? Nevermind, here's the AGS 4.0 language specification - write your own interpreter using C and OpenGL directly. You want to port your game to ARM Linux? Sure, same download link. But you may want to try out ScummVM interpreter first.

You don't like the current visual editor? Here's the AGS 4.0 language specification link again - write your own. You want to port the editor to you Android TV.... you get the idea.


The biggest drawback is the fragmentation an approach like this would bring.
But fragmentation is given in any open source project anyway. This could be leveraged by only focusing on the scripting language specification and not actual implementation.

Because, and here's a big IMO again, the main focus of AGS development should be: "I want my actor to do this or that" instead of "I want my game to run on xyz".
This may seem ridiculous at first, but once there's a clear separation between a script and an interpreter; and there's clear language definition that negates reverse-engineering; and once it runs at least somewhere somehow - the implementation of it for running somewhere else will come naturally. 

Thanks everybody for feedback! It's extremely motivational, thanks again!

Your screenshots give me a bit of a Agatha Christie feeling

Well, this sent me on a introspective brainstorming. As others said, there should be zero A.C. in there, BUT!, as a kid I was heavily influenced by British crime TV series. Poirot, Sherlock Holmes & others. So, probably some of that came through when designing characters, their backstories and motives. Examining them now, there might be something, uhm... agathachristian about them.
But with heavy dose of post-war consumerism and brutal capitalism of an emerging world-power, of course. It's all about greed and money, you see.

In what style and medium of music are you interested for the game?

Great question, and one I've been procrastinating the most about. Music is currently 0% completed and I mainly know what kind of music I DON'T want. And that's period-correct but genre unfit big-band and upbeat jazz music. None of that.

What I think noir soundtrack should sound like is atmospheric, non-intrusive, ambiental style. Period correct instruments should be present, but I wouldn't mind synths as well. Yeah, I know - Blade Runner, Vangelis - but that music is timeless and sounds as good as it did in 1980-something. And it fits so good in adventure/rpg gameplay.

And it all should have the nostalgic effect of iMuse on SoundBlaster 2.0 in 1992, only better!

Duje, it's looking great so far.  The more up-to-date backgrounds are very evocative. Funnily enough I also kinda like the place holders - there's something of a kind of old fashioned virtual reality feel happening in them.

That's what I say! What one might see as 21st century crappy pixel art, someone other might see as beautiful image of the future! In 1982 that is. It's always that damned time-space continuum! Meh.

Liking the look of that update there! Looks like this one is going to be a lot of fun to play. Multiple playable characters, by any chance?

Thanks!

Multiple playable characters... kind of. There will be couple of playable characters, but in different, self-contained, sequences.
There is only one playable character at any moment, and that's mostly Sam Preston, PI.

Finally, an update!
Edited the first post.

You are late, doimus!

Erm... sorry...  I'll do it when they make One Hundred Billion Dollars!!!!

US examples are most prominent as the US is at the forefront of both gaming and warfare  , but I guess it should be relatively the same in all countries where there are similar law systems.

I hereby reserve the right to post Dr.Evil image in this very post when they reach.... one.... million... dollars!

AFAIK, military equipment is clear as long as one uses military (government) designations. These designations are somewhat already yours, as you paid through tax for them. 

Stuff like M16 is fine (military designation) but Colt AR15 is not (commercial designation of the same rifle). UH-1 Huey is OK (military) but Bell 212 (commercial name for the same helicopter) is not.

There was a similar case recently between Bell (the company that produces helicopters) and EA. Bell wants money from EA for using their helicopters in Battlefield 3. Don't know how that one panned out. Might be worth googling about.

LOL, I just looked at it, and they're at $392,000 out of $400,000 needed. 33 days to go.  

And, man, even Cookie monster approves this! I'm so backing it now!

Regardless of CJ's dogma (or not) with wanting more "permissive" licenses than the (L)GPL used, it is a pragmatic move to do so. As has been noted in other threads, the use of the GPL/LGPL can cause problems with other software libraries (primarily commercial ones). And while yes, most "permissive" licenses like MIT allow for closed source forks, the GPL does not exactly forbid this either (for internal/private use, for example).

Thanks for this clarification. That's one pretty serious limitation of GPL-ing the code, IMO.