FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

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 - November

Pages: [1] 2 3
Game creators corner / Re: Project announcement: PARPG
« on: February 08, 2009, 04:59:07 am »
I'm already working on such a project, so I won't be of any help to you, but I'm just glad your retirement from FIFE doesn't mean you totally abandoned your game related aspirations :)

Framework development / Re: PyChan Feedback
« on: October 14, 2008, 03:50:45 pm »
Hello Phoku !

I'm glad to see you took the time to start working on FIFE again (even a little, but it seems you already done much in these few days).

I personally don't have time to pursue what I started working on (dialogUE system and editor) because of my architecture studies.

But since you are currently working on the UI, and since I plan to get back on my editor one day, i've thought you could maybe look into adding the following feature :
It could be useful to have text selection and edition functions (cut, copy, paste) for the dialogue editor, and  probably for other tools as well.
The text selection would require some additions to the core GUI itself.

Do you think this may find a place in your todolist ?

General discussion / Re: A new name for FIFE
« on: March 23, 2008, 06:42:45 am »
I like the idea, altough Barracuda proposed one in his first post :

1. FIFE Is (a) Flexible Engine

I would prefer :

Flexible Isometric FIFE Engine

General discussion / Re: Fallout-dat-support: Is it still needed?
« on: March 09, 2008, 06:05:50 pm »
I also think that in case someone wants to use fallout graphics - or any other fallout file - he could extract them and use them as-is instead of using the whole .dat

Framework development / Re: Dialogue Editor
« on: March 09, 2008, 03:31:28 pm »
Thank you for the ideas on features to implement.
I'll work on that as soon as the basic editing features of the editor are ready-to-use

Framework development / Re: Dialogue Editor
« on: March 08, 2008, 07:02:16 am »
Nicely done! Do you think someone like me, with limited programming knowledge and interest, yet a strong sense of logic, will be able to use this program for creating dialogue? Will it even be made available for me? Cheesy

I'll also answer to this question here because the subject deviated from pychan :
Yes, someone like you should be able to use it. But you will definitely have to familiarize yourself with some python base syntax. Because dialogues are easy to do as static things, but if you want to make dialogue interactives and evolving with the course of the game plot, you'll have to handle basic scripting of events, how to use triggers, and how to use the ruleset/characters base functions.
Tutorials will probably be made in the future so this is made accessible to "someone like you" (:)), but only when these features are ready to use, which is not quite the case for now.

Framework development / Re: Dialogue Editor
« on: March 08, 2008, 06:41:14 am »
Could this editor also handle group-discussions? I.e. the character talks with 5 people at once, arguing, and what he chooses to say will decide who in that 5-people group says something back, or with someone speaking right after. Maybe they could even speak in eachother's mouth.

This should be possible, I'll think on how to implement so the system stays the most flexible.

Could these events (or, variables I guess) also take into account something that happened while the player was away? Like in Fallout, where you go away for a long time, and when you come back a whole lot of stuff has been going on and the characters might even have forgotten about your last conversation, except this one important think you talked about.

This is possible, but the change, the "something that happened" you want to take into account, wouldn't be executed by the dialogue itself, but in the script of the event.
Example : you set a trigger that will fire fire an event "Time since last visit > 40 days" when the actual time exceed the time of the last visit by more than 40 days. In the script of this event, you do the changes you want to happen on the dialogues.

-First case, you want the dialogue to change totally : the event script would have to modify the default dialogue of the character so talking to him would load another dialogue.

-Second case, you want the dialogue to change just a little, let's say make access to a new dialogue branches possible, whereas it wasn't before. The scripted check just need to check some variables that would be set by the event, and if the event has already happened, these check leads to new dialogue branches.

A more precise example : Suppose one of the citizen of the city has disappeared. The timer triggered event, after 40 days, would set the following variable :
Code: [Select]
character.set("BillyHasDisappeared", '1')
Then, in the dialogue of the character, the Answer "What's up ?" would have a conditional targeting set. Suppose the node 3 is the node where the character say "This place is dead, man, nothing happened for the last two years at least !", and the node 4 is the node where the character "Billy, the farmer, has disappeared last night." The targeting script would contain the following :
Code: [Select]
if character.get("BillyHasDisappeared") == 1 :
else :

Hope this explanation is understanble.

Framework development / Re: Dialogue Editor
« on: March 07, 2008, 08:54:51 pm »
First, let me set some general explanation about how the system works :

A dialogue is composed of Nodes and Lines : a Node is an ensemble composed by :
-A Message : this Line contain the text that the speaker say to your player character
In the dialogue editor, nodes Messages are shown by the orange lines icon.
-The Answers : these Lines are the answers that the player character can say to the speaker.
In the dialogue editor, nodes Answers are shown by the green lines icon. Each answer targets one or more nodes : it means that when the player pick an answer, the dialogue will continue with one of its target nodes. If there is only one node, the process is very simple. If there are more than one node, you must set a targeting script that will redirect to the desired node depending of the result of a check (for example, an "intimidating" or "persuasion" ability check that would lead to either a success : the speaker stay or a failure : the speaker gets angry)

In addition to this scripted check determining Answer -> Node redirection, there are three other "script elements" you can set :
-Answer Condition : Set such a condition on an answer and a check script will be fired before the answer is shown, returning 1 if the answer must be displayed and 0 if the answer must not be displayed. You just decide when you want it to return 1, or to return 0.
-Answer Consequence : Set such a consequence on an answer and the consequence script will be fired when the player pick this Answer : you decide what you want to put in this consequence script.
-Node Consequence : The same as the one before, with the slight difference that the script is fired when the player get to the given Node

