AGS Awards nominations close at 13:59 GMT on Saturday 10 February 2018. You haven't yet nominated, so you've got 18 days and 9 hours left to play the games and decide which to nominate!

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.


Messages - Monsieur OUXX

Pages: [1] 2 3 ... 167
1
You mean AGS 4?

I support it.
I said AGS 5 to avoid creating confusion with the "AGS 4" cleanup branch, but it doesn't really matter.

2
Leadership decision to take :

AGS 5 based on this? Last call?

3
The more "external" code/tools/graphical elements you can embed in the game, the more development tools you can have for making games -- things you potentially wouldn't have thought about (graphic programming, dialogs editor, script debugger, etc.). This sounds perfect.

4
Here's my thoughts on the matter.

Let's look at this objectively:

  • The gaming industry is 100x larger than it was in the 80s/90s. This is considering the industry as a whole, including those casual gamers playing titles on mobile devices.
  • A very small percentage of that number are those who 'grew up' with point and click adventures.
  • A larger industry means more potential for sales, also more potential to get lost in the crowd of new releases.
  • We live in a society where attention spans are very low.
  • The core gameplay (or player interaction) of a point and click is driven by puzzles, something that requires a lot of patience and commitment from the player.
  • The majority of popular mobile and AAA games require little to zero effort from the player in regards to understanding narrative, let alone puzzles.
  • Media has become increasingly gratifying with the introduction of affordable CGI and improved *dramatic* narratives in television, a large majority are not prepared to invest in slow burning narrative (see above)
  • As time passes, less people are logging onto a PC when they get home. Average families favour sitting back on the sofa and playing mobile/console games, often with television running in the background.
  • Due to the lack of responsive gameplay, most point and click titles can be equally enjoyed by watching Let's Play videos.
  • We are in an age where most people are now used to googling problems they encounter in life, why would this be any different for puzzles in a video game?
  • A great deal of Point and Click games released are 'low-res' and the work involved in creating a higher resolution game requires a large team of very talented artists.
  • Low-res games are often overlooked by the larger majority of gamers and higher resolution point and click games are generally not financially viable for indie developers.
  • Most popular low-res games will have a unique gameplay mechanic not seen in AAA titles, often skill-driven gameplay.
  • The indie game market is over saturated but very healthy (and a viable option) in comparison to 10 years ago.
  • There is still a very strong and dedicated community of fans of this genre, let us not forget that.
  • People buy adventure games for the story, first and foremost - something that is very hard to convey in marketing media.
  • Quality visuals can go a long way when promoting a game on social media, try to tie this into the story.
  • People still buy adventure games.

THANK. YOU.
I was being too lazy to post this. This sums it up entirely.
Asking "what is wrong with the adventure games genre?" is like asking "what is wrong with books?" -- i.e. "why don't people read books in 2017?". Well, they do. Just not the same people, not the same books, not as many.

5
Quote
Quote from: Monsieur OUXX
I'm asking again : what's wrong with SharpDevelop?
Seriously? I've answered this (twice). Any reason for ignoring what I wrote there?

I've missed it (twice). Now I see it.

@eri0o : it wasn't clear to me that you were just mentionning Unity for its features, not as a candidate for AGS 5 underlying tech. When I started this "comparison of engines" thread I should have been more specific : comparison of strengths and flaws of technologies that might become the underlying tech for AGS 5.

I know that Crimson Wizard is interested in a top-down approach (features first) -- aparently, so do you. I started this thread with a bottom-up approach on mind (tech first). Let's meet halfway.

6
Doesn't the second post in the issue you linked to contradict your conclusion?

Maybe. The thing is that I wrote this message in a work environment where I couldn't open the link that I linked; I could only read its summary in Google. But the day before I did read several posts in several websites on the Internet, stating that VS Code is a "fake" free software. Anyways that settles it. "Really" MIT = OK for our purposes. Carry on ;)


Quote
Unity, Unreal engine
eri0o I fel like there is an ongoing misunderstanding about Unity and Unreal : I've stated several times that those are not suitable for our purposes for licensing reasons. But you keep posting about them. Unless we decide that AGS should be a Unity plugin and that AGS games will have forever the splash screen/watermark "made with free Unity".

I'm asking again : what's wrong with SharpDevelop?

7
VS Code is not brandable nor redistributable either.
Why not? It's open-source and released under the MIT license.

I don't think so; I think they made it misleading on purpose : https://github.com/Microsoft/vscode/issues/17996
It's written here and there on the Internet that the source code is MIT, but that the EULA states that the use of the software is still licensed, whatever that means.


If it turns out that VSCode is indeed free in every way, then it can become a good candidate. But some effort still needs to be put asap into packaging the thing with MonoAGS, which could be far from trivial.

8
Monodevelop is redistributable, isn't?
Yup, it's a mix of LGPL and MIT license. Alsoif I understand correctly it would still be c ompatible with .Net Core (if only using this http://lastexitcode.com/projects/MonoDevelopDnxAddin/ , or natively )

