Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[deadworm222]

Hello, WinterMute users! I got used to using Agast, and when the gamedev team I joined (ForeverDream Studios) used Wintermute, the transition from one engine to another was a... hmmm... a slight shock. So I made a long nitpicky list of all the features I didn't like about in WinterMute.

Here it is. It might sound like I'm shouting and angry, and I was, when I wrote that... there really isn't that much I can do about it now! Some of the points (like points 5 and 6 ) are really nitpicky, and needn't be answered. And point 4, for example, is probably a thing I just need getting used to.

1) What's the point in having a static object in the backgound image and then also a separate object to take care of masking? Why not just create an object with no sprite and only a clickarea and deal with what-is-in-front-of-what with a huge z-buffer bitmap?

2) You have to learn the scripting language AND the usage of the IDE in order to make WinterMute games. Why not just learn the scripting language? Unfortunately, if you want text-only editing, it's rather hard because information about one object is put in many different files. For future releases, I hope there will be a possibility to choose between a text editor (which by then will hopefully be an internal text editor) and the Scene Edit & wizards & such. ProjectMan is very nice, though.

3) There's loads of buttons in the GUI. How about simple keyboard shortcuts like "+" for choosing the add point-tool, etc.? (Or are there keyboard shortcuts already?)

4) Why the difficult "order list" thing? Why not just 255 z-buffer indexes for objects?

5) The walk-area system is way too difficult. Block areas? Single points? Why not just a system to define the walk area!? Waypoints? Why not just add a waypoint to the corner of each block area automatically?! Well, there is a benefit, actually - if you want, the ego will not walk close to the corners, which is realistic.

6) In Agast, I could have created a new object with a sprite and click areas in three seconds!! Why all the hassle with the windows? Why having to attach a script to an object? Why not put everything conviniently into one single file?

