Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Colony Ship RPG (The New World) update #16 - tools of the trade (engine update 1)

Goral

Arcane
Patron
The Real Fanboy
Joined
May 4, 2008
Messages
3,571
Location
Poland
http://www.irontowerstudio.com/forum/index.php/topic,7471.0.html

Vault Dweller and Nick said:
Much like a hero is only as good as his weapon (rule #15), a developer is only as good as his tools. So when we switched to Unreal, our main concern was whether or not we'd be able to find our way around the 'blueprints' (Unreal's visual scripting system). We started with Unreal 4.14 and several plug-ins to get the ball rolling and get a quick feel of the engine:

- LE Extended Standard Library (blueprints that add general functionality and improvements)
- Unreal.js (brings V8-powered Javascript into Unreal Engine 4)
- Rama's Victory Plugin (C++ Blueprint Function Library)
- Dialogue Plugin (a node-based editor)

We needed the javascript plug-in to tie scripts to dialogue: doing checks like "aod.str > 7" or executing actions like "dlgAddItem(35,5);", but integrating an entire programming language and running a separate instance of the interpreter engine for such a basic task is overkill (it's like running Google Chrome in the background as a part of the game). Plus, big and complex subsystems tend to cause big and complex problems over time, which we don't need, so we kept experimenting and this is our progress report (technically it's Nick's report, so I'll post his email as is and call it a day):

#1 - The Dialogue Editor

We managed to combine Unreal's blueprint graph (visual scripting) with DialoguePlugin's tree structure into a new asset and made a proper editor:

b_111140.png


b_111142.png


This means that both the dialogue structure (text, parts, answers, links) and dialogue scripts (spawn characters, switch mission, add items, unlock door, etc) are all contained within a single asset and not scattered around the build. Whereas in AoD we could only add something from a pre-defined list of scripts to get a list of commands like "do this, then this, then this, ...", now we can code a complex action with checks, loops and whatever UE blueprints allow and they allow pretty much everything.

We can also call functions from the blueprint libraries, if we need to store and reuse some generic scripts (examples from AoD: scheduleEnding, setMapLighting, etc). We've also managed to plug into Unreal context menus and asset categories, so dialogues (and everything else) are created in a convenient manner:

b_111144.png


It's very easy to use it and there are only two simple rules:
- In order to qualify as a dialogue check and appear in a dropdown list in dialogue nodes' properties, the function must receive 0 parameters and return 1 bool value. That value is basically a result of your check and tells the dialogue system if this NPC text / PC answer should appear;
- In order to qualify as a dialogue event (action, script, call it whatever you like), your function should have 0 input parameters and 0 output. It's just does inside what you want and doesn't take or return anything.

#2 - The Item Editor

In AoD we used ItemGen and CharGen editors which stored lists of items and characters in their own custom binary databases. We liked them and gotten used to them but Unreal offers its own way of storing, editing and searching data, in many ways greatly superior, so we decided to discard our square-wheeled bicycle and do it the way cool kids do. Here is our new item editing interface:

b_111145.png


It does everything our old ItemGen did and then some:

1) One item class now will not contain data fields from other classes, i.e. melee weapon will not have a field "Magazine Capacity", armor will not have "Range" and "Attacks Supported". Now each item class contains only the related data due to the inheritance hierarchy. For example: InvItemInfo (properties for all items, like name, weight, etc) -> InvEquipableItemInfo (adds properties that define 3D visuals) -> InvWeaponInfo (adds properties common for all weapons, like damage type, range, AP cost, attacks) -> InvRangedWeaponInfo (magazine capacity, ammo type, etc);

2) Unreal typed fields: you can enter/select only related data, which is displayed in the most convenient way. Take a look at "Static Mesh" property for a weapon on the image above. It's not a generic text field anymore, where you had to type some string and hope that the mesh/animation named like that is somewhere in our files and the game, with gods' blessing, will hook it up. Now you get a proper menu with a full list of suitable resources to select from, thumbnails, search field, view options and full information about the selected asset:

b_111147.png


3) There can be not only properties, but functionality attached to each specific item in a form of custom blueprint graph. Do you want this item to shoot sparks when reloaded or shine when it's thrown? Do you want this grenade to go boom when it hits or spawn a distortion effect instead? Want to inflict some specific status effect when this club hits, but just this club, not others? Well, no more shit code and special cases checking for "if this is acid do this, else if it's net do this, else if it's napalm ...". All specific functionality is completely self-contained in this item - just place, drag around and connect some blueprint nodes to make magic happen. We also can (and surely will) inherit some functionality from parent classes - like, every item derived from ranged weapon will be able to spawn a muzzle flash, every item of every class will spawn a map object when it's dropped because core class (InvItemInfo) will know how to do it, etc.

We've already set up a core hierarchy of items, but we can improve and expand it at any time, from adding new properties to creating new item classes. Check out Gameplay\Items\BaseTypes\ . In order to create a new melee weapon, right-click InvMeleeWeaponInfo and select "Create Child Blueprint Class". That's it! Give it a name, edit its properties and move to an appropriate folder (Gameplay\Items\Weapon\, for example, but we'll sort out specific folder structure later). You can easily find any item out of hundreds we'll have by typing a couple of characters from its name in the Content Browser's search bar. Also, your new item will now appear in all selection menus, where you need to select an item - like character's weapon slot in Character Editor. Speaking of which...

#3 - The Character Editor

It's similar to the item editor - an easy LEGO constructor for all your character editing needs, including a viewport with a paperdoll that will instantly reflect all the equipment you select, appearance customization (later) and derived stats updating in real time as you change stuff:

b_111149.png


Some notes:

1) Check Gameplay\Characters\Database\BaseTypes\ - that's where we will store the "creature" types. Each creature will have unique equipment slots, blueprint code that runs animations, a set of meshes and rules that show/hide them and other blueprinted functionality a creature has - what damage it accepts, what status effects it reacts to and so on. For example, a plant in the wasteland is a creature that doesn't has any clothing slots, one body mesh and one (possibly invisible) weapon item. A robot is a creature that has armor, weapon slots and inventory, but not hats or gas masks, etc. So each creature type has its own properties, no more spaghetti code like "if the creature is human and impaled, show the spear, but not if it's a demon, in which case show 200 body pieces if it's dead and broken, but if it's a construct, show only the mesh named "body"; but if it's you're plant, show trunk_01 and 02, ...".

2) To create a new human character, right-click HumanCharacterInfo, select "Create Child Blueprint Class", name it and move one folder up, from BaseTypes. Now you can select your newly created character in CharMarker's dropdown. If you ever rename a character, Unreal will automatically go through all its references in all CharMarkers and update the name everywhere, so there is no chance to mess up dbID.

So in short, the core system is already there - we can start adding dialogues, items and characters right now, which puts us right on schedule (so far).
 
Self-Ejected

Lurker King

Self-Ejected
The Real Fanboy
Joined
Jan 21, 2015
Messages
1,865,419
So it seems that the fear mongering about Unreal in that other thread was unjustified after all. Nice!
 

Goral

Arcane
Patron
The Real Fanboy
Joined
May 4, 2008
Messages
3,571
Location
Poland
I think it's still too early to say, they've just started. But if 1 person could do something like Bloodlust Shadowhunter then I don't see why they wouldn't succeed.

Nick said:
So in short, the core system is already there - we can start adding dialogues, items and characters right now, which puts us right on schedule (so far).
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom