Why isn't there a serious, modern Adventure Games engine?

Monsieur OUXX · Sun 04/12/2011 22:57:24

Quote from: Ali on Tue 01/11/2011 12:51:16
I thought it was somewhat relevant to this ol' thread.

Yes it is, and that's great news.
I'm still investigating how to adapt Blender GUI to my specific needs (it's like the awkwardness of their GUI and Python API is hard-coded, despite their huge efforts since 2.5

)

===

Just for the record, this one went under the radar but it seems very dynamic: http://jmonkeyengine.org/

It's both a set of libraries and an IDE. It's comibning low-level stuff (Ogre3d) and high level (Java)
It seems rather (very) good, even though I definitely want to go for Blender, as it's the ultimate solution for including a modeling tool directly in the game editor.

Anian · Mon 05/12/2011 02:05:21

Uuu, and this is from Ogre family, seems simple to use (because it has visual scripting to some extent) plus it has a lot of good thing from Ogre engines
http://www.openspace3d.com/

David Ostman · Mon 05/12/2011 11:59:46

Unsure how many have noticed this, but Theo/Skygoblin left AGS and developed their own adventure games engine, Gobby, for the development of The Journey Down HD, and the blog post outlines some stuff that might be relevant to this thread.

I searched this forum for "gobby", which brought up an unrelated thread, so I'm guessing this hasn't been discussed much yet?

Lewis · Fri 09/12/2011 17:26:25