Although WinterMute has many great features (for example antialiasing and sound looping & stuff which Agast doesn't yet have - although antialiasing could be done and has been done with alpha channels in Agast), the GUI isn't the best possible yet.

*sigh*

Please tell me this is just a bad first impression... or a culture shock...

Another thing is, that Voodoo 3 cards aren't supported. There probably isn't any way round this?

Seriously, I hope I will have fun with WinterMute and I also hope this forum community will aid be in my quest to try to create a notepad for the game...

[Mnemonic]

(Just for the record, this is a modified version of deadworm's yestedays post from the AGAST board. I already answered there before seeing this post.)

[Mnemonic]

Another thing is, that Voodoo 3 cards aren't supported. There probably isn't any way round this?

Hmm, I'm not aware of it. I thought the problem with 3dfx cards have been solved long time ago. Did you use the latest build?

[deadworm222]

I believe I did, but the update might not have worked, or maybe it went to a different folder, or I have to do some tricks before the new version works. It just says "sticking back to software."

[Mnemonic]

Ok, then it's not able to create the 3D renderer for some reason. You can check the log files (they are in the project folder), there should be more details about what went wrong.
To get rid of the annoying message everytime you run the tool, you can disable the 3D acceleration in the settings window.

[deadworm222]

I've already turned it off.

I'm very sorry if I offended you.

[creatorbri]

Morning everyone. I'm Brian, of ForeverDream Studios. You'll surely see myself, Jussi (deadworm), and other members of the ForeverDream Team poking their heads in now and then, since we've decided to make Wintermute our official development tool for our upcoming adventure game, Curves of Danger.

First I want to comment that while I respect Jussi's opinions and complaints, I personally have been very impressed with Wintermute so far. For the most part I'm thrilled with the way its all handled. Its an excellent, free alternative to the not-so-free SLUDGE (I've never done much with AGAST).

My only major gripe is concerning the vast number of individual scripts that are required to build a game -- it can get confusing and sometimes even spaghetti-ish. This is Number 2 on Jussi's list. What I'd really like to see to handle that is a better way of juggling all the scripts than just listing them by folder. Our maybe a debugger would help, since you could use that to follow the actual progression of the compiler through you scripts.

[Mnemonic]

I'm very sorry if I offended you.

I don't get offended that easily I was just a bit... surprised by the tone of your post and I think it was a little unfair to post it at the AGAST board. But I agree with what Todd said.
We shouldn't take these non-important things too seriously.

Morning everyone. I'm Brian, of ForeverDream Studios. You'll surely see myself, Jussi (deadworm), and other members of the ForeverDream Team poking their heads in now and then, since we've decided to make Wintermute our official development tool for our upcoming adventure game, Curves of Danger.

Hi Brian, (it's evening here actually )

My only major gripe is concerning the vast number of individual scripts that are required to build a game -- it can get confusing and sometimes even spaghetti-ish. This is Number 2 on Jussi's list. What I'd really like to see to handle that is a better way of juggling all the scripts than just listing them by folder. Our maybe a debugger would help, since you could use that to follow the actual progression of the compiler through you scripts.

Although I don't think it is a critical issue, because the scripts are sorted by scenes, and there usually aren't that many scripts in one scene, I can also see a lot of space for improvements, namely in the SceneEdit tool. I'd like to have the template system integrated in SceneEdit as well as a better ability to access scene object's scripts.
The next generation of tools is planned and I'm working for some time on preliminary tasks to allow that.

As for the debugger, I didn't plan one yet.

[creatorbri]

I'll try and clarify my concern somewhat.. as I'm learning the scripting language, I'm finding that I've got to jump between scripts in drastically differing locations to follow the progress of the program. Handling for a left-click is defined in multiple places. As defined in the default scripts, the process for handling a right-click on an object and executing the "Talk" action on the object involves the game.script file, menu.window, menu.script, and then the_object.script, which are located in several different folders. Item-level event handlers have to be defined in individual script files that necessarily are named by the names of the items they refer to. In the default script nearly-identical event handlers are re-defined in every single item script.

None of these are horrible issues, they are simply minor inconveniences that in my personal view make things a bit convoluted. And actually, most if not all of them can be rewritten to fit my taste better.

I thought about it some more, and I think the number one thing that bothers me about this script management method is that the order of the program is all but incomprehensible. After poking around it occurred to me that game.script must be processed before anything else, but I would really appreciate it if the IDE could somehow display the order things are going to be called in.

Other organization possibilities: Perhaps a more parent.child oriented approach, or else a tree-like structure that clearly divides the scripts into hierarchical levels of importance. I don't know -- dunno if I'm even making any sense. At least I know what I'm talking about.

[deadworm222]

I don't get offended that easily I was just a bit... surprised by the tone of your post and I think it was a little unfair to post it at the AGAST board. But I agree with what Todd said.
We shouldn't take these non-important things too seriously.

You see, the post in Agast forum wasn't about WinterMute, it was about my frustration - and it certainly wasn't meant as criticism! If I want to criticise, I'll be more civilized: like in this thread.

[Mnemonic]

Brian:

Ok, let me explain the overall concept a bit, I hope it will help you to understand the execution flow.

The crucial thing to uderstand is that WME tries to be a (more or less) object-oriented system. It provides you with a bunch of predefined objects (classes, actually) you use to build your game (scenes, entities, actors, regions, windows...). Most of the objects consist of two parts. One defines the appearance (the body) and the other one defines the internal logic (the brain). The "body" part is stored in all those definition files with "weird" extensions like .scene or .actor, and those files will be (in an ideal case) edited by the GUI tools. The "brain" is represented by a script(s). So the general approach is: I create an object, then the script and I attach the script to the object (that's why I have so many scripts).

A script typically contains two blocks: the raw code and the event handlers. The "raw" code gets executed when the object is being created (it's actually a constructor, to use the OOP terminology). After the constructing code is finished,  the script is suspended and only waits for an event to come and trigger an event handler.

Example:

Code: [Select]

object.X = 100;
object.Y = 200;

on "LeftClick"
{
  // some code to handle mouse clicks
}

In this example, when the object is created, it's position is set to 100,200. After that the object awaits "LeftClick" events.


Ok, let's get back to the original question. What you need to know it that the game itself is also an object, hence it also has script(s) attached. It's obvious the game's script is the very first thing to get executed, because the game object is always the first one to be created. When the game loads a scene, the scene's script is executed. When the scene loads an entity, the entity's script gets executed, etc. etc. Is it clearer now?

The game's scripts usually contain the general code, which handles things like in-game menus, caption display, save/load etc. This is the "core" which is done once and it is rather stable during the whole development process.

Most of the time you'll be editing scripts related to scenes. Both the scene initializations (scripts attached to scenes themselves) and event handlers for scene objects.

[creatorbri]

Yeah, that actually clarifies things immensely, I appreciate it. I do still need some help understanding the following, though, if you wouldn't mind:

1) Attaching Scripts - Under precisely what circumstances should I attach a script to an object? If I understand correctly, I should attach a script to an object whenever I want that object to immediately execute a set of instructions, and/or wait for events, independently of any other object or script. Is this correct?

2) Initializing Music - Where in the code should something like music be initialized? Based on WME's intended architecture, is it proper practice to start playing a music file from within the scene_init.script, or is it best to do this somewhere else?

2b) How many music / sound channels does WME support?

3) Items -- The default project contains an "items" folder with a sample book item in it. Is there some way to use these pre-defined items, or do I have to manually place it & reference the image and script from within my scene? Is an item always an entity that must be placed in the "body" of the scene?

4) Function -- I'd like to define some functions so I don't have to re-type as much code, but I'm not sure where to put them exactly. If the function is dealing with interactive objects in the game world, should it go in one of the main game script files? If its only going to be used within one scene, should it be in the scene_init.script?

I apologize if these are stupid questions or not well thought-out, its extremely late and has been a very long day. Also, I know this is probably not the best section to put them in, since it's kind of evolved into a "How Do I Do This" discussion -- but my goal is to understand what Wintermute can and can't do, and how it works in general so that I can stop complaining about it.

[Mnemonic]

If I understand correctly, I should attach a script to an object whenever I want that object to immediately execute a set of instructions, and/or wait for events, independently of any other object or script. Is this correct?

Yes, exactly.

2) Initializing Music - Where in the code should something like music be initialized? Based on WME's intended architecture, is it proper practice to start playing a music file from within the scene_init.script, or is it best to do this somewhere else?