9
Editor Development / Re: Discussion on existing engines
« on: 11 Jan 2018, 08:28 »
Guys, thanks for all the feedback above. Lots of accurate things to move the discussion forward.

However there's one point that seems to be continuously misunderstood, which is Visual Studio. I'll say it more time : it does not matter if it's free (money-wise) when it's not legally redistributable, it makes it unsuitable for a packaged AGS. VS Code is not brandable nor redistributable either.

recap one more time :  a potential IDE must be :
Quote
- free (money-wise = zero dollars)
- free (license = you can do a commercial use of the game you make, you can extend the source code, and you can add the AGS logo on the IDE)
- legally redistributable (you can host it ont he AGS website and you can allow to copy it around)
- OPTIONAL BUT HIGHLY WANTED : portable (as in "no installer required")
- OPTIONAL BUT HIGHLY WANTED : lightweight (less than 50MB all included, no separate download/install required beforehand -- in AGS you'd need the .Net Framework, but everyone usually already has it)

SharpDevelop is all of that, VS is not, VS Code is not -- that's is why I'd like someone to explain why ChamberOfFear said it's outdated.

10
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 16:30 »
Right, Clarvalon has released an exporter to Xage (with source, apparently) which might be a good place to start.

True! I forgot about that. Brilliant! Damn, at the moment I work at a very restrictive company (and I have very very long days of work so I have almost zero free time once I'm at home). I can absolutely not toy around with any of that. #frustration :~(

I would strongly suggest to start orienting the amount of energy spent on MonoAGS onto the packaging part, so that a non-hardcore developers community has a chance to slowly emerge.

11
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 16:02 »
I believe this will require coding some kind of wrapper for MonoAGS to emulate AGS behavior.
I was thinking the same thing. The (small) thing is that MonoAGS doesn't have a parser for AGS script or loading AGS resources. So it might be simpler to do it on AGS side, as an exporter.

12
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 13:47 »
The fact of mentionning SharpDevelop as an option for the IDE suggests that not being really up to date with the .NET eco system.

@ChamberOfFear Can you explain how? Which specific point do I misunderstand? Is it only compatible with "traditional" .Net Framework? Is it compatible with Mono? Is it compatible with .Net Core? Is it out of support? Etc. It's free, portable, lightweight, under MIT license, and specfically targetted at C#, so it makes it a very appealing candidate.

@tzachs Any reason why you don't use Monogame as the "middleware" that other point-n-click engines use? (see initial table). It has recently switched to .Net Core and it has the most permissive Microsoft license. I know it was mentionned before but we never elaborated. It might not be too late.

Other question : do you use tools such as mkbundle or Monokickstart to bundle Mono in the current version of MonoAGS?

13
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 10:20 »
The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation.

Maybe I was being ambiguous in my previous post, but I hope it was understood that I wasn't actually suggesting that the user of the IDE was going to type commands, because that's just insane. The dotnet CLI tools would just be prerequisite to install, in the same way that the .NET runtime and Visual C++ redistributables already is for the current AGS. The actual command typing commands would be handled "under the hood" in the IDE. From the end users perspective it would still be a build and/or play button, like we already have.

I didn't have time to read @tzachs post since I'm at work so I hope I didn't say something that was already said.

That's good. I assume that CLI is also redsitributable, like VC++ rdistributables were. But the IDE needs to be redistributable (licensing) too. That was one of the strong advantages of AGS: lightweight, free and portable.

14
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 08:29 »
@tzachs : you have addressed all my worries, except for the IDE (second point below).

- About Protobuild : (btw, yes I meant multipe .csproj, not multiple .sln) you said you haven't experienced the pain of the multiple projects to maintain.
Out of curiosity, how do you currently work? Is it like this: You have the several .csproj in VS and when you build, it builds them all and you trust that is the MacOS project got built successflly, then it's OK? (not that Protobuild would address that paradigm -- just trying to have some context). The pain usually comes later, after seveal years, when you need to let users use a different IDE/Compiler or a newer version of the original IDE. You get entangled in the many versions of VS -- well not you specifically because you know how to upgrade your csproj, but there's always someone who asks about a version that you don't own -- and you cry.
 I mentionned VS but I'm perfectly aware that nowadays the VC++ restributable bullshit is gone, so don't hit back on VS. My concern can be applied to trying to compile a .csproj with any "unforeseen" IDE/compiler. That's when the automated project generation becomes a magical tool.
Just sayin'.

- About the IDE : still very skeptical. the statement "you could virtually make your game in Notepad" is not acceptable, but it's always something that's very hard to hear for developers. I could virtually make my AGS game in Notepad just by writing XML. Bleh. The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation. Finally, the IDE has a second purpose: organizing files and assets, and allowing thirs-party tools (plugins), as you and hamberOfFear mentionned.
Therefore, I'm asking again: what's the plan regarding a 1) legally distributable, 2) lightweight, 3) portable (no installer needed), 4) cross-platform IDE that would be rebranded "AGS 5"?
For now, MonoDevelop addresses these criteria, I believe, but is available from source only (!) and is apparently complex to turn into a portable installation. I'm not surprised that the Unity guys managed to do it, and make it seem easy, but they have way more time and money to achieve miracles ;)


