So you seriously consider to create your own (indie) RPG?

[mvBarracuda]

So let's try to create a win-win situation for both sides We're currently working on an open source 2d (RPG) engine with indie developers as our primary target audience in mind. You prolly already know the project as we got a thread here at the Codex; if not, you should simply check this one out (yes, this thread also contains screenshots and download links, in case that you just care about the eye candy and not about this article at all):
http://www.rpgcodex.com/phpBB/viewtopic.php?t=13532

The work on the engine is coming along quite well lately and now we're thinking about finally tackling the initial design of our future scripting API. The scripting API will heavily influence how scripting and the whole gameplay implementation for FIFE-based games will work. As we're targetting indie developers, we would like to get some feedback how our scripting API should look like to actually be flexible, easy to learn and use but also powerful enough to work for all kind of different games that you may have planned.

There are different methods how the design of such a scripting API could be tackled but we decided to go for something that's called use cases. The idea behind these use cases is that interested developers who think that FIFE might become a good solution to create an own RPG with, provide examples for their games. Our team will analyze these examples after that, create a list of requirements for the scripting API based on the examples and finally start to implement all of this into the engine.

So what is an use case? Well use cases are interaction situations that are described in a very detailed and structued way. While this surely sounds awfully complicated, you'll admit that it's quite easy to get into it as soon as you've wrapped your head around some examples. We already have a bunch of use cases listed at our wiki so this should be your starting point if you consider to support us by providing new use cases:
http://wiki.fifengine.de/index.php?titl ... _like_game

So why should you "waste" your time by helping us? If you consider to use FIFE your an own project later, the provided use cases will ensure that the scripting API will support them. Or to rephrase that: if an use case is listed, we can ensure that your planned feature will be supported by FIFE. If there is no use case for it there is the chance that the scripting API will lack aspects that you might find important for your planned game. Additionally there might be some generous people around here who think that FIFE might be worth supporting even if they don't intend to work on any FIFE-based games later.

I hope the Codex is the home of some brave indie developers who might actually lend us a hand here; well, we'll see if that works out If there are any questions concerning this, just ask here and I try to clear up things. The idea should be easy to understand by reading the examples that can be found at the wiki though.

http://wiki.fifengine.de/index.php?title=Use_Cases

 

[KingBimbo]

SERIOUS QUESTION: Some Indie developers may have questions on how the GPL will affect their product.

 

[Psilon]

SERIOUS ANSWER: You can do what id Software does. Even though the engine is GPLed, the Quake III data files are still copyrighted and proprietary, and thus illegal to acquire without paying for the game. That said, GPLed source code basically means you have no hope in hell of applying any sort of key-based registration system to unlock demo versions.

 

[Selenti]

SERIOUS QUESTION: why are 90% of "indie developers" half-illiterate eastern europeans?

Did Fallout's 1 INT dialogues tap into a hidden and lucrative market?

 

[User was nabbed fit]

Did Fallout's 1 INT dialogues tap into a hidden and lucrative market?

Remind me to sig-quote that sometime in the future...

 

[Atrachasis]

The idea behind these use cases is that interested developers who think that FIFE might become a good solution to create an own RPG with, provide examples for their games. Our team will analyze these examples after that, create a list of requirements for the scripting API based on the examples and finally start to implement all of this into the engine.

While I personally am not very likely to use the FIFEngine (kudos and good luck for the project nonetheless), you might consider the virtue modifiers of Ultima IV as test cases:
Gaining Virtue in Ultima IV
Many of these are tied to dialogues, but there are some triggers (such as fleeing from a non-evil enemy or letting creatures flee) that call for quite a flexible scripting system. Maybe those would make good "use cases" for you - if you were theoretically able to remake UIV with FIFE, I'd say you have a winner.

 

[mvBarracuda]

