Game creators' wishlist

From FIFE development wiki
Jump to: navigation, search

This article is outdated and is just stored for archive purposes. Archived.png

This article became outdated and is just stored for archive purposes in this wiki. There are several reasons why an article could become outdated. The development team may have decided to use a different concept or even the author itself felt that the article is not really up-to-date with the current development status of the project anymore.


This article is a wishlist for game creators where they can propose new features or improvements for the development of FIFE. Please don't sign your proposal but word it in a general, non-personalized way. The following guidelines apply to this section:

  • Post a subheading as the title for your suggestion.
  • Begin with a concise explanation of your suggestion.
  • Elaborate on your explanation in more depth, if suitable.
  • Be sure to include enough detail so that it is obvious what you mean.


  • Health and mana potions.
  • When you drink a potion the jar does not disappear but it stays empty.
  • A combiner for items::potions(). With the combiner you can combine for example one empty jar with a red root to make an health potions, etc...

Video Formats

It would be nice if you could include support for the Matroska and MPEG 4 video formats. Ingame movies are a big part of this style of game, and we want to be able to choose a simple format for ingame videos.

Idea for worldmaps

I was wondering how FIFE could simulate the FO worldmap while travelling from one location to another. I tried to work on this issue within LUAgui, but I was confronted with too many limitations. We would have to do a lot of work to enable LUAgui for this task. Therefore I thought about using FIFE itself (or let´s say: the maploader). Here comes what I´ve got so far...

Original FO-worldmap

Why is it called "worldmap"

Thinking about this question, I got the perfect idea (at least it is perfect for me :-D ). In short: the worldmap could be realized as an special type of map - with some additional GUI-Elements (which are done with LUA):

  • One elevation of the map shows the world
  • The citymaps could be visualized by different elevations
  • The position of the pc is visualized with an own gfx; when you click the map, it behaves like a normal map object (moving with animations etc.)
  • Including footprint-like gfx, you also could visualize the travalling progress
  • If you arrive a location, the map will be loaded by using triggers ( if_arrive_triggername() or someting like that)

What do we need?

  • FIFE should have an option to render maps from topdown-view. IMO the best thing would be, when you place an special attribute in the map itself (like view="topdown")
  • FIFE should have bigger tilesizes. (cutting a huge map - e.g. of Germany - into several 80x36 pieces isn´t funny)
  • Scrollblockers for cosmetic reasons (e.g. to let the player think he isn´t on a map but within a scrollable GUI-area)
  • Triggers for mapevents (should come with the normal mapcode I guess)



  • The map of Germany is the main elevation
  • All other elevations contain the citymaps

Additional thoughts

  • Within the scripts, you know the progress of the player - this can be used to activate locations (and their triggers)
  • Discovering new locations when you travel near them, could also be done with special triggers
  • Having the ability to place objects on the map, modders have the abiltiy to use nicer gfx for the locations. E. g. unique buildings etc. (Just imagine Civ 2 or comparable games. IMO that looks nicer than the well known green circle from the Fallout-worldmap)

Colour (graphics) overlay

A decently large 2d isometric RPG usually has a lot of various NPC/critters/characters (refered to as critters in the rest of this article) as well as many map objects. To avoid all of them looking the same or repeating too often, you need a lot of different sprites. The problem with having a lot of sprites is that artists have a lot of work on their hands, as well as an increase of the game size in terms of disk space. A solution to this, regarding at least critters, is a modular aproach that regards critters not as whole, individual sprites but as entities made of several different sprites. The idea is not new, since it was already used in other isometric RPGs, Baldur's gate II and Siege of Avalon to name just two and as I know, such system is already planned for FIFE. This aproach offers a lot of flexibility, but there is a way to expand this even further by using colour overlays.

What is a colour Overlay

A colour overlay is a separate image file that lies on top of the base sprite and provides additional colour information about it. Each individual sprite has its own colour overlay for each frame of animation. Each overlay could in theory contain as many channels as there are colours, but I would dare say that in practice it will be highly unlikely you will need more than 4 channels per overlay. The standard four colours and their corresponding channels I propose are:

  • red - primary colour channel
  • green - secondary colour channel
  • blue - terciary colour channel
  • black - neutral channel, no colour change

