Mittens 2018 will be in Boston this September. There are three spaces left, so check out the thread for details!

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 - tzachs

Pages: [1] 2 3 ... 54
1
I also think that any public domain asset should be allowed, though not sure how I feel about previously created assets (unless you make it public domain) -> and all assets should get the same treatment whether it's graphics, sound or code.

Now, for a little more radical idea, and I'm not even sure if I'm for it, but I thought it might be worth bringing it up for a discussion: what do people feel about allowing other game engines to participate?
It will bring more participants which equal more cool games, and might lure outsiders to join the community, and maybe try AGS one day.
On the downside, there's a sense of homey feeling here that's hard to describe, and it would be shame to see it disappear.

2
I'd also like to mention Chris, who would like to change the world. It's about making an impact, seeing how things you do in the world actually make a difference. If I steal a cake from a bakery, for example, maybe I can see the baker installing a home security system when I come back later.
A sub-set of this, is also about making choices that have consequences. Like which person do I save, as seen in "The Walking Dead" game. And I can mention The vacuum as an AGS game that did this superbly.

3
Add spoiler tag for Hidden:
Any chance the team/tzach tries to rescript, reimagine, emulate AGS Script, so transition to monoAGS is easy?

Well, AGS script is based on c++, and c# is c++ re-imagined, so applying this full-proof logic will tell you that c# IS AGS script re-imagined. 8-)
Anyway, I'm not going to work on an AGS script emulator myself (I feel the work-to-benefit ratio is too small here), but anyone else is welcome to do it.
For ease of transitioning between the languages I wrote a document that explains the differences between the languages and the APIs: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

Also, I plan to create an interaction editor that will hopefully allow you to write most of your game without having to code at all: my hope is that this will make the transitioning relatively simple.

4
The biggest issue I have now, even though that sounds dumb, is that I have literally no idea where to look for these jobs. Which kind of shows my disconnection from this world of game developement. I mean, ofcourse there are those well-known giant companies producing AAA games, but that sounds too much for starters.
That is why I was asking, maybe there is some kind of a place, like a internet hub, to check out for smaller groups, indie companies, etc, to begin with something?

Tigsource: https://forums.tigsource.com/index.php?board=40.0
IndieDB: http://www.indiedb.com/jobs
Gamasutra: http://jobs.gamasutra.com/

Also, silly question, but have you tried googling for "game developer jobs"? -> it gives tons of options, like this, for example: https://www.indeed.com/q-Game-Developer-jobs.html
You can also google for specific engines, like "unity3d jobs", there's a lot of jobs out there.

5
I don't think differences in workflow is the big problem here, but rather the sheer amount of work involved to have the editor speak in an additional engine format. And also, a lot of the editor features will need to be disabled/hidden as they will not be supported by current AGS (or a lot of effort will be required to modify the engine), making me doubt how useful it would be in practice, and if the perceived benefits will be worth the effort.
That said, I will be making an effort to make the editor relatively modular (separating the editing experience from the output generators, for example), so that if somebody wants to go for it, she/he will be able to do that.

6
Engine Development / Re: Test game
« on: 21 Mar 2018, 03:24 »
It was more for an idea of what he is testing.
I'm only doing unit tests, I don't currently have any game-testing frameworks, though I would definitely want to have something like that eventually. What I would like to have in my fantasy game testing framework:
- Very stupid bot: it would randomly left/right click in various locations in the screen, trying to make weird things happen.
- Stupid bot: it would randomly trigger interactions with objects in the screen, trying to make weird things happen.
- Scripted tests: either by triggering interactions directly or using programmatic mouse clicks, and assertions will be made against pre-made screenshots (no clue on how to test audio).
- Benchmark tests: will make sure there are no performance regressions.
- Tests should be able to run in a docker container in some kind of headless OpenGL window, so it can run from the build server.
- Tests should record a video so we'll be able to see what went wrong.
- Dumb & Dumber bots should record all clicks and allow playback to reproduce errors (which can't be perfect because of timing, but might be useful on occasions)
- Dumb & Dumber bots should be generic and configurable so that they could be used by game developers to test their game.
- If we have the money, then we'd like to run the tests on xamarin test cloud which runs the tests on a lot of different real mobile devices, which will help us find issues with specific devices.

7
- replication of known AGS functions (character.Say, etc.) -- to which extent?

I created a "cheat sheet" which compares AGS functions to MonoAGS functions: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

The "cheat sheet" has 2 sections, the first compares AGS script to c#, and the second section compares the APIs (functions and properties).

I plan on maintaining this document as we add more missing APIs (or change existing APIs to make them friendlier).
Any feedback (like missing functions that you think are important to add) will be appreciated.

8
Could this editor change by Tzach be made currently? Like, by you? Like, for money?.... :3

I could try, lol, but I will have to give most money to tzachs, because it's his code.
Works for me 8-)

