MMORPG style Inventory - Stock Torque3D 3.10.1

Scripts and code that enhance the gameplay functionality of the engine.
  • 1
  • 2
15 posts Page 1 of 2
Zweshi
Posts: 19
Joined: Sat Sep 05, 2015 10:30 am
 
by Zweshi » Fri Nov 09, 2018 2:36 am
Hello everyone,
Isn't it high time that Torque3D had a easy to use, easy to maintain, and easy to expand upon inventory system? I think so too! And in that spirit here is a MMORPG style server to client inventory resource written in TorqueScript for stock Torque3D 3.10.1... probably works on any version of Torque but 3.10.1 is where it's been tested.

Video showing off inventory functionality:


Current Version: 1.0.0a
Download: https://www.dropbox.com/s/p4x4e8qvwf9e4 ... y.zip?dl=0
Installation: Instructions are found in the downloaded folder's base directory
License: Code: MIT | Art/Sound files: CC0


General Notes:
  • Networked with a "never trust the client" mindset
  • Standardized images/bitmap arrays
  • Standardized data variables for all the things
  • Standardized "helper" functionality
  • Using a flat database system
  • Using object namespaces to reduce redundancies
  • Written in just TorqueScript
  • No .gui files, the gui elements are built to a targeted gui(standard is set to PlayGui)
  • Data driven gui approach with full customization
  • Plenty of example objects

System Features:
  • Base inventory
  • Inventory Menu
  • Currency panel
  • Notify panel
  • Examine panel
  • Sound suite
  • Select object behavior

Network Optimizations:
  • Full inventory data is only sent when player opens their inventory for the first time
  • Split/drop/Move/pickup functions only send data for the affected slots
  • client verifies data before a request is made reducing redundant server calls
  • server is only called if/when actions are taken not for redundant tasks such as open/close states

Inventory Item Types:
  • Currency
  • Stackable items
  • Non-stackable items
  • Equipable items
  • Food items

Inventory Item Functions(Menu System):
  • Split stack
  • Pickup item
  • Move item
  • Examine item
  • Drop item
A Word On Adding Content:
One thing I've learnt over the years is that efficiency on the data layer is useless if it means the content layer suffers(learnt that the hard way), so with that in mind content additions are handles exclusively within a scope that a artist without code/scripting skills can master. A item addition requires a shape(.dae) used for world placement, a 2D inventory image(.png) of the item, and a datablock akin to a simple non-interactive spreadsheet.
That is it, you do not need to even touch the codebase of the inventory system to fully interact with the content layer.

A Word On System Customization:
One of my biggest pet peeves is when developers build cool systems as external resources(for any engine or data system) that are very specifically engineered to do one thing very well but if you want to modify them at all you might as well re-engineer the worlds power grid first as that would probably be simpler.
With that in mind i wrote this resource to be adaptable through the dankest of data driven approaches, for example: Want the inventory on the left side instead? No problem just change $InvBase_PnlPos and your done, more inventory slots and rows? Just change $Inv_Rows, $Inv_NumBtns and $Inv_InventoryMaxSize and your good to go.
It's easy to change things and it should be easy.

A Word On Data Management:
You will notice that this resource uses a flat database as opposed to a more sophisticated separate database system for data handling. As i started this project i contemplated writing a database system to go with it and get some inter-server goodness going right of the bat for that sweet sweet efficiency. But limited time along with the fact that i was not gonna use the system myself made me lean towards a simpler solution, after all if you need a sophisticated database for your game then you probably already have a preference for a existing system.

A Word On Client Login:
This inventory system does not sport a client login system, instead it simply uses the client player name to connect the player to the server side inventory, this is what we in the industry call a complete lack of security bordering the absurd. This is by design though as i wanted to avoid writing a login system as at that point this resource would land in the security sphere which i'm not really comfortable with for a public resource like this. So keep this in mind for your multiplayer projects, you need to connect your login system to the inventory where appropriate.