[Replied to the wrong thing, can't find an option to delete. Bah!]

Sslaxx · Sat 10/12/2011 15:04:19

Quote from: David Ostman on Mon 05/12/2011 11:59:46
Unsure how many have noticed this, but Theo/Skygoblin left AGS and developed their own adventure games engine, Gobby, for the development of The Journey Down HD, and the blog post outlines some stuff that might be relevant to this thread.

I searched this forum for "gobby", which brought up an unrelated thread, so I'm guessing this hasn't been discussed much yet?

They're a commercial company. It isn't likely that they'll be releasing Gobby for public use. And really, nobody knows very much about it beyond what's been said in that blog post, although the tech they're using is good seeing as they're interested in cross-platform compatibility. So yes, it does appear to meet the criteria of "serious, modern adventure game engine" but you or I are not going to be getting our hands on it. Then again, we never got our hands on SCI, AGI, MADS etc. and they were reverse-engineered...

David Ostman · Sat 10/12/2011 18:56:19

Yeah, I wasn't thinking they'd release it for the masses, unless they set up some kind of licensing arrangement, but that's a hassle that might be more effort than it's worth to support.

Just brought it up as it could perhaps inspire anyone who's looking in what it takes to cobble something new together

markus · Tue 13/12/2011 09:27:06

As the person responsible for creating Gobby over at SkyGoblin, I can honestly say that, from what I can tell from what it is you're looking for in this thread, I doubt Gobby is it. It's not a generic tool for creating adventure games and we haven't really written it to in any way compete with AGS. I doubt it'll ever be possible to create a game in Gobby without a lot of knowledge in C/C++ and, depending on which platforms you intend to deploy on, some knowledge in Java, Android, iOS and Objective C. We're also a 2D engine and though it would take little time to add the rendering code to render 3D assets, we have no tools and no content pipeline for assembling them. As I'm sure most of us here already know, core engine technology's a very tiny piece of the puzzle when compared to the tools needed to assemble a game.

With that being said however, we're in no way precious about Gobby and I can't really see any reason not to share it at some point down the line. If someone else should have an easier time building a game of their own using our technology, that's a good thing and something we would very much like to encourage. At the moment we don't really have the time to package any of what we have into something coherent enough to be understandable for anyone outside of our office, but if there is serious interest in making use of what we have at a later time when we're not quite as bogged down in our own work and the code wouldn't just gather dust in a sad and lonely repository somewhere on the Internet, we'd gladly share what we have.

Peder 🚀 · Tue 13/12/2011 17:15:50

I'd love to get my hands on Gobby (GobEd?) sometime in the future, even if just to have a look at it.

Snarky · Tue 13/12/2011 18:13:35

Good stuff, Markus! Knowing your generosity I suspected you wouldn't mind sharing your engine, but didn't want to assume.

You mention on the blog that you made some design decisions with Gobby to "adress the different nitpicks Theo had with AGS when developing the prototype for The Journey Down." Can you explain in a little more detail some of the things you decided should work differently? For discussing future AGS versions it would be very interesting to hear what the pain points are now and how you fare with other design alternatives.

Also, when you say that developers would have to know C/++, does that mean that the game logic is written in native code rather than a high-level scripting language? I thought that was quite unusual for an AG engine, but I suppose if you're a small team who all know C it won't mess up your production pipeline.

theo · Tue 13/12/2011 21:17:12

I'd rather see Markus answer the techy questions but I'll gladly share one major difference between GobEd and AGS which has made my life (and Henrik's) one bajillion times easier:

Sprites aren't imported into the editor with weird ID's. They are called upon with one single thing and that is their location and filename -there is no weird abstraction in between the original asset and the one used in the engine.

For a "common" AGS user who builds smaller games, this wouldn't really be an issue. But for a larger production with literally thousands and thousands of frames of animation, being able to simply re-render our frames into the same folder as the originals and then just hit run and see the changes... is absolutely invaluable. Also, since we don't have to rebuild the sprite file every time we start up after adding assets, we save tons of time every time we start up the game. Again, not an issue for a smaller project, but JDHD in AGS took several minutes to start every time I made the teeensiest change in any of the sprites. That was a MAJOR disruption in my work-flow.

markus · Wed 14/12/2011 11:34:26

Theo has definitely mentioned the biggest difference in the workflow. During development, Gobby reads files directly from disk and our assets are referenced by their filename. This means that launching the game during development doesn't take noticeably longer than switching rooms in runtime. Also, we use virtual coordinates for everything which allows us to resample textures as we see fit as well as run the exact same room configurations on all screen sizes and devices.

We use a language called Angelscript (http://www.angelcode.com/angelscript/) for game logic. So far we've had very good experiences with it and I'm quite impressed by how easy it usually is to map C/C++ functions and objects to the scripting language (I wholeheartedly recommend it). Though we do almost everything from Angelscript, we write anything that's performance sensitive in C/C++. Since we iteratively create the engine and implement our scripts in parallell, the "engine" as a whole isn't really feature complete in a general sense and is more of a framework specifically tailored to the needs of The Journey Down. For instance, the Gobby editor is far from having the kick-ass "save-game-to-exe" feature found in AGS and creating a game requires that native code is written and compiled which uses Gobby as a library. All platforms require some C/C++, Android requires some extra Java to wrap the native code and iOS requires some Objective C for setup.

Ali · Wed 14/12/2011 11:45:20

Quote from: theo on Tue 13/12/2011 21:17:12
Sprites aren't imported into the editor with weird ID's. They are called upon with one single thing and that is their location and filename -there is no weird abstraction in between the original asset and the one used in the engine.

Aaah! I agree, this is the most frustrating thing about AGS workflow.

While Gobby doesn't answer all of the demands this thread has been making of a modern adventure game engine, the fact that you're approaching multiple platforms is distinctly modern. Good luck with the development!

Snarky · Wed 14/12/2011 13:08:38

Yeah, I also find the need to import resources into AGS to be a huge pain and waste of time, even in a fairly small project. Just the fact that you have to keep them organized in the file directory and then also in AGS is pointless duplication of effort, even if you rarely need to re-import them. Besides, it makes the project file a huge glob of binary data, which complicates source control.

I can see some of the reasons for it, like the processing AGS does on sprites in the input phase to pick transparency and to expand animated GIFs into separate frames, but I don't think it's worth it. Something like how Eclipse works, where the resource files live on your file system and you can choose to include or exclude them from the project (and perhaps set a couple of other parameters of how they're interpreted, if necessary), would be much more convenient. (For the AGS 4.0 wishlist!)

Eggie · Wed 14/12/2011 13:14:58

This wouldn't been a problem until a few days ago when I thought to myself 'Gosh, you know I REALLY should have used gifs instead of pngs before I imported these thousand images over the course of four years' in my big AGS project. I thought about going through and reimporting the sprites but had to drop the idea immediately, too much work, too much margin for things going horribly, horribly awry. The filesize of this game is going to much much bigger than a game of it's length should be.

Snarky · Wed 14/12/2011 16:12:15

Really? I thought AGS stored sprites in its own format internally, so the source file format shouldn't matter.

Besides, a well-compressed PNG file shouldn't be any bigger than a GIF; rather the opposite. But Photoshop, for example, produces bloated PNG files, and you can use an app like PngCrush or PngOut to losslessly reduce the file size.

Shane 'ProgZmax' Stevens · Wed 14/12/2011 22:06:59

I've always used gifs for my work in ags, primarily because of its support for animated sprites. This is also the main reason why I never went with wintermute since the author made it clear to me in no uncertain terms that he'd never support animated gifs. Importing a single animation rather than a sequence of frames as separate images saves me considerable time in the importation process.

That said, conversion/compression of art assets could certainly benefit from being done last (as a precursor to distribution) so builds could be compiled more rapidly, though to be quite honest I'm working on games with LOADS of sprites and the compile time has never taken more than 30 seconds, though likely mileage will vary based on your cpu/fpu and ram.

I was pretty intrigued by the screenshot of your editor that had the walkable areas and so forth defined with user-defined polys; I think that's an absolutely grand idea and one I used when I was building my now-defunct game engine. Is there a limit to how many points a shape can have in the editor? I'd like to have a look at your editor some time!

Snarky · Wed 14/12/2011 22:47:33

I've never really understood why you find it quicker to import GIFs than PNG sequences. AGS can import a series of images in couple of clicks now, so where do you save time?

Anyway, if we didn't have to import the sprites at all, just put the files in a folder in the project tree, it wouldn't be an issue any more, right?

Polygon-based walkable areas is another good idea. For one thing it would really simplify the pathfinding, and you could do things like overlapping walkable areas.

cat · Thu 15/12/2011 08:30:30

Quote from: Snarky on Wed 14/12/2011 22:47:33
AGS can import a series of images in couple of clicks now, so where do you save time?

Last time I tried this, it didn't work with alpha channel - also, in a 32bit color game it is kinda annoying to always have the messagebox if I really want to use alpha channel...

David Ostman · Thu 15/12/2011 11:14:06

Quote from: cat on Thu 15/12/2011 08:30:30
Quote from: Snarky on Wed 14/12/2011 22:47:33
AGS can import a series of images in couple of clicks now, so where do you save time?

Last time I tried this, it didn't work with alpha channel - also, in a 32bit color game it is kinda annoying to always have the messagebox if I really want to use alpha channel...

If you quick import a series of PNG files with transparency they import just fine (they just look wonky in the sprite browser). Also, doing it that way there won't be a message box popping up asking you things. It's how I usually import sprites, even if it's just a single one.

Calin Leafshade · Thu 15/12/2011 12:15:57

The 'Import Multiple Sprites' thing uses the last options you used for a normal import, including the Use Alpha Channel setting