Messages

Sad to see this fall through. Maybe we can find a couple of days this fall or winter to organise a meetup?

Yes, let's do that!

Well, that was fun

Spoiler

I would like it if the cool title music kept playing when viewing the credits.
In terms of balance, it may be nice if the initial character generation is less random; it makes me want to quit and restart several times until I get a decent character. For example, instead of four dice, roll two dice and take the complement of both.
I would like to see stat mods on the character selection screen.
It took me a while to figure out why the 'build' button disappears on most areas, or why I can't rest in the cul-de-sac. I was also confused that 'loot' sometimes is automatic (success or failure) without getting to roll for it.
Final idea: please add hot keys! Let the player trigger any button by pressing its first letter; this would make gameplay much easier.

[close]

This is not Linux though. So far this is the only user who has reported this problem; it seems to work fine for most people.

One player of Heroine's Quest reports, "In game when I move the mouse, it stutters then shoots off in one direction. Anyone know why?"  This person is not using Logitech Setpoint. Does this issue sound familiar to anyone?

The ESC issue is known: if the last key you pressed was control (or control+anything else), then the escape key won't register until you press another key first. This is a bug in Allegro and it could be resolved by migrating to a newer version of Allegro, but that is a time consuming process since the AGS code relies on certain older functionality.

Half-way through people! Any interest?

Also, I have cleared the backlog, so the MAGS site is now once more up to date. I'm planning to start MAGGIES 2013 in the next couple of days, if not today.

That's great!

If you have the time, may I ask you to do some tweaks on the MAGS site layout? In particular, on contemporary monitors I don't think it's necessary to restrict the screenshots to 80x50 pixels, or the important control buttons to 8x8 pixels. I'm sure this made perfect sense several years ago, but nowadays I think we can all handle full-sized 320x200 screenshots on the site, as well as buttons that are more practically sized. Just a thought

It is possible that you have a DLL conflict: that is, somewhere on your computer you have an earlier version of AGSteam.dll, and AGS tries to read that one instead of the more recent one (which should be in your Heroine's Quest folder). Can you run a search on your computer for files named AGSteam.dll, and see what it turns up? The dll you need should be dated April 6th, 2014; earlier versions do not contain the achievement functions.

I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).

That's really not the point. Just because certain things can theoretically be faster doesn't mean that AGS has speed issues. If you want pure speed, go program in assembly code. The question is whether AGS is fast enough for what it's meant to do (i.e. run adventure games, and possibly other games) and the answer is a resounding "yes".

Look, if you're going to make a case for fundamentally rebuilding AGS, start with practical arguments. As in, find some people who've been working on a large scale adventure game, and ask them what their actual issues were, and if they managed to create a game anyway despite the lack of a "switch" command. Ask if any of their players found that their low-resolution games were running inordinately slow on contemporary computers. Ask whether they found AGS hard to learn, and if they'd have had an easier time if its script had been based upon Turbo Pascal. Get a view of the real issues, not of hypotheticals.

The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.

Ah yes, that same core engine team that states above that they'll quit if AGS changes to a different scripting language. Sorry, I don't see how you have much of an argument here; hundreds of game developers and 100000s of game players have no issue with AGS's speed.

Speed and upstream support seem like the most obvious ones to me.

I've seen zero evidence that AGS has speed issues. In fact, I've done all kinds of crazy scripting within AGS (including writing first-person maze games and platformers) and based on this experience I'd suggest that AGS's speed is fine.

What Calin said. There's also (depending on the choice of language):