In Fallout it was possible to re-colour critters (and other objects?), but there was no way to re-colour only certain parts of the sprite. By using overlays, you get a lot more control over colouring the base sprite.

The 1st image is the base sprite, the 2nd one is the colour overlay and the 3rd one shows a few of the many possible colour combinations. Black means no colour change so those parts are left grey, or whatever colour these parts are on the base sprite. By using only two image files you get toilets galore, for no additional work or increased file size.
By using multiple overlays per base sprite you can quickly get various results with a single base sprite. Red and green channels in the top-right result have the same colour applied.

Other characteristics of a colour overlay

  • it should be completely optional, so the game developers choose whether it benefits their needs or not
  • areas of the base sprite that are influenced by the overlay should be in greyscale, everything else can be of any colour
  • option to change colour of the primary, secondary and terciary colour channel while the game is running. This would be done by the player using either a set of given colours or using a colour picker to choose any possible colour. It should be possible to change colours for all parts of the critter at once (shield, body, cape, etc.)
  • option to lock specified colour channels, so they cannot be edited by the player while the game is running
  • one base sprite should have one or more different overlays to choose from, but only one overlay should be in use at any given time. It should also be possible to change what overlay is in use while the game is running. This would allow the players to choose from different colour distributions over the sprite. For example, the player could pick what pattern/insignia he wants to have on his shield or armour.
  • it should be possible to change different overlays for multiple parts of the critter at once. For example if the player wanted to change his insignia from cross to chess pattern, all of the critter parts would change from cross to chess pattern, this includes, capes, shields, armour etc.

Benefits of colour overlays

  • Reduced number of needed base sprites
  • increased flexibility and customization
  • Since a colour overlay has a limited amount of different colours (usually only 4), it doesn't take much disk space, especially when the image is compressed
  • they are easy to make, the artist must simply apply red, blue, green and black shadeless materials to apropriate parts of the 3d model, turn of antialiasing and re-render the sprite


  • An overlay has no antialiasing so borders between different colours are rather sharp. However, if the sprites are not too big, this problem is not so obvious

Dialogue ideas - wip notes

Dialogue with more than one NPC

Usually there is only a dialogue between the PC and NPC, with occasional third NPC adding a comment or two. I propose an idea, where it is possible to be in a dialogue with more than one NPC, so the available replies can be addressed to either of the NPCs and also vary depending on the addressee. The player would have to think who to reply to, to get the desired result. This could also be combined with quick response (see below) to create interesting dialogue situations.

Replies with emoticons/images

There should be an option to mark replies with certain labels

  • angry
  • kind
  • agree
  • disagree
  • initiate trade
  • end conversation
  • reply with timer (see next section)

The marked replies would display a small emoticon (or any image defined by the developer) besides the text. This would allow the player to glance over possible replies and quickly get their meaning. This would be especially useful if the player only wanted to trade or end a conversation without trying to decypher the meaning of the reply. However, game developers should use this with care, as it could simplify the conversation and take away from player experience. This was a feature in an RPG called Lionheart.

Reply timer/quick response

Usually when the player is in dialogue mode with an NPC, he has no time limit when deciding what to answer to the NPC, meaning the player can read and think about the possible replies. I believe it would be an interesting twist if certain replies could have a timer. After the time would run out, the reply would no longer be available. These replies would be an opportunity for the player to have a rather large effect on the whole conversation. The trick is, they would not be always positive so the player would have to think fast whether to choose the reply or not.

Positive fast replies could unlock quests, give better dialogue replies in the rest of the conversation, or offer shortcuts towards achieving a certain goal. Negative fast replies would do the opposite - lock quests, give worse dialogue replies, and give the player a longer path to achieve a certain goal.

The timer could either be visible, so they player would know how much time he has left, or even better, the reply could only be marked it has a timer, but with no indication of how much time is left. This would make the player even more uncertain and quick to act. The amount of time would be set by the game developer, but should be modified by the stats of the player character.

Last note

All of these three ideas could be affected by the player charisma stat so it would finally become useful :)