15
General Discussion / Re: Trumpmageddon
« on: 09 Jan 2018, 17:17 »
Btw, it's uncanny how spot-on Snarky's predictions from 14 months ago are.
Hope that was tongue-in-cheek, Khris

the funny part is that Trump is already the  "short-on-expertise extremist/sycophant/charlatan" about whom Snarky is talking, if you compare him to literally any US politician before the 90's, even the ones from his own political family.

16
Editor Development / Re: Discussion on existing engines
« on: 09 Jan 2018, 16:46 »
Presumably the future IDE would be distributed with the dotnet CLI tools included, so that anyone would be able to build the game. If you need to code you could download you favorite code editor software, which most likely has a plugin for C# building. I have a hard time picturing a coder which wouldn't be delighted over the opportunity to use their favorite tool for game development.

All I'm saying is that you can't legally redistribute Visual Studio (true?). Therefore AGS 5 can't be shipped with it (true?). Therefore if we want to be serious, AGS has to be shipped with another, user-friendly way of building the game. I know programmers (I am one) love to say "here are the sources, all you have to do is..." but real-life people, especially AGS users, need to have an all-inclusive solution provided. Not to mention AGS is portable (it doesn't have to be installed).
MonoAGS has been made with Visual Studio so far, and we know how sometimes it's tricky to build a program in a different IDE than the one in which it was originally built. I'll believe it can be built with a free, open-source, redistributable, portable IDE when I see it.

@tzachs, a question for you : why did you put emphass on functional languages in the docs? did you have some advantage on mind regarding the making of a game with your engine?


17
Left aside all the sexist innuendos : very good pixel art, executed with a lot of taste. Very good colors.

18
Editor Development / Re: Discussion on existing engines
« on: 09 Jan 2018, 15:51 »
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.

Lol, right, Monsieur OUXX, I am pestering tzachs about this from the first moment I learnt about the engine.

I've read that in many of your comments, but I wasn't sure that I was targetting the "same" code separation, because here I'm specifically targetting stuff that wasn't even separated in AGS itself (blocking room transitions being the most obvious example)

Quote
Component-based
Yes, that's very good.

19
Critics' Lounge / Re: Main Character Critique Request
« on: 09 Jan 2018, 14:51 »
I don't think that knee bending works, I get tired just by looking at him standing like that.

It's not because of the bendig itself, but because his body balance is too far to the back. His center of mass (his hips) should be slightly more to the front.

20
Editor Development / Re: Discussion on existing engines
« on: 09 Jan 2018, 14:00 »
@tzachs : I finally got to have a look at your source code, and I must say it looks really really promising.

Here are my concerns :
- Like I said before, all my concerns about Sound Engine and about Assets Management are gone. Hurray!
- I'd still feel more comfortable if GUIs management was unloaded onto some third-party library like GTK# or similar,
- Keep an eye on (mild) reflexivity. One day we might want to make it possible to access objects properties through script* (for example, through an in-game console). Therefore, be careful with "anonymous" fields used by Protobufs/Protocontract. Oh wait this is actually C#. We can access an object properties through its name any time, any place.
- I suggest even more than previously the use of automatic solution generation, since I saw that you have one .sln file per target platform. https://www.reddit.com/r/dotnet/comments/6hmjrf/cmake_now_support_c/
- I'm kinda worried that there are platform-dependent wrappers for every core feature, such as drawing, input, etc. Isn't that managed by OpenTK? Or is it only some "transparent" wrapping meant for some basic C# trick (make advantage of interfaces or whatnot)?
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.
- event hooks! event hooks everywhere! E.g. OnNewItemInInventory
- Have you considered an importer for an existing AGS 3.4 project? --> That would be for the community. remember how many people had a hard time switching from 2.72 to 3.0?
- You have re-implemented all the usual classes such as lists, dictionaries, events, trees (you're literally using C#!), point, rectangle (you're literally using OpenTK!), etc. I won't complain because everyone does it (ScummVM, etc.), but... what is it with you people?
- One big big concern: the IDE as it is now, and even if you intgrate an "editor" as an in-game GUI, the game development workflow would be to run and debug the game from within Visual Studio. Even if it's a free Visual Studio, we can't redistribute it, which means that we must tell the users to download two separate things: 1) MonoAGS, and 2) Visual Studio. For me that's a no go. Any solution would be better than that -- like swapping to SharpDevelop or MonoDevelop. An answer that comes to mind is : "no, you misunderstood, first you compile the game in visual studio but then you can distribute the unfinished game to develop it 'from within itself', as some sort of standalone Editor" --> that doesn't sound like a good solution, because then you can't change (and recompile) any custom script inside it as long as it travels outside of visual Studio.

* Just in case you wonder why, here is one possible illustration : that could come handy for commercial games to automatically patch softlocks that many players might have in their saved game.

Overall I would like to congratulate you for how compact is your code.
Also, kudos for using async/await.

Pages: [1] 2 3 ... 167