Messages

[EDIT : everything that is written in this hidden section was my original post but you should not consider it my opinion -- it was more of a conversation starter and has been contested. The table is better.]

Following post-mortem this thread and all the previous threads http://www.adventuregamestudio.co.uk/forums/index.php?topic=55657.msg636578880#msg636578880

Spoiler

EDIT : everything that is written in this hidden section was my original post but you should not consider it my opinion -- it was more of a conversation starter and has been contested. The table is better.

I'm starting this thread in this forum for two reasons :
1) there was no thread dedicated specifically on MonoAGS
2) This is virtually a sub-thread to the "AGS 4"  thread (aka "why this project is screwed up"), only dedicated to MonoAGS as one of the many options.


What I like about MonoAGS

• It's started by one (seemingly skilled) person, who has leadership
• he sources are immediately available on git.
• Some thought has been given to follow in AGS legacy (programming-wise). Specifically: Not being unncessarily anti-Microsoft, while still focusing on cross-platform tech
• Some thought has been given to having a good, flexible scripting language (i.e. C# as a scripting language that can still be compiled separately from the engine or Editor source)
• Some effort in the documentation

What I don't like about MonoAGS

• The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.
• It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.
• It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

What I don't know about MonoAGS

• Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click

Apart from that,I have no opinion on the switch from Mono to .net Core. That's a side discussion.

There should also be threads to discuss Blade Coder and Adore.

[close]

Engine	AGS	Bladecoder	MonoAGS	Adore	Escoria	Placeholder 1	Placeholder 2
Middleware / underlying game engine	Allegro	libgdx	None	Löve aka Löve2D	Godot	Placeholder 1	Placeholder 2
Editor included	Yes	Yes	Not yet (plans on making things editable directy in-game)	No editor provided but many frontends suggested (e.g. Notepad++ with a plugin) See link in footnote	Yes	Placeholder 1	Placeholder 2
Platform/VM for the engine	None (direct  C++), but has binds to some Windows libs.	Java	Non-Microsoft .Net Framework, aka “Mono” (considers moving to .Net Core)	Lua		Placeholder 1	Placeholder 2
Platform/VM for the Editor	.Net framework	JDK required	Mono (considers moving to .Net Core)	-		Placeholder 1	Placeholder 2
Hardware supported	Windows desktops. Existing ports : MacOS (outdated) ]PSP Android iPhone(?)	All++ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)	All (but for subtle things meant for mobile devices such as tapping and accelerometer, you'll need extra code/libraries)	All+ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)		Placeholder 1	Placeholder 2
Engine's language	Old-school C with big chunks of C++	Java	C#	Lua		Placeholder 1	Placeholder 2
Editor's language	C#	Java	C#	-		Placeholder 1	Placeholder 2
Main libraries used (apart from DirectX+OpenGL which are included implicitly in most cases)	allegro 4	I don't know how much of libgdx is self-sufficient	OpenGL+OpenAL bundled in OpenTK	I don't know how much of Lua is self-sufficient		Placeholder 1	Placeholder 2
Proper versioning	Yes (git)	Yes (git)	Yes (git)	Yes (git)		Placeholder 1	Placeholder 2
Automated tests	No ?	?	?	Yes (“busted”)		Placeholder 1	Placeholder 2
Automated solution generation	No	Not needed ? (Java all the way)	No	Not needed (Lua all the way) ?		Placeholder 1	Placeholder 2
Automated build and release	No	Most likely	Yes	?		Placeholder 1	Placeholder 2
Native support for Photoshop (PSD) files	No	No?	No	Yes?		Placeholder 1	Placeholder 2
Localization mechanisms	Yes, up to 256 characters per font	?	?	?		Placeholder 1	Placeholder 2
Good manual + community + tutorials	Yes	Yes	Yes (at least it has some doc and a proper home page)	Yes but only one demo game		Placeholder 1	Placeholder 2
Maintainers	Approx.. 4	Many for libgdx,  +1 very efficient for Bladecoder, +approx. 4 from the AGS community if we go there	1 +approx. 4 from the AGS community if we go there	Many for Löve2D, +1 for Adore, +approx. 4 from the AGS community if we go there		Placeholder 1	Placeholder 2
Sound engine	Not really, apart from just playing sounds	Yes (libgdx)	Yes (OpenAL has good features, that tzachs has wrapped into MonoAGS)	Yes		Placeholder 1	Placeholder 2
Controllers input	Just the basic : keyboard+mouse (and joystick with a plugin)	Yes+ (including mobile device gesture)	Just the basics	Yes		Placeholder 1	Placeholder 2
Subpixel management / maths / vectors (see in an other post in this discussion what I mean by that)	No, apart from basic float management and the Tweens module	Yes+ skelettal animation out of the box	basic OpenGL stuff + everything that was ported to C#. Anything else has to be binded manually	Yes		Placeholder 1	Placeholder 2
Multithreading inside the game	No	Probably	to be implemented by the game designer	Probably, using Lua	?	Placeholder 1	Placeholder 2
Data structures / serialization / database-like processing	No, apart from arrays of structs	Yes (XML, Json and everything natively)	Yes? (classes from Mono and/or .Net Core)	Yes? (Lua has everything)	?	Placeholder 1	Placeholder 2
Pixel-perfect low-res graphics	Yes	?	Yes?	Yes?	?	Placeholder 1	Placeholder 2
Collaborative work / compatibility with versioning	Possible with scripts and rooms, but not recommended with the main game file (.agf) nor sprites library.	?	Editor doesn't exist yet	?	?	Placeholder 1	Placeholder 2
Game scripting language	custom (AGS script)	NONE YET	C# (but some people think that things are little too hard coded yet)	Lua	custom (Gdscript, aka something similar to strongly-typed Python)	Placeholder 1	Placeholder 2
dialogs scripting language	custom (AGS dialogs script)	Ink	C#	Lua	?	Placeholder 1	Placeholder 2
in-game GUIs	None/custom (poor set of native graphic controls)	Yes (offered by libgdx)	custom (partially implemented)	Lua libs	?	Placeholder 1	Placeholder 2

Escoria : https://github.com/godotengine/escoria/blob/master/README.md
MonoAGS : https://tzachshabtay.github.io/MonoAGS/
Bladecoder: https://github.com/bladecoder/bladecoder-adventure-engine/wiki
AGS: https://github.com/adventuregamestudio/
Libbgdx : https://libgdx.badlogicgames.com/features.html
Löve : http://www.love2d.org/
Suggested editors for Löve : http://www.gamefromscratch.com/post/2016/01/25/Editors-and-IDEs-for-Lua-and-Love-Development.aspx


Ink : https://www.gdcvault.com/play/1023221/Ink-The-Narrative-Scripting-Language
Java :
Mono : https://en.wikipedia.org/wiki/Mono_(software)
Mono versus .Net Core : https://stackoverflow.com/questions/37738106/net-core-vs-mono
Adore : https://github.com/CalinLeafshade/adore

1) relying on a cross-platform tech? If yes which one?
2) which is the licensing Of that underlying tech ?
3) Is that underlying tech  only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is that underlying tech  only a game engine or an Editor too?
5) How old is each of the few central underlying tech or lib (name them) and the main project itself ?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?