Feedback:
If you decide to use this system for your project(s) and find some gaping flaw that i, in my infinite wisdom of course, overlooked completely i would very much appreciate if you would report back so i can break out the ol' shovel and get back in the trench to fix it.

Lastly if you have any questions feel free to reach out to me either in this thread, on discord, or twitter and i will do my best to help you out.
Twitter: Zweshi
Discord: Zweshi#0840

All the best and happy inventorying!
- Jonas
Last edited by Zweshi on Sun Dec 09, 2018 8:27 am, edited 2 times in total.
Zweshi
Posts: 19
Joined: Sat Sep 05, 2015 10:30 am
 
by Zweshi » Fri Nov 09, 2018 2:37 am
< Reserved >
TRON
Site Admin
Posts: 37
Joined: Tue Feb 03, 2015 8:55 pm
by TRON » Fri Nov 09, 2018 3:19 am
Very well done. Thanks for sharing and nice demo video to go along with it.
Duion
Posts: 1131
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Fri Nov 09, 2018 12:24 pm
Thats really nice, since it is exactly what I needed. Some time ago I also started making an inventory system after a tutorial, but I gave up somewhere in the process.

Now to the criticism:

The install is a bit annoying having to manually edit files and then the binds do not work, since the keys are already used, so they have to be fixed manually as well. The easiest solution for people who want to try it out, would be just to distribute a pre modified version, that you just have to drag and drop or even a full install, that you can just launch, since a full Torque install is also the same size download as the inventory system.

The other point is the size, I wondered what uses 130 MB in the package and then noticed it has art, plus source files, which is nice, but 1024x1024 texture for such tiny objects is a "bit" over the top, 128x128 would fit as well without noticeable visual difference. I know those are just example items probably, but then you made the things overly complicated for yourself, you could just have used plain materials, or no materials at all and just vertex paint the models, would save greatly on resources. Polycount is also far too high for some objects.
I did my art like that in the past as well, everything with texture, proper node setup in blender, but now I know, that you can get away in many cases with just making a simple low poly model, giving it a color and export to .dae file and distribute nothing else with it and it will work just fine with hardly a noticeable difference in appearance. That way you could make that 130MB download into 1MB download or so while greatly increasing performance ingame and saving time on your workflow.

Yes this has nothing to do with the inventory system, it is just a workflow and performance optimization, for users and yourself, I like to be perfectionistic.

Another question, do you plan on making items use multiple grid fields instead of just one each? When I tried to make an inventory system, I wanted larger items to take up more spaces, like it is done in many RPG games, but I found it to be very hard to build so I gave up on it.
XIXWYRMEXIX
Posts: 12
Joined: Sat Mar 07, 2015 3:13 pm
by XIXWYRMEXIX » Fri Nov 09, 2018 3:15 pm
Thank you for providing this resource, especially considering you did not even make it for yourself. I will try it out on my current project. I was looking/thinking about an inventory system in the future but since it is here I will just use this! Thanks a lot! Will try to provide feedback after I use it.
Zweshi
Posts: 19
Joined: Sat Sep 05, 2015 10:30 am
 
by Zweshi » Fri Nov 09, 2018 4:32 pm
@ TRON Thank you, happy to share it!

@ Duion Thank you, Happy to hear you were on the hunt for something like this!
The install is a bit annoying having to manually edit files and then the binds do not work, since the keys are already used, so they have to be fixed manually as well. The easiest solution for people who want to try it out, would be just to distribute a pre modified version, that you just have to drag and drop or even a full install, that you can just launch, since a full Torque install is also the same size download as the inventory system.
Install is a tricky beast to get situated, the reasoning behind having to add exec lines is to not overwrite the standard init files as that becomes a liability for compatibility down the line if they are ever changed either with a new Torque release or by the end user. The keys i hear you on, i decided to use the keys i find to be the most logical for the operations rather then what was unbound by default, i do think i made the right call but i can see it being argued both ways.
The other point is the size, I wondered what uses 130 MB in the package and then noticed it has art, plus source files, which is nice, but 1024x1024 texture for such tiny objects is a "bit" over the top, 128x128 would fit as well without noticeable visual difference. I know those are just example items probably, but then you made the things overly complicated for yourself, you could just have used plain materials, or no materials at all and just vertex paint the models, would save greatly on resources. Polycount is also far too high for some objects.
I did my art like that in the past as well, everything with texture, proper node setup in blender, but now I know, that you can get away in many cases with just making a simple low poly model, giving it a color and export to .dae file and distribute nothing else with it and it will work just fine with hardly a noticeable difference in appearance. That way you could make that 130MB download into 1MB download or so while greatly increasing performance ingame and saving time on your workflow.

