Legendary Tales - Refresh

[Throndir]

Do you mind if I list down the issues I had with LT? You can decide if it's something you'll change or not in yours.

[Grimston]

Yeah, that would be excellent. Would love feedback to push for changes and features.

[Throndir]

Hasabushi is making his list, and I'm still thinking of ideas.

I'll be reiterating through previous suggestions. Here's in my opinion what I wish the original LT had/made easier to do.

Highest Importance

• Multiplayer support.
  
• Easier way of connecting map locations together. The original LT, you had to remember what Location ID something is, then connect them through a dropdown.
  

Medium Importance

• Allow more customizability for the game dev including the following:
  
• Able to remove, rename, and add statistics. Eg: if someone didn't want to use "Mana", but "Magic Points", or "Rage", "Energy", "Action Points". Or renaming Mindpower to Intelligence, Faith to Wisdom, etc. Or adding new statistics: Physical Perception, Physical Accuracy, Mental Perception, Mental Accuracy, etc.
  
• Expose how statistics are used. Eg, "Faith" isn't hard-coded to increase "Priest Spells Defense". Or "Endurance" doesn't neccessarily mean more HP.
  
• Able to decide which statistic is shown as a bar on a character. If a new class with three types of "renewable statistics": Mana, Rage, and Action Points. Perhaps you want to visually see how much Mana and Rage points there are left, but not Action Points.
  
• Able to remove, rename, and add damage types. Original LT was hard-coded for had Poison, Electric, Fire, and Acid. What if someone wanted "Light damage" or "Darkness damage".
  
• Able to remove, rename, and add defense types. (Example in the next bullet point).
  
• For each damage type, a list of "defenses types". Original LT uses the opposite of the damage type. Eg Missile Defense vs Missile Damage. Melee Defense. Fire Defense. etc. What if a gamedev wanted to boil down all types of elemental damage to a single defense stat "Elemental Defense".
  
• Able to remove, rename, and add spell types. Original LT is hard coded for Wizard Spells and Priest Spels. eg: able to add Nature Spells, be able to allow Schools of Magic such as Conjuration, Necromancy, Enchantments, etc. Or anything the gamedev can think of.
  
• Able to remove, rename, and add weapon types.
  

Lowest Importance

• Skinnable UI. Either set by user, or set by game dev.
  
• Different image sizes. The original LT, images were at a set pixel, 209 x 209 was it? It felt very arbitrary without any way to configure.
  

[Hasabushi]

Highest Importance

1. Multiplayer (of course) - both single player module/packages download and multiplayer chat and user interface.
2. Map Designer - this needs to be a custom drag and drop interface, with a seperate floating window for location design and layout. I'll explain more on this if you need me too. The more simplified the map is the quicker a draft of a world can be created.(I remember getting frustrated with the engine on this level with my Arena game).
3. Easy to navigate interface that a newbie can pickup really quick, allowing a growing community hopefully hosted on FWC :D

Medium Importance

1. Custom Stats - basically the same thing Throndir wrote about, I hated the fact of not being able to change
stats or create new ones. This means all stats not just the vitals.
2. New Skills - NO MORE HARD CODED SKILLS or SPELLS! I beleive this really hurt the LT community, especially with everyone now wanting to be able to customize.
3. Support of animated 2d Sprites: animated 2d gifs (sprites) for portraits or animated maps.
4. Custom Classes & Races - with a wizard interface for creating classes and races.

Lowest Importance

1. Modding - this is something that should be worked toward for the future growth of this engine, the more that can be modded the further this will grow.
2. Mulitplayer Server Skinning - Basically a player could connect to a server and choose a module or campaign to play, in the process his GUI is skinned to whatever the module creater has chosen.
3. Ageing - this is a function I currently have in my Legend of Hero's game engine. Basically the character ages over playtime, and the option is given to marry and reproduce an heir who continues the quest. In effect I've noticed that this causes the player to care about their character and his/her future.

[Throndir]

Yeah one big thing about LT that became a limitation the more I worked with it was a lot of the hard-coded things.

Being able to configure and control how the mechanics of the game work would let the engine be great if one wanted to make a system similar to d20 or any other system.

[Grimston]