Answering for MonoAGS:
1. Yes
2. Kept the same license AGS uses.
3. 2D graphics, GUI and audio (no 3D planned in the near future).
4. Working on an editor.
5. New.
6. I list all the current dependencies here. They are all actively maintained. I do plan to do some changes to that in the not too distant future (switching from Mono & DotNet framework to Dotnet Core, and using FFMPeg for both audio and video are the 2 big changes I want to make).

@tzachs not accurate enough! could you please have a look at the bits I added in italics in the quote above?

Firstly, only my two cents: I think that only people who know about IT (at least) and programming (at best) should jump in.

I agree on the list below, although I'd argue about "only IT people", because before you make a tool you set up goals for this tool ,and that goal usually relates to needs of potential users. What I mean, the list of "things" also need to include something from gamedesign perspective as well.

OK, but then even that should be rationalized as a poll:

"sort the features below by order of importance: (each point receives a unique number going from 1=most important to n=number of questions=least important)
- AGS games working on Windows
- AGS games working on non-Windows Desktop OS'es
- AGS games working on Mobile devices?
- Same 3 questions for the Editor
- AGS having primitive 3D abilities or at least abstract rendering surfaces (to make it clearer: useful for modules that manage walkable areas, downhill walkable areas, layers, parallaxes, cast shadows, rain/particle effects, and to a certain extent Tweening, etc.)
- AGS being good at hi-res graphics and/or video-like animations (lots of frames and alpha), smooth sprite movements
- AGS being good at pixel games (no blurry or artifact effects caused by window sizing or sprites alignments/scaling)
- AGS being able to emulate 8-bit games
- sound engine (ambiant loops, localized sounds, etc.)
- talkie games (dialogs and sound assets management)
- collaborative game-making (primitive versioning + file merge + maybe permissions)
- etc."