These scripts have access to 3 "objects" that should allow a dialogue writer to do anything :
-The player character object
-The speaker character object
-The ruleset of the game

Now let's take your example : you want to store an information "that will have an effect on the next conversation you engage in with the same character you talked to earlier".

The first thing to do is to set a scripted consequence of the player picking an answer : you create an Answer "Tell me more about your sister ?" in the desired Node, and then click the "Add Consequence" button. An "Answer Consequence" script element will be created : when the player will pick this answer, its content will be executed. You then have to fill this script element so you get the desired behavior : In this example, by writing :
speaker.set("TalkedAboutHisSister", '1')

The result is that when the Answer will be picked by the player, the script will create a variable "TalkedAboutHisSister" on the speaker, set to 1.

Then, you can create a new Answer, and add a Condition to it. You fill the condition script with the following :
if speaker.get("TalkedAboutHisSister") == 1 :
      return 1

Then the line will show only if the variable "TalkedAboutHisSister" has been set to 1, i.e. that the player has picked the answer "Tell me more about your sister" once.

Framework development / Dialogue Editor
« on: March 04, 2008, 07:07:00 pm »
Here's the current state of my work on a dialogue editor :

A screenshot is available here :

The editor can only visualize a dialogue for the moment, but I hope to make it capable of creating an entire dialogue from scratch, or modify one, for the end of this week.

Framework development / Re: PyChan Feedback
« on: March 04, 2008, 07:04:22 pm »
Oh yes I got further : the editor should be ready to use very soon.
Here is a screenshot of the actual editor : for the moment it can only visualize an existing dialogue, not create or delete one.

I created some sort of browser-like widget to make the arborescence. I made it the more flexible possible so it could fit well, with some rework, in pychan. It's not totally finished on my side, partly due to the pychan issues listed before. See the BrowserWidget() class in extensions/editor/plugins/dialogue_editor/ in the attached diff if you are interested.

The diff is attached to this thicket

Framework development / Re: PyChan Feedback
« on: March 03, 2008, 05:31:22 pm »
Another "issue" I found :
The resizing function of a HBox (resp. VBox) automatically set the height (resp. width) of any contained widget to the max height of its child widgets.

I'm not sure this behavior is really useful, but more importantly : it causes display bugs.

This happened to me : take a HBox that contain, an Icon and a VBox :
1) The Icon's height is set to the VBox height when the HBox resizing function is called. This should not happen, first because it cause strange visual appearance (an Icon's height isn't supposed to change dynamically), second because of the following :
2) When the HBox resizing function is called a second time (suppose the VBox content has changed), the VBox height is flawed : after being set to the correct height it should have based on its content, its height is then set to the Icon's height, which itself is flawed. The result is the two having a too important height coming from nowhere.

A solution would be to set the Icon max_size, but this would just be a "hack" : the fact is I hardly get the point of this automatic height/width expanding.

Framework development / Re: PyChan Feedback
« on: March 03, 2008, 11:30:11 am »
This code will cause pychan to draw the elements incorrectly :
Code: [Select]
<ImageButton up_image="path" down_image="path"/>
<Label text="Test"/>
And basically any HBox with an ImageButton in it : the ImageButton won't show, only the Label gets drawed

However if you try this code :
Code: [Select]
<ImageButton up_image="path" down_image="path"/>
<Label text="Test Label"/>
The ImageButton is drawed, but the button width is the width of the Label, whereas it should be the width of the image.

Something else : by default, it could be good if the ImageButton hadn't a border around it.

Also, concerning Icon :
Code: [Select]
<Icon image="path"/>
<Label text="Test Label"/>
Try this code : the Icon image width is set to the Label width, whereas I think it should stay to the width of the Icon. Maybe by just setting the max_size of the Icon/ImageButton automatically ?

In the case of the Icon widget, HBox layout seem to work correctly. Just the annoying border.

Also same remarks about borders : I don't think Icon should have a border by default.

Framework development / Re: PyChan Feedback
« on: February 22, 2008, 11:40:17 am »
I have two requests to make :

-Possibility to hide child widgets and not just the top container of a hierarchy : I presently need it for a browsing interface for my dialogue editor, to expand/shrink "folders", like in any explorer interface.
-Possibility to delete widgets : would be really useful for dynamic interfaces such as inventory or dialogue

EDIT : I just found out about removeChild(). I assume a removed child is totally deleted. So it only resolve my second request, but not the first one.

Framework development / Re: Draft of Dialog system - enhancements
« on: February 21, 2008, 04:24:52 pm »
Work on the dialogue system is finished. It can be improved, but I think this is good for a start.
The new diff is attached to the ticket here :

Feel free to test it (an example dialogue is included in island demo) and tell me what you think.

Framework development / Request for a getTopInstance function
« on: February 20, 2008, 11:47:32 am »
This is a request to Jasoka, as he seems to be working on the instance picking functionalities.
So, jasoka, could you think of a getTopInstance function ? Or can the top instance on a determined screen point already be get with the actual getMatchingInstances function ?

By the way, by top instance I mean the instance to which the clicked pixel belongs, if not covered by a semi transparent pixel of another instance. (and the top semi transparent instance if there is any)

I think this will be needed in future, for nearly all in-game click based features (context menu, attack/skill targeting, etc...) but also for editor features (instance dragging)

Pages: [1] 2 3