Messages

I'm curious what the JIRA setup looks like at your work.  I was the one who set it up where I work, and I find it very intuitive and easy to use... (yeah, I would say that...).  Did you look at the Cloud instance I linked though?  It's very streamlined and clean compared to the full server version.

Oh, wow. This looks much better than what we have at the office. Now I wonder if the on-premise version is really that different or we're just using a really old version.

Anyway, even with the new interface, it still seems overly complicated, and here's an example for something not intuitive at all. I navigated a bit and went back to the issues and all of a sudden the issue disappeared. Apparently there's 2 tabs for issues? Here's one without the issue and here's the one with the issue.
Classic Jira/Atlassian confusion

I thought all the engine/editor contributors so far got involved through the community, rather than just stumbling across the code?

It's hard to say for sure, because people might use completely different nicknames, but if I look at the list of the people who forked AGS (i.e a partial list of the people who made an attempt of doing something with the code) there are a lot of names I don't recognize from the forums.

I suggested this 8 years ago : http://www.adventuregamestudio.co.uk/forums/index.php?topic=38838.msg511292#msg511292

We use the Atlassian stack at my job, and I'm not a fan.
Jira in particular is maybe my most hated software on the planet: yes, it's very powerful, but it also too complex and unintuitive. I remember on the first day using it, I sent them about 5 tickets about various usability issues (buttons are not where you'd expect them, extra clicks needed for basic stuff, etc), I didn't get any replies (i suspect that the feedback button leads to nowhere).

BitBucket is mostly ok, but it's slightly less appealing than Github. For one thing, the ecosystem around Github seems friendlier: integrating Travis for example with Github was a snap, but integrating Jenkins with BitBucket was a nightmare (and also I don't think Bamboo is free for open source). You can tag issues in commits in Github as well, btw. But perhaps the best argument for sticking with Github is visibility: it's the most popular option, most developers are familiar with it and there's an organic stream of new developers interested in the project that I don't think we'll get with Bitbucket.

