syscrusher

Hello, all

I am looking seriously at buying ORK, but what I want to do is select out only the pieces of ORK that I need and ignore the rest. Some examples of features "in" and "out" of my project:

Use from ORK:

• Currency definitions and conversions
  
• Data classes for character attributes, effects, statistics
  
• Data management for leveled loot lists, experience point level-up calculations, etc.
  
• Visual elements of ORK UI and connection to ORK data entities
  
• Almost all of ORK quest-related features
  

Not from ORK:

• Scene load and scene transition management
  
• Player controls and player object life cycle
  
• Camera management
  
• Player avatar
  
• Pathfinding and navigation
  
• AI behaviors (use ORK for quest-level "goal" definitions but not low-level wander, follow, patrol and similar behaviors)
  

Undecided, but probably from ORK:

• Inventory
  
• Faction relationship tracking (but not the effect of factions on gameplay, just the internal data)
  
• Music management
  

Basically, what I want to do is to use ORK almost fully for pure game mechanics (which I define as the "rules" that would be published in a book in a tabletop RPG), but not use ORK at all for the realtime aspects of how game state is controlled and presented on screen.

My questions are two:

1. From the file list in the Asset Store, I see a ZIP file that says it contains the game-mode source code. Simply asked, is *all* of the non-editor code present in that bundle, or a subset?
   
2. For those who have used this system extensively, how closely coupled are the game rules and data handling sections with the user interaction parts for graphics, sound, and camera?
   

I fully realize that this plan involves a lot of C# scripting. I have 30 years of programming experience, so that not only doesn't scare me, it rather excites me. :-) The scary part for me is the artistic part, and ORK doesn't do that anyway, so I'm planning to buy other assets for that.

I'm looking for comments on whether experienced ORK users think what I propose is feasible. I've looked at the API docs and the tutorials, and I am convinced that ORK is a superbly designed system, but it is also clear that its focus is toward a turnkey environment for non-programmers (or those wishing to minimize coding). My question isn't whether ORK is good or bad, but whether it is a good fit for my requirements in particular.

Thanks for any input and comments.

gamingislove

Well, ORK is pretty flexible - if you don't need/want a feature, don't use it and that's pretty much all there is to it :)

To answer your questions:

1) The gameplay related code is included, i.e. all stuff related to the actual game data, game systems, UI, etc.
Only the editor and some core functionality (e.g. the data serialization) is closed source. The editor automatically adepts to changes in the settings.

2) Those things are completely unrelated. You can use the whole game system (stats, battles, etc.) without interfering with graphics/controls/sound at all. Naturally, there are a lot of settings to do so if you want, but they're optional. Don't need it? Don't use it :)

ORK is, in it's core, a hardcore RPG framework with additional/optional tools to do the presentation (animating battles, cinematics, dialogues, UI, etc.), world building and everything else you'll need when creating an RPG. It doesn't limit you to use a certain style, graphics, controls, etc.

syscrusher

@gamingislove

Thanks for the quick reply. :-)

I wasn't concerned about ORK's flexibility -- that's obvious from the docs and tutorials. But without seeing the source, it's hard to know how closely coupled the various packages within ORK are. For example, you could build the inventory system so it assumes the presence of a character controller of a specific type.

The class inheritance tree tells a lot of this info, and yours seems pretty cleanly partitioned between functional subsystems.

It's too bad there's no good automated way (of which I'm aware, at least) of automatically generating a dependency tree for C# APIs.

syscrusher

Specific question with respect to your serialization (one of the closed source parts): Is it feasible for me to override the SaveGame() and LoadGame() methods on your classes to manage those with my own code? I need to be able to merge ORK game state with that of my other components. I know C# doesn't mind if I do this; my question is, does that break some fundamental architectural assumption of ORK?

gamingislove

You can use the custom save data system to add your own stuff to save games.
While the serialization is in the closed source, the save game implementations are part of the gameplay code and can be changed.

syscrusher

That interface would let me add variables into the basic ORK save, which I think could be useful in prototyping, but ultimately I think I'll need to swap out the save game implementation when I get past the prototype. That's okay; I'll just build it into the project plan.

Is the serialization used anywhere other than game save/load?

syscrusher

@gamingislove, I wanted to let you know I've just purchased ORK from the Asset Store. Thanks again for your responses today that helped me evaluate. It'll be a couple of days before I get to dive into ORK, but I have some vacation time from work coming up later this month and will be doing a lot of coding then. :-)

gamingislove

The serialization is used for data storing and save games - it converts the data into an XML formatted string.
Thanks for the purchase :)

twinj

Helpful post. Thanks.