The thing you're overlooking is that AGS's scripting language isn't some weird arbitrary custom design. Rather, AGS's language is, for the intent of learning it, pretty much identical to C++, one of the most commonly used languages in the world (granted, there are some C++ constructs that AGS doesn't support, but nothing that would be used by somebody learning how to program). This also means it's very close to C, C#, PHP, and JAVA; meaning that any novice programmer familiar with any of those can pick up AGS almost instantly, and can use tutorials and coding samples for any of these languages. By constrast, LUA is known to substantially less people.

As far as I've seen, AGS ports just fine to Mac, Linux, and Android already, so I'm not sure what else you'd want to port it to. And I'm not sure why anyone would want to use AGS as a prototyping tool; it's an engine for creating games, not a prototyping tool.

Now I grant that it would be nice to use better debugging tools and be able to import standard libraries, but converting AGS to some other language won't actually accomplish that. Rather, I'd be curious to see what specific examples of debugging and libraries people would need. I'm willing to bet that simply creating these would be way easier than swapping out AGS's scripting language to something else.

Overall, you're suggesting a huge sweeping change, requiring huge time investments with clear and obvious drawbacks, for only hypothetical benefits. That's not a good tradeoff.

I really don't mean this as discouragement or criticism, but I wonder if all the energy put into hacking the scripting language might not be more usefully spent on other parts of the engine. The fact is that AGS Script isn't that unique, and we might be better off simply adopting a standard one with an existing compiler than having you spend so much effort trying to improve what we have.

That strikes me as a very bad idea, as it would throw out backwards compatibility with all existing games and ongoing projects, as well as invalidate most of the skill that our community members have developed with using the scripting language.

The AGS scripting language works, and has worked well for over a decade, and we've got a database of nearly two thousand games to prove it. There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.

Well done Ghost, and may our new alien overlords spare you!

Maybe I should learn C first?

Not particularly, no. Thinking in object orientation is a good skill, and that works better with C++.

It's ok if you don't get pointers; it takes most people years to get pointers. They're not necessary for most programming tasks, including game design. You'll build up experience over time, don't worry about it

Is your AGS executable installed under Program Files? Because under more recent windows versions, a program can't just write to that folder or any of its subfolders. Solution: move the demo game to e.g. D:\my games\demo

I started in GW BASIC (and later QuickBasic) making some simple platform games. I sold my first game over the BBS network. It didn't do particularly well, of course, but it was a great overcomplicated puzzle that me and my best friend spent ages writing levels for. Then years later, me and a group of fans got into personal contact with Richard Pini (yes, that Richard Pini) and we endeavoured making a game for them. That didn't work out either, but it did encourage me to study Computer Science and get the necessary background in programming frameworks. After briefly working in Visual Basic, I permanently moved to C++ (for which I eventually created my own graphical library written in assembly language) and Visual C++, of which the AGS language is a close cousin. With that under my belt, I finally managed to successfully launch a fully designed game, which was SubTerra; it was moderately successful and enough of a cult classic to show up at HOTU and similar spots.

[Jun-29 1700 Netherlands 2 vs 1 Mexico]

Jun-29        1700   Netherlands 2 vs 1 Mexico

Jun-29  1700 Netherlands 2 vs 0 Mexico

Netherlands 2 vs 1 Mexico

Netherlands 2 vs 1 Mexico

29-Jun Netherlands 2 vs 1 Mexico

Hah! In your face, Mexico!

Thanks. In my case, either 1-8 or 15-22, with the understanding that I'd only attend the first three days (1-3 or 15-17 respectively).

Sorry, I was without internet for a few days. This post was meant to state that I'm still in, but I doubt that my confirmation would have been enough to get this event uncancalled. Well, I'm sad to see this, there are some local AGS'ers that I was looking forward to meet. Should we perhaps reschedule for September?

And also,

http://www.adventuregamers.com/articles/view/26659

One player of Heroine's Quest reports that for him, the keyboard doesn't work; within the game, the keyboard is completely unresponsive, although mouse controls work normally. Since nobody else so far has reported this issue, this appears to be something in that user's computer setup.

That said, has anyone encountered something like this before? Any ideas as to what might cause it or how to fix it?

If you've enjoyed Heroine's Quest and/or our earlier games, please support our Patreon campaign to help us create more quality games!