Seriously, though, I remember it had a lot of rough edges and I had concerns about usability (and like you said, it was mostly untested), so if you really want to take a go at it you'll probably need to invest a fair amount of time (so you should probably keep most of the money ;) ).

9
Did somebody water the plant after the murder took place? (if that's true, then I'm guessing the detective somehow knew that, and then figured out the murderer dragged the victim after the plant watering, otherwise the person who came to water the plant would have seen the body and called earlier).

If not, then some more questions:
Was there something in the pot that shouldn't have been there?
Did the detective have knowledge about sunflowers and how to care for them?
Was there more than one murderer?
Is the scene the victim's apartment?


10
Oooh, very interesting! I haven't considered hosting VS Code inside my own editor (I thought of doing the opposite), but that might be a viable alternative as well.

11
AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.
I made the same "crime" at the beginning with my engine, until somebody on the chat enlightened me on this feature in AGS. It wasn't due to laziness, it was due to artistic blindness, I didn't notice the difference myself.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.
Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?

12
Just a reminder you can just do what Unity does and have the thing you write code separated from the rest - this is also how working with Chrome/Firefox developer tools with VSCode works, and I think with Unreal too. People seem to be OK with this - I know in the past we used to have IDEs but not doing it looks to me more maintainable.

So, as I said earlier:
Quote
I'm hoping to distribute the editor in several flavors: the standalone version will come bundled with the dotnet cli but without any IDE. Like persn said, you'd be able to use pretty much any ide you want (you can program in notepad if that's what you want) with that. That's pretty much the equivalent for unity. Other flavors would be as IDE add-ins, and I'm planning to target Visual Studio and MonoDevelop (hopefully all flavors will share as much code as possible between them), though that's probably not going to happen for the first version (version 0.1 coming sometimes this decade to your home).
What you're saying here is basically what I planned for the first release.

However, for people who don't have a particular favorite IDE they want to work with I think that having everything built in the same product provides for a better seamless experience (especially if you're working from a single monitor- I wrote some unity games and switching between the applications on my laptop was super annoying). The fact that unity and a lot of other engines aren't doing something like this is indeed alarming and a cause of concern regarding how maintainable it is. I still want to try and see for myself if I can make this work, and then evaluate maintainability concerns.

Also think about a package manager (you can use one that already exists) to share scripts.
I'm using standard c#, so nuget or paket should both work fine.

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?

13
Right, Bridge.NET is one of the solutions I mentioned which I'm skeptic about. My concern with Bridge.NET is that it directly transpiles c# to JS, it doesn't compile the generated IL, meaning all the dependencies will need to be compiled as well, and some of them do IL injection, so not sure what the solution there would be.

Either JSIL or WebSharp look like a more appropriate solutions but both look abandoned. I suspect both are abandoned because WebAssembly makes it all obsolete. Both Mono and .Net Core have in progress ports to WebAssembly, and as Electron supports WebAssembly this might be a good solution for the future, but probably not viable for now.

14
For example, I want to run the room designer in a tabbed document window in VS Code. The room designer itself will be written in c#, using components from the engine & API (both c#) and rendering the actual c# game code in the window.

15
It looks like plugins can be bundled fairly easy assuming we're using an installer, we'd just have to install them to their designated paths https://code.visualstudio.com/docs/extensions/example-hello-world#_installing-your-extension-locally

