Messages

Well, then don't choose that mode. Why the negativity? We do what we want to do and it's been that way forever. There are some SCUMM hardcore fans and there are people who have more open minds about how a possible Indy FoA follow-up should look like, we cater to both.

[When you play the full FoY game, you will be able to avoid any fighting at all and in case you do end up in a brawl you can choose between the old SCUMM combat (which is exactly the same you had in your fight versus the Barrier Guard in the FoY demo) and this arcade mode (not with announcers obviously - but with high jumps, punches, kicks, blocking, ducking, combos and so on).]

Guys, guys, please actually read the info you find in this thread and on the download page (especially before announcing that you aren't looking forward to the game at all anymore because of this Easter release). When you play the full FoY game, you will be able to avoid any fighting at all and in case you do end up in a brawl you can choose between the old SCUMM combat (which is exactly the same you had in your fight versus the Barrier Guard in the FoY demo) and this arcade mode (not with announcers obviously - but with high jumps, punches, kicks, blocking, ducking, combos and so on).

The arcade combat is making it into the game for the people that like a little more to fighting than clicking in a simple pattern and I think it does that nicely. I know it seems rather boring unless played by two actual people, preferrably with a gamepad connected, in which case it actually is a balanced and fun game much like Street Fighter II or Tekken III for instance. If that isn't your cup of tea, no problem. Ignore the Easter special and choose the classic SCUMM combat mode in the full FoY and you'll never see it again.

You already had a functional combat model in the game, but you diverted time to develop this instead?  It's just pretty surreal.

We're on our 12th year of development.

If you're serious about announcers and real time combat like this, a good start would be to scrap the jumping mechanic altogether as it doesn't really DO anything anyway, and then focus on attacks that actually make sense for Indy like using his whip/gun instead of all the kicky-face stuff that he'd never do.

How much have you played the game? Have you tested it against other people? We have and jumping does a LOT in the hands of a skillful player. Not to mention, there will be air attacks available as well. Whips and guns will probably be available as a special combo.

[my proposition regarding AGS's resolution capabilities]

Hmm, I have thought about the situation for a bit and here is my proposition regarding AGS's resolution capabilities:

- we need reliable 'blocky' scaling in all graphic modes, ie. an algorithm (shader) that doesn't AA or blur pixels when stretching up or down.
- the developers need to stay in charge of all settings
- this new proposed system would overwrite the current system, this could go hand in hand with an updated setup application (maybe one you can rename and have look better)

In a nutshell, the developer, in AGS's general settings pane, can set an original 'development resolution', any aspect ratio, any dimensions, any numbers - that is the resolution that all one screen rooms are and so on. Coordinates would no longer make a difference between 320x200 and 640x400 double pixels as some (older?) functions did, pixels are actual on-screen pixels. Also, the developer can decide whether or not to force the game to always run at this resolution (and give a fatal error when the hardware doesn't support), set boundaries or possible scalar values or even allow any scale (aspect ratio always, under any circumstance stays the same as the development resolution but letterboxing to any higher resolution - and maybe cropping to lower ones - can, if the dev allowed this in AGS, brought in). Again, if the end-user hardware doesn't support any possible resolution, a fatal error is reported. By itself, all games would by default try to run in the development resolution.

Basically, the developer can set a number of rules... Allow players to change resolution away from the original at all? Allow them to choose any new scale or limit it? Allow them to add vertical, horizontal or both kinds of black bars? Allow them to crop the resolution down? What scaling algorithms are allowed?

This means, with all that control, some game makers might screw up and, for example, make a 320x200 game and disallow people to change the resolution but people will, in those cases, complain very quickly and let them know to re-release their title with re-sizing enabled.


Are there any big problems (in theory) with this approach?

I don't even want to take a part in this whole discussion at large, just want to point out that NOBODY in this community has bullied you, Studio3, or any other member in the community one bit. If you act like an idiot over and over again, people will point it out and possibly get annoyed. That's understandable and nobody's fault but your own. That is NOT (cyber-) bullying.

Don't have the time to explain much but you should be able to get away with making one function for GUIs (your GUI function should work fine) and then one for the more abstract GUIControl. Look it up in the manual.

Yeah, I don't really expect an increase any time soon either, unfortunately. Oh well! Might force my project into episodic releases but that doesn't have to be a bad thing I guess.

Looks like we're on the same page really. :p Both agreeing on the fact that it is possible to work around but a bit of a hassle. Just me saying it's so much of a hassle I wouldn't want to do it on a large-scale project and you saying the opposite. I can live with that haha!


About the 3D plugins:

(1) I don't know of any AGS plugins that allow for decent quality character rendering and animation (skeletal-/bone-based that is) as well as rendering of backgrounds. As far as 3D plugins go, I'm pretty sure the Razerblade 3D plugin I wrote myself is a pretty good attempt, but it still lacks character animation. It would also require me to re-write a pathfinder and such. Basically resulting in a shit load of work to make it work in an adventure game way (as it is build for shooters and the such).

(2) 3D models and backgrounds either look undetailed or are actually high-poly and make use of shaders and then require the player to have a kick-ass system. 2D can show a lot more detail with a lot less processing power.

Okay, to shorten the discussion: we both agree that working around the 30k sprite limit using more than one actual game is 100% possible in every way. I say, however, the workaround itself is so daunting, adds so much dead weight to the development process and opens so many holes for possible bugs and problems that, in a large-scale project (!), it simply isn't feasible - it's technically possible but unrealistic with the constant need to update interfaces, characters, rooms and scripts and the need to keep all versions between games 100% in sync (making any of these once and turning them into templates is a great approach in theory but, in my amateur experience working on big projects, absolutely unrealistic).

To the voices that still doubt it's reasonable to go over 30k sprites in a game, once again, I have presented calculations that show who and how I'm going over the limit. If you see anything wrong with these, let me know. From my time working on tons of adventure games using pixel art, 30k sprites indeed sounded like WAY enough and I never came close to it once. This project, however, is different due to the workflow of rendering 2D art from 3D models, working together with an actual professional senior artist at a medium-size American game development company who is able to put out wonderful, richly-animated character art. Somewhere between 32-64 frames per walking animation loop is not overboard with these specs at all.

If you want/need different perspectives for each room I can see why you'd be better off with a full 3d engine, proximity. :p Personally, my needs are different though and, once again, I presented very reasonable calculations that show that even only 16 characters just with idle, walk and talk animations already are well above half of the sprite limit.

Reducing the framerate of your animations (like going down to less than 25 fps where it will start looking choppy) is a matter of style, it might look good in a more cartoony setting for example (or as David Ostman and General_Traitor both mentioned, a handdrawn or painted look). I'm working in a realistic setting though and I'd really like fluid animation. I think AGS should deliver.

I assume changing the sprite limit isn't as trivial as it could or should be and I respect that. Just asking for a little heads up on if we can ever expect a raise (in the near future).

40 fps is *just* enough for basic point-and-click games to not feel unresponsive - even then gradual camera pans or fades work much better at a slightly higher framerate. The actual need for more than 40 fps, however, arises as soon as you include any kind of arcade sequence into your game (as is the case in my game), try playing any kind of action/arcade game capped at 40 fps (a shooter, a platformer, a real-time strategy game or anything like that) and you have to admit it is not really playable/responsive at all. Games that rely on quick reflexes usually run at 70 (vsync on) or, even better, 100 frames per second without vsync - for a very good reason.

I don't know why Proximity multiplied his sprite-needs by the number of rooms but my calculations don't do that and also show the need for an increase anyways so no need to focus on his (I assume) mistake.

Rendering 2D sprites from 3DS Max is a super common technique that has a similar history to that of pixel art, Calin. In fact, some adventure games even today use the same technique as it still allows for more detail on characters and a much wider audience (they don't need kick-ass systems to display the millions of polygons you need to render a 3d character with the same detail as a 2d one).

Lighting information is not necessarily lost, you can bake some awesome lighting (including the ambient occlusion term) into your models that would otherwise be either impossible to correctly calculate in Wintermute or any 3D engine or, once again, require some kick-ass end user systems. There's a ton more reasons why using a 3d program to render out 2d sprites is a legitimate way to create game graphics, it really isn't 'absurd' one bit. For your reference, I could call working hours on pushing pixels around absurd (but I won't because I understand and love pixel art as well :p ).

@monkey:

I didn't mean to imply that you were talking out of your rear, but it certainly would help your case if you could maybe address my concerns that I expressed earlier - even if its just a couple of one-liners!


@dbuske:

The calculations I posted earlier show that you don't actually need to make a big game at all in order to reach the 30k sprite limit. When you have the freedom to render out sprites for your characters with a 3d art package such as 3D Studio Max it is very tempting to actually go for smooth animations which, in a fluid 60 frames per second game for example, mean you need somewhere between 32 and 48 individual sprites for a single loop of a walk animation.

There's much more involved in that approach than just inventory items and global variables. What if I want to make a change in the interface? I have to remember to open and make the change every game. What if I want to change the player walk animation a bit for example? Need to commit the changes multiple times and test run every game individually to make sure it is all 100% in sync still.

What about translations? I'd have to save the user selected translation as well and then find a way to start the next game with that translation. What about room variables holding whether or not some door was opened or whatever? Needs to be saved.

The game options (music, sound fx, speech and ambiance volume levels, text reading speach, voice enabled, gamma and so on) all gotta be saved.

Plus it makes it very easy for people to modify those textfiles and cheat.

Unless there's solutions to these issues (just the first that come to mind really) I really won't be impressed or convinced...

The RunAgsGame workaround is clever but a pain in the *** no matter what way you look at it.

I have not yet reached the 30k sprite limit indeed (at 10k at the moment) but it is closing in and it's very easy to make estimates regarding how many sprites are needed. 30k is a number nobody will ever reach with hand-drawn sprites I'm sure but I'm working together with a professional senior artist at a real gaming company and we are shooting for a very modern visual style. An NPC has 8 walking and 8 talking loops as well as quite a bit more depending on their role. Say 20 loops on average with lengths between 32 and 64 frames mostly, say 48 on average. 16 of these NPCs already bring us to half the 30k limit, and 16 NPCs is certainly not all that much for a decently long game. Combine that with lots and lots of graphical animation for the various rooms (animated smoke overlays for example) and we are closing in on 30k very quickly. That's the power of rendered graphics and the bane of the programmer.

EDIT: And I forgot that each NPC also has an idle view for all directions. Then there's the player character with pick up animations for different heights (low, mid, high) in all 8 directions. Theres the animated cursors, menus and interfaces and so on.

I might actually run into the same problem for a project that uses pre-rendered graphics with lots of animation so I'm kind of interested in the same!

How trivial is upping that limit?

Sorry for being so slow at responding, I'm extremely busy due to an internship currently.  The errors mean that something goes wrong when trying to render meshes, but apparently only some fail (the pipe and hand mesh) and the rest appears to work fine. What that is that's going wrong I really can't tell. Do you have access to a different machine and could try it out there? I and others have used the plugin and tested it out and it seemed to work for everybody so far except you.

At the moment you can only create models/levels and so on in 3DS MAX. Don't know what exactly you mean with integration into AGS in future versions? Integrating a 3d model editor to use seems incredibly hard and time-consuming, wouldn't hold my breath on that one.

Awesome, thanks a TON, BH! I'll store it. Try that Ian and let me know how it goes (just go through the DLL files of Razerblade that you have in the Editor directory, in the test game directory and maybe even in the compiled folder in that and replace the DLL with that one BH posted!

What I think this plugin needs too is some sort of editor. Maybe I'm just spoiled by engines like Unity and UDK but I think it gets really technical without an editor to see where you are placing things.

Hm yeah, good call. While developing a full-blown editor is pretty much out of the question as far as the workload goes for me, I think we could use a map/level/world format to accompany the model format. These levels could then be made in the same 3D program that is used for making models with the difference that you could place models in it. I should think about that, really too busy for anything in the near future though.

EDIT: I have actually given the testgame a try now with the plugin file that I posted originally a couple posts above and it does work with that, must be a problem on your end. Try to run in windowed mode, update graphics drivers and so on.

Hm so that means either I did make changes to the plugin after release (that I can't remember right now) or there is a problem with the plugin running on your system - kinda unlikely though. In any case, to test we would really need someone to upload the original DLL file from back in the day.

Anybody still got that?

The plugin is still in development BTW, I recently made some progress getting actual skeleton/bone based animation implemented into the custom model file format, once that works it's high time for a 1.1 release!

The DLL is the only thing it should need to install properly and show up in the 'plugins' section of the AGS editor. You said in a previous post you copied the DLL into the directory of the demo game? You need to copy it into the directory of the AGS Editor instead. Also make sure to run the right version of the editor in case you have more than one installed.

Ie. make sure that the 'AGS Razorblade Plugin.dll' file is in 'C:\AGS 3.2.1' (if that is your install location of the editor) and then, in that folder, run the 'AGS Editor.exe'. I sometimes made the mistake of using my desktop shortcut which would point to a different version of the editor. If you can confirm that you have done these steps and it's still not showing up, something is indeed very wrong.

Hm, I'm not 100% sure as to what the problem could be unfortunately. All I can think of is that I did some changes to it in the meantime between release back then and this re-release. Don't really have the time to look into it (sorry). If you, in your game script (or that of the demo) somewhere type "RB_" it should pop up the autocomplete window with a couple of Razorblade functions in there, does that work at all?

Unfortunately auto-complete does not work, all Razorblade functions seem to be unknown/undefined. 

Maybe any of the other Razorblade users can provide a download with a working version of the plugin and the demo game???

That would be helpful. If you open the editor and take a look under 'plugins', is the Razorblade plugin listed there? Is it greyed out?

Hm, I'm not 100% sure as to what the problem could be unfortunately. All I can think of is that I did some changes to it in the meantime between release back then and this re-release. Don't really have the time to look into it (sorry). If you, in your game script (or that of the demo) somewhere type "RB_" it should pop up the autocomplete window with a couple of Razorblade functions in there, does that work at all?