So really you would have liked is the engine more dynamic.

I will change the layout to reflect this, and make it dynamic.


Currently in the background the weapon types are semi dynamic, I will not be difficult to make it fully dynamic.

Wizards, I will create wizards for almost everything possible.

I will also attempt to make it drag and drop.

[Throndir]

I can imagine you can store definitions for everything. Currently you have Skills, Races and Classes, it could be extended to have subfolders of weapon definitions, or any of the other ones I listed like Magic Type definitions, damage and defense definitions, and statistic definitions. Items and weapons could possibly fit too, lol.

Ultimately you're the one developing this, so choose which features are the best to add. If you decide to leave the code open-source, someone else in the future could go in and add in the features they wanted themselves.

[Hasabushi]

A possible approach may be to have custom items written to a XML or a CVS file, anything that can be easily opened and read by the modder. It's similar to the approach I'm using with my current project, which when the site is up I'll have a blog on it as well as this :)

[Grimston]

This is true, at the moment I'm just using .net's XML serialisation. I have been thinking of making a module system for the editor. This way instead of a single massive project, If I expose a API to use, then create modules that will then be loaded to produce the bulk of the editor.

Doing it this way would probably mean I will need to rewrite a lot of the code, but the added flexibility would be well worth it. It would also lead to community driven module plugins for it.

Modules would then be able to store data however they choose, be a binary file, TXT, XML, CSV, or even SQLite Database.

Edit:

To expand on how this will actually work, There will be certain events that will make up the game. And plugins can expose the editor to those.

I have started writing the new editor, and I will create a more dynamic set of editor controls in the core plugin.

The plugin system is semi implemented, you can have more then a single plugin per dll in the Plugins Folder.

Plugins can also be created in any CLR compliant language. As long as they reference the Plugin.dll included with the application.

There is also a Set core feature set, that plugins can use to expand on.

I have decided to use MonoGame, this will then allow me to create a basic 2D API, and better skinning systems. While it would be designed to be a Text RPG Game Creator, I hope to make it possible to extend that to 2D games as well... as a start :D

I will also start on the compiled game, and then build the editor API, and Base Plugin at the same time.

I will expand on the plugin system soon.

[Throndir]

This is great news! Willing to support this anyway I can, so if there's anything we can do just let us know.

Looking forward for the next releases of this, and I'll definitely get in touch with past LT members to see if I can bring them back when this is more fully featured.

[Throndir]

Also looking forward for this plugin system of yours. Your engine's going to be a lot more dynamic and because of that, a lot more powerful than the original LT. Opens up a ton of possibilities! :D

[Grimston]

Always good to know there is support  ;)

I have been thinking on what sort of GUI controls I would really need to implement, so far the list includes

• Window - Window control, holds other controls
• Label - Text drawn to the screen
• Button - Click able button
• Meter - Health bars/Energy bars, and such
• Console - Console view, for the games output
• InputBox - Accept input from the user

I also have a base Control, that can be used to create custom controls. The UI Library also supports skins, and has a very basic built in skin, using just plain colors.

I don't really have the time to put effort into creating a skin with images, but it will also be supported, to add more flair to the resulting game. If someone would like to create a skin for this, I will, once I finish it up, supply the basic structure of the skin file.

What other controls should the library implement?

Also, I have a little challenge!

The project has a new name, the abbreviation is: XGCE

Can anyone guess the name?  ;D

[Throndir]

Xtreme Game Creation Engine!

[Hasabushi]

Only things I can think of right off hand is:
The GUI TextArea for descriptive text of the scene
and an AreaInventory perhaps that shows what "mobs" are crurrently in the scene will statics too not just mobiles.
  - Seperate panel with clickable names for more info (hrefs)

Untill I actually see the layout of the GUI can't offer much more :D


Nope, lol.

I just know it's none of my suggestions :D

[Grimston]

EXtendable Game Creation Editor

Due to the time its taking me to create a working GUI system in MonoGame, I will place that side of things on hold, and just use a more simple WinForms approach for now. My original Idea was to port Neoforce Controls, from XNA to MonoGame, but by doing so, I encountered too many uses of key features not yet available in MonoGame. MonoGame is under constant development, So I believe these features will be soon implemented.