That's cool, however I'm less concerned with how to bundle the plugin, I'm more concerned about how to write it. As VS Code only supports writing your extension in TS/JS it means we either need to figure out how to compile c# to js (there are some solutions but I'm very skeptic regarding their completeness) or do it IPC which I'm afraid will be too slow (unless maybe we duplicate the entire render loop in js which might be a big burden on maintenance). A third possibility might be to fork VS Code, and run c# from Electron directly, but I'm also a little bit skeptic about this.
Another problem is that apparently Electron doesn't work with OpenGL currently, so we'll also need to write a WebGL backend (which might not be too bad, considered doing it eventually anyway for supporting WebAssembly).
I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

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

Quote
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.
I think you missed my earlier comment on this- it's Windows only which is a deal-breaker. And also, this.

17
Editor Development / Re: Discussion on existing engines
« on: 11 Jan 2018, 06:07 »
It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.

Hehe, yes, I remember reading your blog ages ago and thinking "wow, this is very close to what I wanted to do too". In fact, one of the reasons I didn't start working on MonoAGS sooner was because I was waiting for Xage (and one of the reasons I eventually started working on MonoAGS was because I thought that Xage was abandoned).
Judging from the recent tweets you linked here it looks pretty sweet.

OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.
When MonoGame made the decision to drop OpenTK it was when there was a big drama in OpenTK- the main maintainer left the project and it seemed like OpenTK was going to die. As it turns out, it didn't, other people came and took over, and it's very actively maintained now. Btw, from what I remember reading at the time, they switched to SDL2 for window and input, but they stuck with OpenGL and OpenAL and just wrote their own bindings instead of OpenTK.

There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.
I'm a big fan of VS Code, and yes, it supports dotnet core for development, the problem with it however is that it doesn't support c# for writing extensions, only Typescript/Javascript. So it doesn't look like I'll be able to bundle my editor with VS Code. Note: there's WebSharp that looked like it could be promising in terms of maybe compiling c# for Electron and then perhaps it is possible to write extensions for VS Code, but it hasn't been touched in a few months so I'm afraid it was abandoned.

Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.
Yes, I chose protobuf for both speed and good support for backwards compatibility. Btw, if speed is what your after, rumors has it that Cap'n Proto is even faster the protobuf.

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

19
Editor Development / Re: Discussion on existing engines
« on: 10 Jan 2018, 15:12 »
Sorry for not reading everything, but did you take a look at https://github.com/ocornut/imgui
I'm using in my project, it's a immediate mode gui that works with opengl and it's in constant update.
I did look at it. I ruled it out mainly because I'm not sure how "immediate mode" integrates well with my design. Also I remember reading about it and people were talking about it more as a "GUI prototyping tool". And finally, the sample picture on the c# binding front page didn't look appealing. On the plus side the images on the original imgui project look better, and the c# binding is actively maintained, so I will keep it in mind.