Yes, if you want the music to start playing immediately after the player enters the scene, the scene_init.script is the right place.

2b) How many music / sound channels does WME support?

WME still supports only one music channel, but there are other options. See these threads for a detailed discussion:
http://www.dead-code.org/forum/index.php?board=3;action=display;threadid=173
http://www.dead-code.org/forum/index.php?board=12;action=display;threadid=188

There's no practical limit on the number of sound channels.

3) Items -- The default project contains an "items" folder with a sample book item in it. Is there some way to use these pre-defined items, or do I have to manually place it & reference the image and script from within my scene? Is an item always an entity that must be placed in the "body" of the scene?

Those are two different things. There are the inventory items definitions (the items.items file), but how the items are actually displayed within the scene is up to you. But they are indeed usually implemented as entities.
I'm planning to allow the user to make a connection between those two to reduce the scripting needed for the most common situations.

4) Function -- I'd like to define some functions so I don't have to re-type as much code, but I'm not sure where to put them exactly. If the function is dealing with interactive objects in the game world, should it go in one of the main game script files? If its only going to be used within one scene, should it be in the scene_init.script?

The function must be present in a script it's being called from. If you need to share some functions between multiple scripts, put them into a separate file and use the

  #include "path\filename.script"

construct to insert them to another script.

[deadworm222]

May I ask something: As a simple excercise, I'm trying to make a seamless looping script (I can't use the default PlayMusic("music.ogg", true)

function PMusic(filename, loopstart, loopend)
{

//filename: whole filename and path in parenthesis "scene/room/test.ogg"
//loopstart: the start of the loop in milliseconds
//loopend: the end of the loop in milliseconds

[McCoy]

mhh try to use looplength-1, or looplength-2, till you get a gap-free loop. Anyway, I dont know why you can't use the PlayMusic("file",true); thing...