Messages

Dear all,

It took a while since it's been a very "quiet" /r place, but I've just been made a Moderator on the /r/adventuregamestudio Reddit.

It could be quite a nice way to help people promote their games in production / released games. I'd be happy to appoint other Moderators from amongst the active forum members here as well, so send me a message if you're interested.

Whilst I get to go by "Hobbes" here on the forums, I'm HobbesHK over there, just like on Discord (someone else beat me to my desired username on both haha).

If it helps, I can build an empty one? And then you can a lot your stuff into it?

The difficulty will be a Universal Binary.

Hi both,

Thanks (or: Dankjewel) for your kind comments!

Regarding Twitter, I'm not on there (have a work-related account but hardly ever use it), just not the platform "for me" I think. I might have to reconsider in the future, since it appears to have a very active indie community, but for now I'm trying to live without.

Agreed, further to that, at such a high compression rate (plus intensive codec like h264), it probably needs a beefy processor to play back smoothly. So actually a smaller video file might be detrimental if you intend to stick with 1080p. For example, the h265 codec produces smaller files than the h264 codec without quality degradation, but needs significantly more processing power to allow for smooth playback.

Further to that, I think 1080p h264 codec would struggle on any older PC, so I think your best best is to not use HD video if you intend to play the game on older machines. Rendering the video to the game resolution seems to be your best bet here?

[Introduction]

Introduction

Back in May 2021, I finished a short MAGS game called Fhaloness. That was my first time working with AGS again in a long while and rekindled my enthusiasm for this wonderful tool. I really enjoyed putting that game together and as many players figured out, Fabian and Sylvana's journey is far from complete.

Rather than starting "a second game" I've decided to add onto the original MAGS game. So I'll be re-releasing that game when it's finished. The MAGS entry will be rebranded to "Prologue" and the next new area will be called "Chapter 1". I've currently planned 5 chapters but may drop down to 4 if it turns out there isn't enough content to fill the game...

Onto some work-in-progress screenshots!

Screenshots

Inspired by my old-school love for Betrayal at Krondor, the game will come equipped with story-screens that either enrich the environment or offer a short mini-game (similar to what Pathfinder: Kingmaker and Pillars of Eternity have been doing).



Chapter 1 finds Fabian on his path to the city of Aeramor where he hopes to book passage to the Isle of Fhaloness.



In case you get lost, there's a handy map feature readily available in the menubar!



Travelling through the woods of Landerion is not for the faint of heart...



Yes, the game has a battle system!

Progress

Prologue:

- graphics 90%
- puzzles 100%
- scripting 90%
- music/sound 90%

I'm reworking some areas of the prologue to fit in with the wider narrative, so some work has to be done...

Chapter 1:

- graphics 30%
- puzzles 80%
- scripting 40%
- music/sound 10%

Chapter 2 - 5:
0% (Apart from some plot outlines and puzzle ideas!)

Closing notes

As I've been working on this game, it's evolved into a RPG/Point-and-Click hybrid game. I'm really quite proud of the fact that, being such an amateur scripter, I've been able to put together a fully functional battle system (with 12 character levels) using a simple variation of the d20 System, including a levelling up system, a skill-based system (for some interesting dialog options as well).

Since this is a passion project I'm only able to work on in my free time, I'm very hesitant to put any deadline on this one. By breaking the game up into smaller chapters I know it's much easier to hit milestones, which works very well for me. So Chapter 1 is manageable. Right now I've scripted the whole game sequence, but there's an awful lot of drawing, composing & writing still left to do. All core systems are in place, all room transitions work, puzzles function, but it's very, very bare bones.

If you want to help...

Please, please help me spread the word, in any way shape or form. If you want to tweet about this game, please do. The current version (Prologue only) is available on Itch.Io. Please follow me there, leave a comment, anything to help raise the profile of this little game. I'll be sharing more and more updates as we move forward.

I look forward to hearing your thoughts on what I've cobbled together so far. 

Hi Crimson Wizard, thanks for your response!

I had figured out how to do this with the FadeOut one. I think in particular I was looking for a way to slow down the other screen transitions (dissolve one in particular). Is that possible in the engine too?

Hi all,

Quick one - is it possible to easily slow down a screen transition? I know how to do it with Fading Out, but I'd like to slow down eTransitionDissolve for one particular scene.

Is there an option to set the speed for this single instance, which I call with SetNextScreenTransition?

As always, thank you again!!

I think I answered my own question here: SDL2 has a Metal renderer.

So with SDL2 coming into AGS, we would have full support for OpenGL, Metal & DirectX. Which is great. So never mind me. :-)