While I personally am not very likely to use the FIFEngine (kudos and good luck for the project nonetheless), you might consider the virtue modifiers of Ultima IV as test cases:
Gaining Virtue in Ultima IV
Many of these are tied to dialogues, but there are some triggers (such as fleeing from a non-evil enemy or letting creatures flee) that call for quite a flexible scripting system. Maybe those would make good "use cases" for you - if you were theoretically able to remake UIV with FIFE, I'd say you have a winner.

Thanks for the pointer but we're looking for a bit more detailed ones

E.g. we would be interested in a detailed use case by anyone who wants to add crafting to this RPG. Bartering, dialogues (e.g. Torment-style with more than two dialogue participants), looting, or even the screen in Fallout where you can pick a perk are rather good examples for use cases. Now we just need somebody who seriously writes them down for their games

 

[denizsi]

So if one is to make a suggestion, the "use case" illustrated in the link is the format to follow?

The descriptions in that link are too specific and doesn't do a good job of presenting general examples, in my opinion. That said, I'm not sure I get the idea. Let's take bartering dialogue in Fallout. Would that be an example of a very strict use case, eg. there must be these many buttons for this and that, there must be a header for background art here, text goes there etc.?

Perhaps I'm getting it wrong, but is it not possible to give control of commands, functions and operations with GUI elements in a modular fashion, including the core mechanics in a game?

 

[mvBarracuda]

So if one is to make a suggestion, the "use case" illustrated in the link is the format to follow?

Basically yes If you think an important subsection is missing there, let me know and we'll add it.

The descriptions in that link are too specific and doesn't do a good job of presenting general examples, in my opinion.

It's not about general but about very detailed special examples. Thinking in use cases requires you to really concentrate on details you wouldn't mention if you just explain how something works in your game to somebody else.

Let's take an example: crafting in Arcanum. If you would explain it to somebody you would say: "the player character can combine two items into a new one based on his skills in a certain domains and dependent on the build schemata he knows". Now this is a short summary how crafting works in Arcanum but it is NOT an use case.

As I was interested to help out myself, I wrote an use case for crafting in Arcanum:
http://wiki.fifengine.de/index.php?titl ... s#Crafting

As you can see: there are a lot of details listed (what happens if you hover a button, does a sound get played if crafting does not work out, etc.) that you wouldn't mention if you would just summarize it.

That said, I'm not sure I get the idea. Let's take bartering dialogue in Fallout. Would that be an example of a very strict use case, eg. there must be these many buttons for this and that, there must be a header for background art here, text goes there etc.?

The positions of widgets can be often ignored in use cases, however you can't ignore all GUI details as they'll influence the scripting API nevertheless. Let's get back to the crafting example: it would be possible that a text widget could inform the player of the outcome of the crafting process:
* You did successfully combine two items into a new one
* You fail to combine the two items and because of your lack of skill you even break one of them

Now this example seems rather simple but if you think about it, you can extract a bunch of requirements for the future scripting API out of it:
* The scripting API needs to provide access to different widgets and change / update their text description.
* The scripting API needs to be able to modify the inventory of different (N)PCs; it should be possible to add, remove or modify (could be done via metadata or flags) items.
* The scripting API needs to provide ways to check if the player character or his party do have certain items in their inventory.
* The scripting API needs to provide ways to check different player stats.

Perhaps I'm getting it wrong, but is it not possible to give control of commands, functions and operations with GUI elements in a modular fashion, including the core mechanics in a game?

The question is: what kind of commands, functions and GUI elements should there be? While it would be one way to say: let's add everything that we have on our mind to it, that doesn't always work out in a good way.

Especially the question what commands should the API offer to the scripter is a tricky one. You want to offer a consistent API so you need to know a bunch of different needed commands before you design the API. The whole use case approach is a kind of intermediate step to create a good scripting API.

Another way would be to ask: what kind of commands, functions and GUI widgets there should be. While pretty obvious and important aspects will be listed of course, it's pretty likely that you forget a bunch of aspects. Using examples from real RPGs and describing them in a very detailed way helps us to even capture the requirements for the scripting API that are pretty good hidden but important nevertheless.