Quote from: Monsieur OUXX
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?
First of all, when I develop I rotate between developing from Mac and developing from Windows (and I'll add Linux to my rotations when support is added for that) to see that things are working well on both platforms. When I compile locally, I only compile the projects for the platform I'm testing, so I'm not compiling mobile if I don't test mobile. Once I submit a PR, the automated build kicks in which compiles for all platforms and runs the tests.

Quote from: Monsieur OUXX
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.
I don't think that's currently a problem in c# world. There are multiple IDEs, but only a single compiler (Roslyn) which everybody uses. If it will become a problem, I will re-evaluate.

Quote from: Monsieur OUXX
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.
Perhaps notepad was a bad example, but the point here is that while you can write your AGS game with XML on notepad, you can't debug it without the AGS editor, you don't have intellisense, code navigation, etc, without the AGS editor. With MonoAGS you can do all that without the editor, and you'll be able to do that no matter which flavor of the editor you install. Now, this wasn't meant as an answer to your specific concerns, this is obviously not a solution to a lot of people who want something built in. But it is very important to a lot of people who already have their favorite IDEs/tools and want to stick with it.

Quote from: Monsieur OUXX
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.
Sorry for not being clear, you'll have a "play" button in the standalone version which will run the cli tools.

Quote
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 ;)
If MonoDevelop doesn't pan out, then I'll search for alternatives, or worst case (don't want to go there, but it's always an option) build my own.
Btw, apparently unity are now shipping with Visual Studio instead of MonoDevelop. So maybe it is possible to bundle with Visual Studio (or maybe Unity and Microsoft made a deal, I don't know).

Quote from: Amélie
qptain_Nemo told me that MonoAGS most likely will run on Arch Linux ARM too.
I hope? I saw that dotnet core supports Arch Linux, don't know about Arch Linux ARM.

Quote from: Monsieur OUXX
@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.
When I first started development, MonoAGS was a very strong candidate for a backend. I started installing the framework, but I remember the instructions were very confusing for me, and I don't remember if ever got it to work. I remember thinking "yeah, it's not going to fly with non-programmers". Also MonoGame (or any complete game engine) brings with it a lot of baggage, dependencies, opinions and quirks that restrict my own design. Not using it gives me more freedom. However, I'm not ruling out looking into integrating with MonoGame as an optional backend (same goes for Unity, btw).

Quote from: Monsieur OUXX
Quote from: ChamberOfFear
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.
From what I can gather from their Github page, SharpDevelop is Windows only.

Quote from: Monsieur OUXX
Other question : do you use tools such as mkbundle or Monokickstart to bundle Mono in the current version of MonoAGS?
No work was done regarding deployment yet, so no. Also, as I plan on removing Mono, most likely I will not use those.

20
Editor Development / Re: Discussion on existing engines
« on: 09 Jan 2018, 22:02 »
Quote from: Monsieur OUXX
This is aimed at explaining once and for all what I mean every time I try to express some concerns regarding what I sometimes call "vector abilities", sometimes "3D geometry", sometimes "subpixel transformations", etc.
Ah, great explanation, thanks!
Yes, it's a valid concern against OpenGL which I was not really aware of. I'll need to study it more.

Quote from: Monsieur OUXX
By game production pipeline I meant that the work of the project leader, game designer, artists and scripter don't overlap.
Here is how they sometimes overlap in AGS :
- Every time you add a sprite or a room, it modifies game.agf or some other central set of files. Conflicts cannot be resolved easily.
So that's another reason for me to switch to dotnet core, their csproj supports globbing patterns so you don't have to specify specific files that are included in the project (it's possible that mono supports the new csproj too now, btw, not sure). Besides the csproj there's nothing else so there would be no conflict here.

Quote from: Monsieur OUXX
- If a sprite changes on the file system, you have to reimport it --> you have addressed that. (by the way, make sure that room backgrounds are not managed separately -- AGS keeps them in a black box, unlike sprites)
Room background is not separate. All assets are treated the same (at least when developing): files in the file system.

Quote from: Monsieur OUXX
- if you add or remove a sound, it creates its corresponding name in the script. It breaks compilation if you remove the sound. (the sound artist's work conflicts with the scripter's work)
Hmmmm, that's a touchy subject. I understand your concern, but on the other hand named assets are also important for intellisense and avoiding typos. It's currently not a problem but it might be when I develop the editor- I'll think about how to address that when I get there.

Quote from: Monsieur OUXX
About the GUI : I strongly recommend that you use a thirs-party library, and that you don't implement GUIs yourself! Home-made GUIs are the plague of many game frameworks. There's always a moment when scripters want to extend the behaviour or aspect of a GUI control, and then they can't because they can't hook on the controler events or graphical containers, or can't make sense of the rendering flow. And then you will have to carry that weight. Have you ought about GTK?
Yes, I thought about GTK# among others. I have two problems with that:
1. I want to be able to have the GUIs as part of the world, meaning I need to control when and where to render it with OpenGL. So that pretty much rules out all GUI libraries that are not OpenGL based. The best GUI framework I found for OpenGL is nanogui, which I still consider my fallback plan if my current plan doesn't work as I want. The problem with that is nanogui's c# binding looks abandoned which means that I'll need to maintain the binding myself, plus get a deep understanding of nanogui workings and I tend to believe that the weight this will carry on me is not smaller then have my own framework in place. And also, this doesn't solve my second problem...
2. So, what Crimson Wizard said here:
Quote from: Crimson Wizard
Now, at any point in time you add CanBeOnGUI behavior, and boom, character becomes a GUI element, while retaining everything else, walks among the buttons and talks to labels.
I'll basically lose this ability for GUIs if I follow that route. The fact that GUIs in the engine are treated the same as all other objects and can be manipulated the same, I feel that's a great power for the engine to have.

Quote from: Monsieur OUXX
Therefore, be careful with "anonymous" fields used by Protobufs/Protocontract.
Just to be clear here, protobuf is just used for the saved games file format, that's it.

Quote from: Monsieur OUXX
I suggest even more than previously the use of automatic solution generation, since I saw that you have one .sln file per target platform.
mmm, no? I only have one sln file. Are you talking perhaps about the csproj files? I have a csproj file per platform, not a sln file per platform. I'll have to read about cmake for c# more, I'm kind of hesitant because I didn't see any c# project actually using it yet (but maybe it's because it's new, based on your link). There's a known solution for the multiple projects per platform in the c# world: Protobuild- it's used by both MonoGame and Xage, so I'm more inclined to use it. However I'm still not convinced that the added dependency (be it protobuild or cmake or something else) and the cost that goes with it is worth the multiple projects "pain", maybe it's because I haven't experienced that pain yet, currently I kind of like that clean separation between projects. Also protobuild does not currently support dotnet core as far as I know- I did want to play with it at some point to gain a better understanding of the benefits, but I don't consider this a priority. If another contributor will come and want to add something like that, I'll probably not going to stop her/him though (except for the dotnet core issue...).

Quote from: Monsieur OUXX
- 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)?
For graphics rendering, OpenTK supplies OpenGL bindings and OpenGL ES bindings. Those are not the same unfortunately. So I have 2 implementations of "IGraphicsBackend", the OpenGL one is used by desktop (Windows, Mac and Linux), and the OpenGLES one is used by Android & IOS. And I'll probably need yet another implementation when I add UWP (xbox and windows store) which will either be DirectX or Angle. For input, OpenTK handles it cross-platform for desktops but not for mobile: I use the xamarin APIs which are native representations of the android and ios APIs, but they are not the same. I might switch in the future if I find something.
For bitmap and text rendering, I also currently have 3 implementations (desktop, android and ios) but I want to switch to SkiaSharp which is completely cross platform (and also gives a lot of other benefits like hardware accelerated text rendering). Currently stuck on this, btw: if somebody knows/figures out how to solve this, let me know.

Quote from: Monsieur OUXX
- 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.
Yes, I'm discussing solutions with Crimson Wizard. However... rooms are not adventure game specific? Room = Scene, and every game engine on the planet (I think) have this concept. The "OnBeforeFadeIn/OnAfterFadeIn" events for moving in/out between scenes is also generic and not adventure game specific.

Quote from: Monsieur OUXX
- event hooks! event hooks everywhere! E.g. OnNewItemInInventory
MonoAGS has event hooks a-plenty. All lists that are marked as "IAGSBindingList" have an "OnListChanged" event which gives all the items that were added/removed from that list. Good call on the inventory items though, as I didn't change it from "IList" to "IAGSBindingList" yet, will fix.
Also, all components implement "INotifyPropertyChanged", which you can subscribe to and get events whenever any property in the component changes (this is how the inspector refreshes itself to show you whenever something changes in the game).

Quote from: Monsieur OUXX
- Have you considered an importer for an existing AGS 3.4 project?
I suspect it's going to be crazy amount of work. If somebody else wants to work on it, that would be great. I'm not going to, though, not in the foreseeable future.

Quote from: Monsieur OUXX
- 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?
lol, yeah, it looks bad...
My core engine library targets dotnet standard which means I can target both dotnet framework, mono or dotnet core.
OpenTK is still not officially supported with dotnet core (it's in progress), meaning that the core engine can't reference OpenTK, only the desktop engine project can reference it. So I had to copy a bunch of their classes to make it work. Once they support dotnet core I'll be able to remove those.
For drawing bitmaps, I used stuff from System.Drawing which is also not part of the dotnet standard so I had to take dotnet framework code. Once I switch to SkiaSharp I'll be able to remove those.
And finally, my binding list is not taken from c#, it's my implementation that's there for adding those hooks you mentioned earlier which don't exist in the original list implementation. And tree is also my implementation, there's no tree data structure in c#.

Quote from: Monsieur OUXX
@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?
I don't think I did? I just listed F# as potentially the best candidate if you want to code your game using something not c#, because I know it's a dotnet implementation that is actively supported by Microsoft, and I'm not sure how actively maintained and complete other dotnet implementations are (everything else afaik is developed by the community and not sponsored by major players, I might be wrong about that).

Quote from: Monsieur OUXX
- 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.
Ok, so I guess it's time to talk about my plans for the editor (important note - everything here is subject to change and might not actually happen).
First, regarding your concern: I'm hoping to distribute the editor in several flavors: the standalone version will come bundled with the dotnet cli but without any IDE. Like persn said, you'd be able to use pretty much any ide you want (you can program in notepad if that's what you want) with that. That's pretty much the equivalent for unity.
Other flavors would be as IDE add-ins, and I'm planning to target Visual Studio and MonoDevelop (hopefully all flavors will share as much code as possible between them), though that's probably not going to happen for the first version (version 0.1 coming sometimes this decade to your home). The MonoDevelop addin can be packaged together with MonoDevelop and distributed. For the visual studio flavor, yeah, you'll want to download VS first and then download the AGS extension.

Regarding what you said earlier about hard-coded verbs: the plan is for the editor to have somewhere a place to edit your list of verbs (or you'll use a game template which has the verbs pre-set). The editor will auto-generate a "Verbs.cs" file with your verbs, and the core engine itself will not have knowledge about specific verbs.

You'll also be able to edit your outfits and choose which animations are part of that outfit, those animation names will also be auto-generated to a cs file.
As for the animation editor, I plan to have a basic layout like AGS has with individual frames and live preview, but also will have a "switch to timeline" button: this will place your frames on the timeline, and you'll be able to add tweening for properties (shown on separate tracks in addition to the frames), and possibly set various blendings. And one last thing for the animation editor would be to allow for composition animations -> show the entire object tree so that you'll be able to have separate animations for the head and body (for example) and see how they work together.

For the room/scene designer, I plan the canvas to have a similar interface that InkScape has for moving/rotating/scaling objects (with grid lines/snapping for alignments etc) and for editing areas something similar to InkScape vector tools as well. In the tree view of the scene you'll be able to show/hide/lock/unlock layers or individual objects, and selecting an object will show the inspector (called "Properties Window" in AGS but the same principle, pretty much exists in all editors). From the inspector you'll be able to set values and add/remove components. You should be able to switch between "playing the room" to "editing the room" immediately (I hope), or maybe even editing while playing. You'll be able to see and edit the GUIs from the scene designer (they might not "belong" to the scene, but it's just that more convenient to see how the game will actually look from the editor). When adding a new object to the canvas you'll be able to select from various presets (object, character, button, etc): each preset is basically an entity with a specific set of components and defaults. The presets that are available for you to use will be dictated by the game template you choose, or you'll be able to create your own presets (or import from modules, etc). This is kind-of similar to prefabs in unity (but not as powerful- will probably extend this to be as powerful eventually). For each of those presets a friendly interface will be auto-generated for your coding pleasure (so you'll be able to write "character.Walk" instead of "character.GetComponent<IWalkComponent>().Walk").

For events/interactions- my observation here is that for most adventure games, most of the interactions are basically the player character says something in response for looking/interacting with an object in the room. Really, I don't think I'm exaggerating if I say that's 75% of interactions in a typical game is just that. That's why, I want first to make this as painless as possible. If you type on a object/verb combo line in the editor, it would automatically translate into player.Say(..whatever you typed..). Otherwise you'll have either the current AGS option of going straight to code, or you'll have the option to open the interaction editor. The interaction editor might be similar in some ways to what Blade Coder has. At least for the first phase, I'm not planning to have graphs with nodes a-la articy/draft, but a list of interactions with if/else branching as indented, we'll see how it goes and maybe I'll re-evaluate. The functions in the interaction editor (like the properties from the inspector, btw) will have help links directly in the editor (it will be extracted directly from the api documentation for built in functions/properties, and extracted from code attributes for external modules). You should be able to run code from the interaction editor and to run saved editor interactions from the code. Also, the interactions themselves will not be hidden, code will be generated for you so this can also be seen as a learning tool. And finally, I plan to have async/await support directly in the interaction editor. Hard to explain without a picture, but basically if you add a "Walk", for example, it will add an "await" with "walk" on the same line, but then you'll be able to drag the "await" section to its own line and put other actions between the "walk" and the "await" so you can have the character walk in parallel to other things going on in this cutscene.

Another interaction related feature I want to have is a "matrix" window. This aims to be a productivity enhancer for writing interactions in bulks and also to solve the problem of a lot of games (that drives me crazy) where the developer forgets to code all of the interactions. The matrix window will have all interactable objects + inventory items as both rows and columns. Each cell is an interaction that has to be filled. You'll have a nice "you're 64% there!" label showing you how much of the interactions are done. And you'll be able to click on each cell to edit the interaction (with any of the methods I talked about for interactions), you'll also be able to mark specific cells as "default" (which will activate that whatever "I can't do that" default interaction you configured) or as "bug: not supposed to happen" (which will also activate the default interaction but might do something else like crashing you if you debug, or send an email from a tester or whatever you set it to do on "bug"). You'll have some controls for filtering the matrix to specific rooms/only inventory/etc if it's getting too big and/or you want to focus on something specific. And finally, you'll have a "start marathon" button which will rotate between "unfilled cells" with easy shortcut keys to pass to the next interaction.

As for speech, this is also a big pain-point for me with current AGS. I still want to support the current workflow, but also have a speech control window (maybe somewhat similar to the speech center plugin), and you won't be forced to number your speech lines in the code yourself, the string itself will be the id and map to a numbered filename (or filenames for multiple localilizations), though you'll be able to override with a number for specific lines (like if you have multiple lines with the same string but need to be said differently). You'll be able to write director notes in the speech window for specific lines, and create nice looking scripts for voice actors. Also, there will be a "start marathon" button here too, you'll select a character and it will run over all of the script lines for that character and open the speech line editor. From the speech line editor you'll be able to record the voice and do basic editing. When recording you'll have keyboard shortcuts to stop this take and start a new take, and a shortcut to move to the next line. For editing you'll be able to trim beginning/end of takes, change volume/pitch/reverb. You'll be able to delete takes, and keep multiple takes (for repeating sentence where you might want some variation in how a character says a line). I still painfully remember the amount of time it took to get the independently recorded lines from the voice actor, open a big-ass audio software where all I want to do basically is select the good takes, and then do some trimming and volume adjustments, then manually exporting to files, figure out the correct filename and then needing to test it in the game to see that I completely screwed it up... This whole process took ages. Hopefully doing it all in-editor will save huge amounts of time.
Another interesting possibility here that I want to explore, is being able to open the speech line editor directly as you're playing the game. So, for editing, the game developer will be able to edit lines while playing the game which gives better context. For recording, if the voice actor is recording remotely, the game developer might prepare a few saves where the character speaks, and either instruct the voice actor what to do to get to her/his lines, or even code to directly cut to the dialogs. If the voice actor is recording with the developer in a studio, then hopefully the game developer could bring her/his laptop and hook it up to recording hardware, and switch to the saves/coded dialogs while showing the monitor to the voice actor. The goal here is that the context of the actions will be much clearer to the voice actor as the dialogs are played.

I'm going to skip various other things the editor needs (editing settings, deployments, fonts, cursors, and I maybe forgot lot of important points), but one last point I want to touch on is customizability.
There are obvious customizations you can expect, like authoring your own components and being able to edit their properties in the designer.
But more than that, as the editor will be using the same framework as the engine, it will use the same mechanisms for customizations the engine uses: meaning, almost everything should be able to be replaced if you want. You'll be able to code your own inspector if you so choose and replace the existing inspector (and then share it as a module for other developers), etc.

Quote from: Monsieur OUXX
Overall I would like to congratulate you for how compact is your code.
Also, kudos for using async/await.
Thanks :)

Pages: [1] 2 3 ... 54