Thank you so much Crimson Wizard, that's working a treat! I've got my virtual dice rolling in different places without any difficulty now. :-)

Newwaveburritos, happy to write it up in the future once I've got it working... it's a really nice trial-by-error mess at the moment though.

Using some of the excellent suggestions found in the topic above (making an RPG system in AGS) I've decided to try and script a simple turn-based battle system. So far so good and I feel like I'm making progress.

I've decided to use a very, very simple derivative of the d20 system, where I use a selection of dice to calculate results. So 2d6 for example, would generate a number between 2 and 12. (2 x 6-sided dice).

To help keep these functions to a minimum, I've created a number of functions in the GlobalScript.asc document of my game. So for example, for a d4 I've scripted:

Code: ags

function roll_d4()
{
  roll_value = 0;
  d4=Random(3);
  d4++;
  roll_value = d4;
}

This is working fine and is giving me a random number between 1 and 4. It's generated first as the Global Integer "d4" and then moved into the global integer "roll_value". This because at some points I will want to combine odd dice together (a d4 + a d6 for example) so the overall "roll_value" is consistently called to provide outcomes.

So far so good and I've tested this and it's working fine when I call these functions from a GUI button.

Now we get to my problem. In my current Battle Room, I would like to call these functions from within the room script. The reason is that I "set up" the monster based on a monster_id which is set before the player enters the battle room.

So if monster_id = 1, then a certain monster is loaded (hit points, attack points, character view, attack view, etc). If monster_id is 2, a completely different monster is loaded onto the same character with different variables.

Now, my monster_id 1 has hit points ranging between 2 and 8 (2d4). I've created the function roll_2d4 in my globalscript file and would like to call it from within the room script: function room_Load()