As for confluence and project management, Github has both a wiki and a project management tool which we can use (the functionality might be more basic, but it's also more friendly, and good enough for our needs, I believe).

Sadly it is looking more and more like Bittrex has become an (extremely long-running) scam with what now looks like a clear exit strategy.  This would wipe out pretty much my entire crypto portfolio.

Sorry to hear, that sucks. Our company is now starting to trade in cryptocurrencies and they brought an expert to teach us a little bit about it. According to him there are only 2 exchanges that are trustworthy: Gdax (including Coinbase) and Gemini. Those 2 are backed by big known institutions and at least your USD there is FDIC insured. All of the other exchanges are a little shady at best, or outright criminals at worst (Bitfinex).

[Tesla Effect: A Tex Murphy Adventure]

Woo-hoo!

Can I have Tesla Effect: A Tex Murphy Adventure?

Thank you!

Hi, as morganw mentioned, feel free to take a look at my project (work in progress), which is my "take" on how AGS 4.0 should look. It's not a rewrite but a completely new code base.

RE some of the points made here:

SDL- I'm using OpenTK, a c# binding for OpenGL which lets you choose whether to use SDL2 as your backend (or the native OpenTK backend).

Coding Language- Engine, Editor and scripting language are all intended to be c# and work cross-platform. Theoretically every language that can run on .Net can be used as a scripting language, though, possibly even including lua.

Re linux users hating mono- Well, I would say that the biggest reason linux users hate Mono is because it's c#, and c# is Microsoft. Microsoft used to be the biggest hater of linux (and open source in general), but it's quite the opposite today (in fact, Microsoft today is part of the linux foundation). Developers also hated developing c# on linux, because the only available IDE was MonoDevelop and it was not good. Today you have more (probably better) options for c# IDEs on Linux (people really dig both VSCode and Project Rider). There are other concerns about mono which are still valid today, like library size and performance (it is slower than dot net framework on Windows). For those 2 reasons, I'm planning to switch from Mono to .Net Core once OpenTK adds support for it (in their plans). .Net Core apps can be self-contained with a (hopefully) much smaller footprint, and are much faster than mono (and also faster than .Net framework), and it's open source, so all wins.

Networking- I'm not currently planning for building in networking, but as it's going to be simply a c# project (with no sandboxing), anybody can use the networking APIs from the standard library (or use any existing c# networking library).

Vulkan- Currently I'm only supporting OpenGL (and planning on adding DirectX support for XBox eventually), and Vulkan is not currently a priority for me, as it's not used exclusively yet in any platform and I'm tending to believe that 99.99% of AGS games won't need the high capabilities it gives you. That said, OpenTK might support Vulkan in the future, and then I might get it for free, and if not, I'm accepting encouraging contributions if somebody wants to add support.

Video- current plan is to use ffmpeg for video, it looks like the most complete solution for cross-platform video (and audio) streaming.

Congratulations, guys!

The adventure gaming community just grew by one

Try disabling "Enhance pointer precision" in Windows10 settings and see if that helps.

The tutorial you linked to about the signtool doesn't say anything about a visual studio requirement, it just requires downloading the Windows SDK.
From what I can see, you sign the generated exe, so you don't need to involve AGS build process at all. Just follow the instructions.

Another thing you can try, is using the Desktop App Converter. It converts a Win32 app (i.e the AGS game) to a UWP application, meaning it runs in a sandbox and should be safe, and therefore trusted (and can also be placed in the Windows Store and run in Win10S). Whether it actually works with AGS games, I don't know...

Wow, looks really cool, it reminds me of my old AGS football game
And it's funny, because I actually wanted for a long time to do another football game where you program the AI yourself and then compete against other player AIs. And I thought that a cool backstory for that would be to make the soccer players robots... Guess I'll need to come up with another backstory if I ever get to making that game.

Good luck, I'll be watching this.

Thanks Mandle

Huh. I know about the dropdown and use it frequently, but I never even NOTICED the "copy all from folder" option. How long has that been there? That's quite handy!

Oct 31 2010 

- System cursor visible on black borders even in fullscreen mode. That is simply because OpenGL does not have "real" fullscreen mode, but renders on borderless window stretched to whole screen. Frankly IDK how to fix this. I tried ShowCursor(FALSE) on Windows, but that just did not work (that's an old API anyway).

I don't think this is true, actually. OpenGL does not control the window as far as I understand, you control the window yourself (or with a library). You can see in my engine, for example, I use OpenGL on Windows and I support both modes.
As for hiding the cursor, I believe the library I use (OpenTK) just sets an empty bitmap as the cursor.

Which GUI toolkit are you using?   

I wrote a little bit about my plan here:
https://github.com/tzachshabtay/MonoAGS/issues/137

The tldr; version: I plan on having the engine itself as my GUI toolkit for the editor (but it's not definite yet, I plan on trying it out and then evaluate how crazy it really is).   

Please let us know when/if the project progress past it's "secret" phase as some of would surely be interested in following along.

Well, technically the project has been available on Github from Sep 2015, so you can start following now
I plan on releasing documentation for the engine by end of next week which would hopefully help to understand how things work a bit better.

I got the impression that you were doing the engine first and the editor later but perhaps I misunderstood you post or conflated it with others.   How far along is your editor?  How portable is C# with respect to Linux, Mac, mobile and web?

Your impression is correct, I have not started working on the editor (unless you count design), I'm concentrating on having an MVP engine first (and also working on documentation currently). Then I'll start working on the editor. C# is perfectly portable to Mac, Linux and Mobile. The engine already works on Mac (in fact, I do most of my development on a Mac currently) and Android, and I'm currently working on IOS, and then I'll work on Linux.
The web is another issue, unfortunately, and currently not easy for porting. The Mono team is working on supporting web assembly, though (http://forums.dotnetfoundation.org/t/wasm-asm-js-plans-projects/1947/2), so hopefully once that's released it will be possible to support web.

I was thinking in terms of an intermediate compiler output (similar to compiler producing .obj) that could be targeted to multiple runtimes (similar to traditional linker).  If we could define a standard api, intermediate language or whatever term is appropriate then everyone could design to that standard.  We could choose a common file format such as YAML, JSON, or XML and allow for both compressed and human readable forms.  This doesn't mean that development necessarily has to have an extra step between iterations.  A default or development engine could be defined in a configuration and the link or targeting process could be done automatically. Alternatively the editor could have an integrated engine and export to the intermediate form on demand if that would make development iterations were more speedy or efficient. I don't mean to minimize the required effort as there would surely be issues to resolve but in the long run it may result in saved effort.  It's a way of having a degree of independence between IDE and runtime.  It would make it easier to support future, not yet invented, platforms.  It would also be a way for you, scotch, colin, and the rest to collaborate and benefit from each others' effort.

The alternative suggestion sounds much more viable, though it too will have a lot of limitations. Importing/exporting scripts between languages is not going to happen, for example. Also engine features will not map 1-to-1 so you will definitely lose information during the conversion. I'm not opposed of doing something like that in theory, but it's definitely a very low priority for me currently, top priority is build an MVP, release, get feedback and stabilize.

I would also like to add a note, that even if a global api does not exist, there is a still a chance to create converters from one data to another. Even AGS does that now to some extent, converting certain old game data into new supported form.

Right, I already planned on my editor to spit up both code and json/yaml file. The code so that the user will be able to detach from the editor whenever she/he wants, the json/yaml for the actual UI designer. So using that json/yaml somebody would be able to convert to other formats (with the same limitations I already mentioned).

CW makes a good case that the AGS runtime (i.e. the engine part) has reached a point where further development is becoming impractical.  Others have pointed out the advantages AGS (i.e. mostly the IDE part) has over alternatives.  I have no reason to disagree with these assessments. Further, we have at last three new runtime projects, based on lua, C#, and WebGL, currently under development that do not have the same limitations as the current AGS runtime but lack and IDE.

So, we have a great IDE integrated with a runtime that is difficult to improve and becoming obsolete.  We have three newer runtimes under development without the current runtime's limitations.  One can only wonder if it would make sense to move current AGS development towards the possibility of the IDE targeting multiple runtimes?   

If one thinks the editor is good enough, then I agree, a focus can be made just on the engine while sticking with the existing editor. This is exactly what Scotch is doing, I believe, he mimics the engine's API precisely so you wouldn't have to change much in the editor to support it.

Personally, I don't think the editor is good enough. I agree that it has advantages over other IDEs (mainly it's focus on a single productive workflow), but in other ways I find it lacking: poor code editing capabilities, almost no debugging capabilities, no portability and also I think that pretty much all of it's UI designers can be improved as well (not to mention that the editor will need a lot of improvements to support the new engine features),
which is why I opted for re-designing everything and not just the engine.

I might as well come forward too...
I'm also "secretly" working on a rewrite, my secret project is actually out in the open for a long time, and I've recently asked CW to join me (and if any other developer wants to join, yes! Please let me know).
You can see my progress on Github.

My approach is similar to Snarky's suggestion, it's a complete redesign (I'm ticking almost all of the boxes in his list, and planned to tick them all before first release).

The engine is written with c#, the scripting language is also c#, and the editor (there is no editor currently, but there will be) will also be in c#, so hopefully having one language to rule them all will make it easier for developers to contribute.
Regarding the API: I tried to keep some level of familiarity with AGS's API and workflow (so I still have Object, Character and Room) but did change stuff where I saw an opportunity for better concepts (Views are out, Outfits are in, so this is more in line with Visionaire).

Currently the engine is working on Windows, Mac and Android, I'm working on the IOS port and will move on to Linux next, and after that will start working on the editor.

For the engine I'm using an entity-component based system, similar to unity, and I have Object, Character and various GUIs as pre-set entities with all the components you'd expect, so you would normally not need to touch the components (so the workflow will be similar to AGS), but you'd be able to add/remove components if you want specific behaviors. So for example, if you decide mid-game that you want your object to talk, you don't need to replace it with a character (or add a dummy character), you can just add a "talk" component to your object and you're good to go. And as GUIs are also entities with components just like objects, you can even turn your character to a button mid-game if you have some crazy mini-game idea.

Another highlight of the engine is it's built to be customizable from the bottom up. There's a hooking system which you can use to replace even the most basic systems (you don't like the built-in path finding? No problem, code your own and switch).

Also, The API is built heavily on c# async/await, which should make it easier to program actions happening in parallel.
Here's an example from the demo:
When you look at the window, the camera will zoom in, rotate and move (all with asynchronous tweens), at the same time, followed by the character saying "there's nobody home", and then the camera will tween back to its original position:

Code: ags

private async Task lookOnWindow(object sender, AGSEventArgs args)
{
	_room.Viewport.Camera.Enabled = false;

	float scaleX = _room.Viewport.ScaleX;
	float scaleY = _room.Viewport.ScaleY;
	float angle = _room.Viewport.Angle;
	float x = _room.Viewport.X;
	float y = _room.Viewport.Y;

	Tween zoomX = _room.Viewport.TweenScaleX(4f, 2f);
	Tween zoomY = _room.Viewport.TweenScaleY(4f, 2f);
	Task rotate = _room.Viewport.TweenAngle(0.1f, 1f, Ease.QuadOut).Task.
		ContinueWith(t => _room.Viewport.TweenAngle(angle, 1f, Ease.QuadIn).Task);
	Tween translateX = _room.Viewport.TweenX(240f, 2f);
	Tween translateY = _room.Viewport.TweenY(100f, 2f);

	await Task.WhenAll(zoomX.Task, zoomY.Task, rotate, translateX.Task, translateY.Task);
	await Task.Delay(100);
	await _player.SayAsync("Hmmm, nobody seems to be home...");
	await Task.Delay(100);

	zoomX = _room.Viewport.TweenScaleX(scaleX, 2f);
	zoomY = _room.Viewport.TweenScaleY(scaleY, 2f);
	rotate = _room.Viewport.TweenAngle(0.1f, 1f, Ease.QuadIn).Task.
		ContinueWith(t => _room.Viewport.TweenAngle(angle, 1f, Ease.QuadOut).Task);
	translateX = _room.Viewport.TweenX(x, 2f);
	translateY = _room.Viewport.TweenY(y, 2f);

	await Task.WhenAll(zoomX.Task, zoomY.Task, rotate, translateX.Task, translateY.Task);
	_room.Viewport.Camera.Enabled = true;
}

On top of that, the engine supports custom shaders, object compositions, independent resolution, parallax and more.

Wait a minute... which is better, OGG or MP3?

Trick question, OGG is actually a container, not an audio format in itself, so you can actually store many different formats in OGG (not necessarily audio).
The common audio format for OGG, which AGS supports, is OGG Vorbis: it offers comparable performance to MP3, so there's no much difference expected in quality. However, there's a newer format, OGG Opus, which supposedly beats them both. Ogg Opus is not currently supported by AGS afaik.

Congratulations!
Hopefully we'll see you in the next Kiddens.

I ended up re downloading community edition which caused license issues..

VS Community 2015 is completely free, it shouldn't cause license issues.

I think there is a huge misunderstanding, you do not need Visual Studio

He does need visual studio in order to re-enable JIT debugging (or alternatively, change the registry, as I explained earlier). This will not be necessary if he gets a release build of the editor instead of a debug build.

But seriously, one would need to have MSVC debug libraries if it is built in Debug configuration.

I'm not following your train of thought here, surely a build server which supports c# release builds also supports c# debug builds.