In addition, my intuition is that the answers provided by people who have actually already released a game should have more weight. And the answers from people who made commercial games should have even more weight. (Obviously, not because they are "more important" but because we can assert that they had more pressure to make a game that actually works and appeals to the players)

[table]

imho I think that we should rationalize this.
Firstly, only my two cents: I think that only people who know about IT (at least) and programming (at best) should jump in.
Secondly, I think we should avoid the usual neverending thread of "opinions". We should have a neat, proper table of all the pros and cons of each project and/or underlying tech, with boxes to tick: The following quesitons come to mind immediately:
1) relying on a cross-platform tech? (yes/no)
2) which licensing?
3) Is it only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is it only a game engine or an Editor too?
5) How old is the tech?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?

so on and so on.  Really, I think the table presentation would help a lot to assert the amount of "invisible tweaking" required. Everyone who's been a developer knows how huge can be the gap between something out-of-the-box and something that requires to integrate several technologies, study how to build it (on several platforms), study its limitations, clearly see the "little things" that are missing, study the maturity, etc.

Is there a forum thread that deals with AGS 4? Not a thread to discuss what it "should" do, but a technical-ish thread discussing what's currently in that branch? I couldn't find anything.

I'd say the first strong leadership decision to take would be to state : "starting from this date, we stop upgrades to AGS 3.x". All of them. AGS 3 is dead. All in favor?

Welp. If you really insist on not seeing your true merits, then I can't stop you ;-) but I think you're wrong to rain on your own parade.

I would like to say something important though. I really mean it:
What you did, CW, was not useless. It was not useless. You can be extremely proud of yourself.

You (and others) have made AGS live through Windows XP, Vista, 7, 10! What it means is that, during close to a decade, there was a tool that was doing (almost) perfectly what it was designed for. Thanks to you. God knows what have might happened to the community if the working branch has been put "on hold" for a full refactoring? It might have died. People might have lost interest. They might have stopped their game in the middle of development. I'm not only thinking about games such as Gemini Rue, but I'm even thinking about games like "Indiana Jones and the Fountain of Youth" which very recently switched to Unity. Without a continuously working AGS, these projects might have died.

I'm perfectly aware of how 20 years of spaghetti code can kill AGS on the long run. But I also know how a rewrite from scratch could have killed it instantly. We'll never know how things could have went. But we know how they did go: AGS kept working almost smoothly for 10 more fucking years. Amazing.

So, thank you. Thank you thank you thank you.

Please feel free to PM me any question and

Haha! All you had to do was to say: "Ooh! Ooh! Pick me! Pick me!"
I'll send you messages.