When I try to call roll_2d4 (which isn't defined as a function in this specific room), AGS can't compile and gives me the error "Undefined token 'roll_2d4'."

Now I'll be using roll_2d4 in quite a few different rooms and scenarios (dialogue checks, difficulty checks, etc) so I don't really want to script my whole dice-setup every single time I want to call it somewhere in the game. I thought the GlobalScript was the best place for this, if I wanted to script custom functions that were accessible anywhere. Am I doing something wrong, do I need to import the GlobalScript function somehow into the room script before I can acccess it? Or should I store these dice-rolling functions elsewhere?

Any help you can give would be greatly appreciated, as always. I fear I am getting overly ambitious with this little game, but I'm having a blast trying to come up with a battle system and building a bit of an adventure-rpg hybrid game. So any help people can give would be most welcome.

Thanks again!

Oooh, good news, congrats! Was it something MacOS-port related? I'm curious to hear what the issue was in the end?

Me again. With a crazy idea. Again. 

I'm absolutely in the dark as to how feasible this is, but would it be possible to build VULKAN support into the engine? It would eventually allow us to move away from DirectX9 (which is losing support and has been losing support for the past few years). On my AMD graphics cards, VULKAN performs much better than OpenGL and it also allows for some funky potential future features. Not that I think AMD FidelityFX Super Resolution should be anywhere near of a top priority! (I joke here, obviously)

The reasoning is that VULKAN is better supported on AMD than OpenGL & DirectX9, so it means a performance improvement (most likely) on the more graphically intensive games. Now that we see games branching into 720p+ resolutions, I think it's feasible to consider this.

Alternatively, as mentioned before, with MoltenVK there's then also the option to move towards native future-proof MacOS/iOS/tvOS development. For current alternative platforms (Nintendo Switch) I also think Vulkan holds more merit than OpenGL.

I would then recommend we keep DirectX9 as a legacy-supported feature (it'll go eventually), with focus shifting to OpenGL & Vulkan.

Does this idea have merit?

Dear all,

Thanks for the engagement on this topic - the more I look at these ideas the more it seems that there's a way to get it done, perhaps?

Eri0o, in true "me fashion" not knowing anything about programming, is SQLite the "easiest" way forward or would something like CastleDB perhaps be a useful alternative? It seems to be integrated into a different system, but the GitHub version is remaining open source.

Dualnames mentioned that his work on the Strangeland save system is available on GitHub (I don't know where exactly) but perhaps there's useable code there to integrate moving forward? Together with Fernewelten's suggestions from the previous thread, it seems that there might be a good path to try:

1. The idea of having a "base save" that saves the game's starting stats.
2. Save games track changes from that base save onwards.
3. Save game format: SQLite, current format, CastleDB, etc?
4. Editor mode to "Lock" when you do save-breaking stuff
5. Find a method of adding recognisable identifiers to all things that "need" saving
6. Add a "use new save system (experimental)" to Editor once we're ready to beta-test

Would that encapsulate all the conversations had so far?

Thinking about Dualnames' post the other day in the Strangeland topic I was wondering if it were viable to overhaul the save game system for an upcoming release of AGS? The current way it works breaks saved games when games are updated, which I would love to see fixed. Now I understand people program loads of custom functions, plugins, etc into AGS, so I see why the saving-memory approach is used. But could we perhaps consider adding in a second save-game-system that people can choose in the editor? It could be started as a "basic one" that collects:

- Integers (Global & Room)
- Inventory Items
- Characters & locations
- Player current room, etc

I'm sure there's loads of other things that would need to be collected, but the more we can build a save system that creates version-independent saves, the nicer it'd be. My personal reasoning is that I'm toying with a modular approach (episodic structure) for a game and would be releasing multiple episodes within the same AGS game (similar to how Life is Strange 1 and 2 were released, for example, or the Walking Dead games). Currently, if I were to release Episode 1 and people would save the game and I'd then release an update a few months later with Episode 2, their saved games wouldn't work anymore.

Would there be any merit to such a design? The Editor could allow a "use memory-saving system (stable)" or "use modular saving system (experimental)" whilst we work on it, for example.

Looking forward to hearing some thoughts on this feature request/idea.

Hi Dualnames, fascinating read! The amount of work put into fixing/working-around the shortcomings of AGS must've been quite a challenge.

At the risk of sounding cheeky, are you considering backporting any of the changes you made into the main AGS codebase? The new save system sounds like a wonderful addition for everyone, for example.

I'd be very interested in reading more pieces like this, thanks again for taking the time to write this up.

Hi Dualnames, I've got a Mac running Big Sur 11.4, so happy to help out if you send me the files?

I do think that with Big Sur / M1 changes, the link provided holds some outdated information. From what I've read in various places (can test this in more detail later) it seems that Intel / Universal apps (x64 or joint x64/ARM binary) can launch with the right-click-open feature. ARM binaries (Apple Silicon) "demand" notarization/signing unless every individual downloaders runs xattr -cr themselves, this to negate ownership issues, making MacOS go "OK, this is yours". Doesn't make any difference whether the download came from a ZIP or DMG, from what I can find out.

Hi eri0o, so sorry for the delay in getting back to you. I did exactly as you asked and the outcome of "file ./ags" is:

Code: ags

./ags: Mach-O 64-bit executable arm64

So it would appear we have success, an ARM executable! I just tried to run it, and it works flawlessly on my M1 Macbook Pro. So it works, when I use "Get Info" on the app, it tells me it's Apple Silicon (so ARM as well). This is great news.

The annoying thing for future reference is that people will need to fork out for an Apple Developer account and notarise/sign the app. MacOS is getting increasingly funny with running unsigned apps and everything on Apple Silicon has to be signed in order to run (unless you compile it yourself). Or you run the xattr -cr command on it, which is a hassle for non-command-line people. But that's a matter for another day, for now, it's great to see the future-proofing I was seeking is in place. :-)

If I run uname -a I get the following result:

Code: ags

Darwin My-MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64

I installed CMake through Homebrew so that might be the way to avoid any GUI stuff, since all that gives me is the CLI version. Worked a treat!

Eri0o, thank you so much for your investigation into the M1/Intel situation. I discovered I was running Homebrew through Rosetta and therefore got the Intel-version of CMake. I've now installed everything M1-native, but it seems that CMake will still only compile an Intel version of the game, not an M1-version. Not a big deal at this point in time anyway, since Rosetta2 is going to stick around for the next... 2 year I believe, at least. So we have plenty of time to explore this further as time moves on.

On that note, speaking as someone who has NO clue about programming, I have no idea how feasible it is to update the Mac version of the engine to Metal instead of OpenGL. The translation layer of MoltenVK (which is now open source I believe) only seems to work for Vulkan-to-Metal, but if we want to future-proof the MacOS port, then I think moving to Universal binary (Apple Silicon + Intel version combined) + Metal-graphics layer support (through a translation layer) would need to happen at some stage.

That being said, Apple has deprecated OpenGL since version 10.14 (Mojave) and it's not been removed for the past few years (since I think quite a few games/software packages rely on it). But the signs are there that OpenGL will get dropped by Apple at some stage.

A quick Google search showed up something like this: https://github.com/kakashidinho/metalangle as a potential solution, but since it's not an actively maintained thing anymore, probably not the right path to go down.

As a completely ignorant person when it comes to programming, is it "hard" to add Vulkan as a graphics driver to AGS Windows? Because then we could explore MoltenVK instead (which is actively maintained and has Valve-backing because of their Proton project on Linux).