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 ... 52
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. 8-)

Good luck, I'll be watching this.

The Rumpus Room / Re: Happy Birthday Thread!
« on: 25 Jun 2017, 04:20 »
Thanks Mandle :)

AGS Games in Production / Re: Unavowed
« on: 26 May 2017, 02:03 »
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  8-0

Engine Development / Re: OpenGL renderer for Windows
« on: 18 May 2017, 14:48 »
- 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:

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 (, 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: Adventure Game Studio
  1. private async Task lookOnWindow(object sender, AGSEventArgs args)
  2. {
  3.         _room.Viewport.Camera.Enabled = false;
  5.         float scaleX = _room.Viewport.ScaleX;
  6.         float scaleY = _room.Viewport.ScaleY;
  7.         float angle = _room.Viewport.Angle;
  8.         float x = _room.Viewport.X;
  9.         float y = _room.Viewport.Y;
  11.         Tween zoomX = _room.Viewport.TweenScaleX(4f, 2f);
  12.         Tween zoomY = _room.Viewport.TweenScaleY(4f, 2f);
  13.         Task rotate = _room.Viewport.TweenAngle(0.1f, 1f, Ease.QuadOut).Task.
  14.                 ContinueWith(t => _room.Viewport.TweenAngle(angle, 1f, Ease.QuadIn).Task);
  15.         Tween translateX = _room.Viewport.TweenX(240f, 2f);
  16.         Tween translateY = _room.Viewport.TweenY(100f, 2f);
  18.         await Task.WhenAll(zoomX.Task, zoomY.Task, rotate, translateX.Task, translateY.Task);
  19.         await Task.Delay(100);
  20.         await _player.SayAsync("Hmmm, nobody seems to be home...");
  21.         await Task.Delay(100);
  23.         zoomX = _room.Viewport.TweenScaleX(scaleX, 2f);
  24.         zoomY = _room.Viewport.TweenScaleY(scaleY, 2f);
  25.         rotate = _room.Viewport.TweenAngle(0.1f, 1f, Ease.QuadIn).Task.
  26.                 ContinueWith(t => _room.Viewport.TweenAngle(angle, 1f, Ease.QuadOut).Task);
  27.         translateX = _room.Viewport.TweenX(x, 2f);
  28.         translateY = _room.Viewport.TweenY(y, 2f);
  30.         await Task.WhenAll(zoomX.Task, zoomY.Task, rotate, translateX.Task, translateY.Task);
  31.         _room.Viewport.Camera.Enabled = true;
  32. }

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! ;-D
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.

@Crimson Wizard, from the error it looks like the released editor was compiled in Debug mode, and not in release mode?

@slasher, if you don't want to wait to get a release version of the editor, I see 2 options:
1. Re-install visual studio and enable just-in-time debugging.
2. If you're set against installing VS, you can enable it in the registry (just be sure to backup your registry first).
Look at this link here:
and scroll to "Enable or disable Just-In-Time debugging", both options are described there.

Note though that it looks like the error you posted is not the real error, but the error after the error. So fixing the current error
will probably result in another error (the real error)...

This is really cool!
Can I have To The Moon, please?
Thanks you, you are awesome, and have a merry key-mas!

Congratulations, Cat! Always knew you're the chosen one. May you have a successful reign.

Adventure Related Talk & Chat / Re: 10 YEARS OF AGS
« on: 02 Dec 2016, 12:48 »
Happy birthday!
So what would you consider your personal best AGS accomplishment? Hitchhiker? Primordia? The awards?

My bad, I didn't know there was a wiki for the keyboard shortcuts when I made those changes (4 years ago?):

Ctrl+M: switch between the script and header file.
Ctrl+G: goto line
Ctrl+Shift+G: open global script
Ctrl+Shift+H: open global header
Ctrl+Shift+F: find all
Ctrl+Shift+E: replace all

Also were missing from the wiki were the tool selection shortcuts in the area editor:
Ctrl+N: draw line
Ctrl+D: draw free-hand
Ctrl+F: draw fill
Ctrl+E: draw rectangle
Ctrl+C: select area

I think everything else was correct.
Edited the wiki to reflect the changes.

I can make a procedurally generated RPG in AGS or in GameMaker but these aren't real languages.

Yes they are. If you can make a procgen in AGS then you can become a professional programmer without too much trouble. The questions are (1) do you want do be, and (2) how do you convince a company to hire you (note that you can absolutely put homemade game design on your resume!)
I know a lot of professional programmers that would have a real hard time programming a procedurally generated RPG (and in AGS it's even harder to do than with fully fledged languages).
I disagree with RickJ, I think you can have normal work hours when doing computer programming, just need to pick your employer carefully. I never worked weekends myself and haven't stayed in the office past 6PM in years.
Also, 30K is probably the lowest wage you can get:
Now, if you want to go down that route the biggest issue is how to get a job, as with no experience or relevant degree you are kind of in trouble. I would do some Coursera courses for education instead of investing money in one of those plans like the one you posted. Coursera will give you quality courses for free (and for some courses you can pay to get a certificate). But the most important part is to get actual experience, so you can go freelancing as Mods suggested (but something you can show in your CV, so like create an app/game/website) and a lot of companies today recruit based on open source contributions so start contributing to an open source project (or more than one) on Github. AGS, perhaps? Getting into big open source projects can be overwhelming at the start, as it takes time to understand the code, so you can start with taking a very small feature request that sounds 'easy' and start fighting with the code.
If after having both some education and experience you still can't get a job in programming, a good stepping stone into the industry is by doing software QA. That's how I started. The wages are lower and the hours longer, but after you put some time in QA it's easier to get promoted to be a dev (when you're doing QA for some time you get to be the most knowledgeable person in the company about how the software works, more than the developers themselves, and so companies won't want to lose you so you can demand a promotion without blinking).

Note that WebAssembly is going strong now and expected to be supported on all major browsers. When it is officially released, it will open the floodgates for all languages (including c++) to run on the web. Hopefully it will happen in our lifetime.

EDIT: Ok I found out... so, is this .NET Core something that we should aim for?
It's very hard to tell, as the water keeps changing (Microsoft is calling this "growing pains"). Mono has been around much longer so it's definitely more stable.
The new kid on the block, and the one we might want to keep an eye for, is the .net standard library. If we target it, theoretically we can compile for mono, .net core, .net framework, xamarin, uwp and more future platforms.

Also, something I always wanted to ask, but did not: currently all Editor is made of WinForms. Does that work on Mono, or we would have to replace them with some portable GUI classes?
There is a WinForms implementation in Mono, but from what I read, it's lacking, and the recommendation is not to use it (and while you didn't ask,.Net Core does not support WinForms). Also relevant, I believe that ScintillaNet is Windows only so a different text editor should be used.

Pages: [1] 2 3 ... 52