Please login or register.

Login with username, password and session length
Advanced search  


Forum rules - please read before posting, it can save you a lot of time.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - organican

Pages: [1] 2 3 ... 5
Game design / Re: Death
« on: December 18, 2007, 10:53:14 AM »
BUT: As it was already said, you have to think about how to handle Death. To keep the player in the flow, it's not advisable to present a "Game Over - Load Again?" screen. For simple handling, I would suggest a death sequence, showing the player what happened, and then auto-reload the scene he died in to have him play again imeaiately without and choice. If you give players a choice here, the answer might also be "no".

I read an interesting game design article about player choice requesters -- nearly all of them are counter productive, so you should generally avoid asking players what to do. For example, if you reach a checkpoint, don't ask the players wether they want to save -- of course they want to. Just save and continue. Same here: If the player dies, just load and continue. If the player really wants to bail out, he will find his way through the menu. Otherwise keep him playing without disturbing requesters, even after death.
No, most players don't like interruptions in the game. But there are also those who think that auto-saving is like cheating, or that it ruins the atmosphere of the game, or that it makes dying feel like it's without consequence. "You die, and then you're automagically restored, why even have death at all?" So however you do it you end up disapointing someone.

Maybe one way to do it, would be to make sure that the player can choose in the game settings if they want to have Auto-save and reload after death (on/off).

Then the hard-core gamer can have his game over screen when he dies, and casual players are revived with auto-reload.

Technical forum / A partial screenshot?
« on: January 17, 2007, 04:29:13 PM »
Hi muties, 8)

Just a simple question...

Is it possible to take a snapshot of just a part of the screen in wme?

Like this:



Is that by any chance possible?  ???

Game design / Time in adventure games
« on: January 15, 2007, 08:45:10 PM »
Hi,  8)

I was thinking about the passage of time in adventure games.

Things like how it affects the gameplay, and which system is the best, and what are the ups and downs of the passage of time in adventures.

After some thinking I came to the conclusion that there are 4 different models for time in adventure games:

1. Time doesn't pass at all in the game, or time only passes between different chapters or parts of the game. This is the most common.

2. Time passes all the time in real-time. This is very uncommon in adventure games. One example was the game KGB, where you had to do things at the right place at the right time. Another example, if it can count as an adventure game, is Zelda: Majoras Mask. There was a three-day cycle and a special calendar system, where some things only happened at certain times. You had to meet people and do things at a specific time, so that new things could happen etc.

3. Time only passes when important things happen, like when you talk a certain person or take an important object. So if you meet that person or find that specific object, or do something important, time passes for example 10 minutes. But you have to play it cool, because you can only talk to some people at certain times, and there are doors that are only open at specific times, etc. So just like real-time adventures, it can be quite annoying if you miss important clues or forget to talk to someone, or do something else really important. I've only seen this time system used once, in "Cruise for a corpse".

4. Time passes in the game, but only in between different time blocks. Each time block can be for example two or three hours (10:00-12:00, 12:00-15:00). And within each time block time stands still, and you only move to the next block when you have done everything you're supposed to in the present time block. New things will also happen in each time block, and people are at different locations, and so on. This model was used in Gabriel Knight 3, and maybe also some other GK game.

So, in your opinion, which is the best model?

What are the pros and cons with using time in adventures?

And will it just frustrate and confuse the player, or can it also add to the gameplay?

Technical forum / Re: can I do resident-evil-style games with wme?
« on: March 14, 2006, 05:50:08 PM »
Well, it should be possible to make one scene containing several rooms.

But I'm not sure if it would take up a lot of computer resources to show a really really big scene instead of many small ones. (We should leave that to Mnemonic to answer...).

But it would be cool if enemies could follow you around corners and into other rooms...

Another way, would be for the game to "remember" if an enemy is chasing you when you go to a new scene. Then you somehow import him a couple of seconds after the main character. Just an idea.

But doing many small scenes inside one larger scene would be best solution... for remembering the enemies damage, how far away they are from the player, what they ate for lunch ;) and other things...

and can you change the movement system from point-to-click to a direct one with the arrow keys?
You can have direct control in wme, both for 2d and 3d characters.

Igorrr's "Spank the hero" minigame uses direct keyboard control for its 2D character...

Technical forum / Re: Get all items
« on: February 20, 2006, 11:49:38 AM »

But wouldn't it be even better to have them in a separate script that you attach to the game.script or scene_init.script?

Then you just have to unmask one line of code.

You either say this:

//#include "scripts\takeall.scripts"

or this:

//this.AttachScript("scripts\takeall.script"); a script somewhere.

Something like that.

And then you just mask/unmask it whenever you like.

General Discussion / Happy year everyone!!!
« on: January 01, 2006, 10:38:41 AM »
That's right...

Happy new 2006, folks!

A whole new year with all new possibilities for all us wintermuties... 8)


General Discussion / Re: Merry Christmas and a Happy New Year
« on: December 24, 2005, 08:21:33 PM »
Merry christmas to you all!!

 :) 8) :D ;D

Technical forum / Re: Diagonal scene?
« on: November 22, 2005, 12:46:48 AM »
I don't understand what your script does, Organican... can you please explain?


First I created an "empty" entity in the scene - no sprite, no nothing.
I called it "diagonal_camera"

You can call it what you wish of course.

Here I made an invisible entity in SceneEdit that I will attach the camera to in a moment. It will be controlling the scrolling.

Then I attached a script to it.
And in the script, I wrote:


 { this.X=actor.X;
This means that the diagonal_camera entity's x and y positions will be the same as the actors.

If the actor is at x200, then the diagonal_camera will be at x200 y200. If he's at x350, it will be at (350, 350).
And when the camera control is attached to it, the scene will scroll from the upper-left corner to the lower-right, diagonally.

Then all I had to do was to add the lines

var diagonal_camera = Scene.GetNode("diagonal_camera");

Game.MainObject = diagonal_camera;

in the scene.init script
The line Game.MainObject = diagonal_camera;
means that the diagonal_camera entity will be given control of the scrolling.

If the scene is turned the other way


Then you have to do some calculations.

Take the width of the game area and subtract the width of the screen from it.

If the game area is 2500 pixels across, and the screen size is 800*600,
then you calculate 2500-800=1700

Next you type this in the diagonal camera_script instead:


And do everything else like the other example.

I haven't tried this code, though. But it should work just like the other one that I tried.
Simple math.

Tales just posted in the thread and explained just what he meant by diagonal.
I see...

In that case...
No, I'm not sure how that can be done.

But it's a very interesting concept, Tales.

Update again:

I think it can be done if you rotate the background image like you already did.

Then if you rotate the actor with the rotate code
Code: [Select]
actor.Rotate=-45;both the scene and the character will be seen from the new camera angle.

Just remember to add the line
in the actor file.

For molly (from the wme demo), the file is called

In it, it should look something like this:

Code: [Select]

  NAME = "molly"

You can open it up in notepad.

This could be one way to do it. To rotate every actor and entity like this (and rotate the background in a graphics program).
Not sure if it would use a lot of processing power though.

It's worth a try at least.

Edit again

I noticed that the scale levels in WME only works horizontally.

So that means that the scene can't have any scaling in the "z dimension", because it will look wierd if things to the right looks bigger etc.

So the only way to do this then, is to either have very little rotation in the scene, just a few degrees.

Or... if the scene's walkable area is "paper thin", or flat, like a 2d platformer (Mario) or something...
or if it just takes place in one plane... like a narrow path...
then it might work. But unfortunately, with horizontal scale levels, you have to find a way to do without the scaling in such a scene.

Though it might be worth it if the character and the scene is rotated, 60 degrees to the left or something.
That would be really cool.

But it means that the actor can't walk in the "z direction", towards and away from the screen... in the "depth" dimension.
Because he'll become bigger when he moves to the right if it looks like your picture.

So if you can do this, you will probably just use it in a few scenes. Because the player can't walk around much.

Sorry :(

This was the best I could do.

Technical forum / Re: Diagonal scene?
« on: November 20, 2005, 11:47:01 PM »
Interesting idea.

I think it should be doable... I think.

With a little scripting...

Just as long as the scene is no more than one screen "wide".

(Like this:)
Code: [Select]

And here's how I did it.

First I created an "empty" entity in the scene - no sprite, no nothing.
I called it "diagonal_camera"

You can call it what you wish of course.

Then I attached a script to it.
And in the script, I wrote:

Code: [Select]
 { this.X=actor.X;

Then all I had to do was to add the lines
Code: [Select]
var diagonal_camera = Scene.GetNode("diagonal_camera");

Game.MainObject = diagonal_camera;

in the scene.init script

Hope this works!

General Discussion / Re: 360-degree panoramas
« on: November 05, 2005, 07:34:22 PM »
If this is a first person game, couldn't you have an invisible character that controls the camera?

And, say, if the mouse pointer is at the left part of the screen, that actor is automatically walking to the left.

Until he's at the "leftest" part of the scene, when he and the camera will be moved to the rightmost side.

I'm not sure how smooth it would be, or if it would work, but I think it's an idea to look into.

I don't have time to check the docs right now but if I remember currently there as two attibutes that always return the X,Y coordinates of the mouse cursor. So, yes, it's possible to do that and the scrolling will be as smooth as Jerrot's demo you can find in the link I posted in my previous post. But it still won't look & behave like a true 360 panoramic engine. Check metamorphiums excellent reply in the other thread.

Oh how stupid I feel!

I should've read the whole thread.


He even used an invisible character and all...

And, about the 360° view, you're right, of course, it wouldn't be a true 3-dimensional panorama.

It would be a 2D representation of a 3-dimensional space.

Kinda like how a world map is a 2D representation of the sperical world,
and not a depiction of the real thing. Of course!

But in an "artistic sense", a 2D representaion can be just as good as the real deal, just different.

I have never really liked 3D for making pretty pictures anyway. They never ever see it from the view you had in mind, anyway.

This "representation" thing would be the 4 direction pictures of the room stretched together into a "2D panorama" of the real 3D space. Something like that.

And I'm not sure if that could work in a game.

Maybe the idea is just too wierd.

But still interesting somehow, though.

No, the idea just makes me freak.

Enough with the 3D already! I can't stand it!


General Discussion / Re: 360-degree panoramas
« on: November 05, 2005, 05:32:14 PM »
Something like that is possible but it won't look good.

Check here

Before you gave us the link, I came up with a similar idea to that thread.

You make a several screens wide panorama. And you add half a screen to the left and a half to the right.

Then I got another idea.

If this is a first person game, couldn't you have an invisible character that controls the camera?

And, say, if the mouse pointer is at the left part of the screen, that actor is automatically walking to the left.

Until he's at the "leftest" part of the scene, when he and the camera will be moved to the rightmost side.

I'm not sure how smooth it would be, or if it would work, but I think it's an idea to look into.

Technical forum / Re: Action/Shooting script.
« on: October 28, 2005, 12:16:30 PM »
That would be so awesome if some one could do it, but then we would have to create a damage mechanism, where if you shoot a certain object it gets hurt.

 ;D The way moi see it... There are three options then.

Either use the "click and shoot" idea I mentioned upthread.

If it's too hard to make a damage mechanism, maybe only allow them to shoot "special targets". Like monsters, and maybe a few things like glass panes, a few weak crappy doors, etc.

Hidden behind some crates  ::), our hero practices target shooting at a window on the other side of the room. The local zombie walks over there to see what's going on, and thus you can either shoot him  :'( in the back, or run away. Great combination beteen action, strategy and puzzling. Something like this would be kinda nice. :)

Another way to do the shooting...
When the player right-clicks or presses the button, the bullets are just fired in the pointer's direction. Which means that they pass through anything and everything between the player and the cursor.

The third way is if the bullets are fired in the precise direction the player character is turned.

They all have their ups and downs. So choose wisely.

Edit: You have a PM. So check your 'inbox'.

Thanx Mnemonic.

While offline, I tried with

Code: [Select]
global position_X;
global position_Y;


{      position_X=this.X-130;
                      actor.GoTo(position_X, position_Y);

{   position_Y=this.Y;
                      actor.GoTo(position_X, position_Y);

                      actor.GoTo(position_X, position_Y);
                      actor.GoTo(position_X, position_Y);


I worked so so... in a bad sorta way.

Igorrr's script is way better. ;D

Just one thing. It's wierd that the "direct control" script doesn't work by itself in my game (it did in Ogorrr's).
I had to instert it into the actor's script file. And I couldn't find what files are referencing it, either.

Oh well...
At least it works all right. So who am I to complain? :)

Much better now. Thanks.

Okay, alright...

Is there an easy way to have the sound fade in and out as you get farther away from things, also in the vertical direction. I know it works left and right...
but not up and down, it seems.

Edit: i tried with
where position_Y is the actor's Y position. But it didn't work. What am I doing wrong?

Edit again:
Code: [Select]
var ent = this.entity;
...doesn't appear to work either. What am I missing?

And now for the second question...

What's the best way to implement direct control for 2d charcters. I mean:
up - he walks up.
left - he walks left.
Right - hw walks right.
Down - he walks down.

Like regular action movement.

Or is direct control out of control for the 2d characters altogether?

What's the best way to do a "simple action movement" for the actor?

Pages: [1] 2 3 ... 5

Page created in 0.138 seconds with 19 queries.