Yes this has nothing to do with the inventory system, it is just a workflow and performance optimization, for users and yourself, I like to be perfectionistic.
I definitely understand your point of view but i do think there is value to over engineer 3D assets in the context of a resource. A bit of extra quality provides a more impressive visual to a window shopper and clarity in node setups/rendering setups/source files provides example opportunities for the end user to emulate. Since at the end of the day the items are of a example nature it isn't all too important that they would function well and be space efficient in a full production environment.
Another question, do you plan on making items use multiple grid fields instead of just one each? When I tried to make an inventory system, I wanted larger items to take up more spaces, like it is done in many RPG games, but I found it to be very hard to build so I gave up on it.
I have gone back and forth a lot over the years on which style i like the most out of these two types of inventory and they both have significant merits to them, but for this resource my intention is to stick with the style of "one item, one slot".

Thank you for the feedback Duion, always happy to hear it!

@ XIXWYRMEXIX You're very welcome, Happy to hear i could save you some inventory dev time! :D
LoLJester
Posts: 71
Joined: Thu Aug 13, 2015 5:58 pm
 
by LoLJester » Fri Nov 09, 2018 5:41 pm
Great resource and video. Thanks for sharing.
Duion
Posts: 1131
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Fri Nov 09, 2018 6:47 pm
I definitely understand your point of view but i do think there is value to over engineer 3D assets in the context of a resource. A bit of extra quality provides a more impressive visual to a window shopper and clarity in node setups/rendering setups/source files provides example opportunities for the end user to emulate. Since at the end of the day the items are of a example nature it isn't all too important that they would function well and be space efficient in a full production environment.
Yes, it is nice to have them higher quality, but doing models and textures like that shows that the art engineer does not know what he is doing, you could get away with 10% of the resources used and still achieve similar or higher quality, since for example no normal maps or specular maps were used, not to talk about new PBR rendering methods. You cannot have such a small items have thousands of polygons, no LOD levels and a huge 1024x1024 texture, of which most is empty space, since in the final game there max exist hundreds or thousands of those items on screen at once plus the game world, plus player models etc which will destroy performance.
It may not be relevant for an example, but this is not something an end user should emulate or use in a final product.
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Dec 06, 2018 4:23 pm
@
User avatar
Zweshi
Most excellent work, sir!

If you were interested in turning this into a module for future use in the new BaseGame template, I'd be willing to help with that and I think that would go a long way to dealing with things like Duion's complaint about installation complexity.
Bloodknight
Posts: 148
Joined: Tue Feb 03, 2015 8:58 pm
by Bloodknight » Fri Dec 07, 2018 11:30 pm
I'm going to be awkward and ask for a licence, I'm assuming at least MIT for parity based on your comments about taking and breaking.

I was looking at an inventory system very much like this for converting the AFX demo into a more rounded RPG demo (which I will pester jeff about later on regarding making it fit into the new modular basegame) The server sided determination is the icing on the cake which I'm pretty sure was going to provide me with headaches, but you've done that :D

As for asset detailing, generally I find its easier to convert better quality/higher fidelity assets to something else than the other way round, much art texturing comes with far bigger textures than needed which allows the designer the freedom to adjust somewhat.
  • 1
  • 2
15 posts Page 1 of 2

Who is online

Users browsing this forum: No registered users and 1 guest