[Astronomy consultant wanted]

Astronomy consultant wanted

We're going to have several puzzles revolving around astronomy.

By astronomy, we mean those sorts of concepts :
- constellations (both north and south hemisphere)
- what's the equinox, the azimuth, etc., and have a vague idea of how they might be included in calculations -- either to predict earth position, or constellations/planets/positions...
- how it potentially relates to the time of the year or to the actual year (can one hypothetically tell what year it is just from looking at the sky?)
- what are the planets that can be seen with the naked eye, what can be deduced from just looking at the sky, what can be deduced from having instruments (and which types of instruments, such as astrolabs and stuff)
- etc.

- Bonus: some very rough knowledge in the history of astronomy -- South American Mayan stuff

Your knowledge should not be necessarily very advanced. It can even be very basic. But you must have (very rough) ideas on all of that.
We'll probably ask you specific questions from time to time, to have clearer ideas in terms of what's possible or not in terms of puzzles.



PS: just to be clear, we're talking astronomy, not astrology. I mentionned the constellations becvause they're an important part of the sky map.

I tried script resample and it's super slow for what I need (There were about 800 dynamic sprites in the end, generating them took about 11 seconds). Maybe I could optimize that somewhat and/or stick a loading bar on it, but getpixel/drawpixel doesn't work with partial transparency.

Now that I've seen how terrible script resample looks, plain old pixel resize doesn't look so bad anymore.

Alternatively you could use the Lua plugin, which could probably let you tap indirectly into direct3D, onto which you could unload the mainprocess of resizing. Or, worst-case scenario, bulk-process arrays of pixels.

Would you be kind enough to add a small paragraph with a link to this on the wiki, on the Fonts page?

I always put my watch variables on a GUI label

Sorry for digging up, but that fits into this conversation: This solution would work only for labels, but not buttons, because buttons get "grayed out" (actually, the gray grid pattern if they have an image, or a light gray color if they have text). Which leaves the need for a pleasant user interface when freezing the game intact.

Sorry, should've elaborated more on those in the first place!
(...)

Thanks A LOT for this.
And now, you "shouldn't" have. But the fact that you did anyway makes you awesome

What you can do is create a few more walkable areas in the distance, with a lower walking speed (and lower walking animation aspeed)

...Or use this module for "better" timers

Timer v3.01 http://www.adventuregamestudio.co.uk/forums/index.php?topic=28979.0

Just to make sure I follow along: the res and g variables is just a way to keep the different channels contained, so that you don't overflow or underflow, spilling over into one of the other channels?

I do not remember tbh, this may be done purely as a speed optimization.

I'm pretty sure Snarky guessed right. CJ does calculations that makes him unsure about the result value in case things go wrong, but the thing he's sure about is that result value cannot be that bad that it exceeds an 8-bits overflow to the left (the result can't be off more than a 256 factor). Therefore he creates some sort of 8-bits long safe zone inbetween Red and Blue (0xFF00FF). Then he calcultates Green inbetween separately. Then he applies the mask again just in case the values have overflown to the left (res &= 0xFF00FF; g &= 0xFF00;). And then he just merges everything together.
)

This look slike the kind of game that could be interesting enough to make the player forget its simple graphucs

If you want a better control over the fading, have a look at how it's done here : http://www.adventuregamestudio.co.uk/forums/index.php?topic=48583.0

Snarky is right. In a nutshell :
1) you're confusing 8-bit consoles with 8-bit graphics : what you're aiming at is 8-bit graphics (the games you named are evidence of that). In other words: about 256 colors on screen.
2) You don't need "real" 8-bit graphics unless you want to achieve the one effect that only 8-bit can do: palette scrolling. If you don't know what that is then you don't need 8-bit graphics.
3) Conclusion: Go for 32-bits graphics but then limit yourself to 256 colors or slightly more and you game will look 8-bit.

Easy!