Jump to content
  • entries
    13
  • comments
    80
  • views
    34,231

H.A.A.R.P An Extremists Approach To Data Driven Design


Road Kill Kenny

3,036 views

 Share

In my short 1 year of programming I have gone to great extents to learn not only how to code but also the techniques and methods behind game architecture that make things work and keep the integrity, re usability and productivity of my code to a maximum.

 

Out of all the techniques I have come across there are two that really have taken the cake. These two techniques are (excluding OOP, thats a given):

  • Finite State Machines
  • Data Driven Design

Data Driven Design

 

For those of you who don'tk now or are not sure of what Data Driven Design is, here is a brief explanation.

 

Data Driven Design is when you don't hard code any constants into the game but rather draw out all the "data" required for your game from external files such as .txt files, .xml files or databases. Pretty much any data you can think of can be stored in a database externally from the code such as the following examples

  • Material Paths
  • Model Paths
  • Camera Follow Distance
  • Prop Attachment Offsets
  • UI element's, textures, scale, position, parent, target etc.
  • Weapon model,
  • Weapon Power
  • Weapon Fire rate
  • Game Settings & Key Bindings
  • etc. etc. etc.

Now anyone who knows me or has seen my posts and status updates would notice that I'm obsessed with Data Driven Design even to a point where it may even get annoying. However, I talk about it a lot for good reason. It is because the benefits of it are tremendous and it increases long term productivity and game design freedom to a new high not possible with simply coding constants.

 

With data driven design you can store all your data in an easy to find place in a database and access it and edit it easily without having to touch your code. This means no more wading through thousands of lines of code but simply going through a logically setup database to find the data. Say you don't like the run speed of your character. You have to close the game find the speed variable and change the value. This could take a while to find in your code and you have to then recompile again. Then you load up your game and if its not good you have to repeat the process again. However with DDD you simply have to change the easy to find value in the database and restart the game.

 

Another big pro is that you can easily make an every game with DDD. Why completely re-write the code for another RTS or FPS game if you have already coded one. With DDD you can simply change the models and values in the database and everything can look new without even recompiling. For an FPS game you can simply code only one gun, but have different stats and models in the database and already you can create pretty much any gun you'd ever want in an FPS.

 

Well I've done a lot of rambling just then so here is a video of something I'm making called H.A.A.R.P. With HAARP I have combined the power of Finite State Machines with Data Driven Design and taken the whole thing one step further to come up with a solution that stops me from re-coding things, reducing my workload and increasing my productivity in the long term.

 

 

 

I don't mind the time it will take to create this H.A.A.R.P implementation because as far as I've noticed so far the art assets get out of data 100x faster than code and this will allow me to concentrate more on making the game and less on coding once I've finished it so I will be able to get the art out quicker before it gets outdated.

  • Upvote 3
 Share

12 Comments


Recommended Comments

I say something in Unity for like $100 bucks a pop but I think it's really smart. Even more so as it's in Leadwerks.

 

Why is it called HAARP out of curiosity?

Link to comment

..yes, this is very nice and this is way to go..on PS3, whole structure is stored inside database (if you using Phyre by default) so you accessing it trough very simple calls...i sort of, copied Phyre approach in editors artists using, so basically they dont do a thing but as a result just updating 'database' entry for certain objects they are allowed to access on our internal mainframe..very handy..good work, I like it

Link to comment

Very nice Ken. This is how I was doing the GUI in a project I was doing but extending it to most everything is a great ideas! If you had to give a negative to the approach can you even think of one?

Link to comment

The only negative is it takes a lot of work to get setup especially the way I'm doing it. It was one thing to set up the databases and your standard ddd setup but to make even the UI editable in game makes things much more complex. Especially because I wanted to make it have no bearing on the final code once editor is turned off. What I mean is, I wanted the editor to have no performance effect and be isolated from everything else which was a challenge.

 

However, I'm counting on the fact that this time spent is going to be payed back once its finished because productivity will be much more and it would be highly reusable.

 

A reasonable trade off I think. I'll call it an investment in my time for a more permanent solution.

 

You might be interested to know that even the gui elements for the Editor are data driven. However, instead of dynamically creating them they had to be created individually using hard code but all their data is straight from the database as well.

Link to comment

Any specific reason you aren't dynamically creating GUI elements this way too? Just didn't get around to it? I am doing that with one of my games and it's working pretty nice.

 

I'm guessing it's because to define functionality you still have to associate the gui element to a function. In Lua this was pretty nice because I was able to give the function name for a click event for example, as a property and it would dynamically link to that. In C++ I had to use a map of gui elements where the key is the name and then in code find those names and map them to clicked event functions.

Link to comment

Definitely not crazy Ken, this is very nice indeed. I too have kind of followed a similar path in my development creating my own editor in which my game engine runs in real time and I can switch to edit mode at any point and edit in real time.

 

DDD and real time editing has some huge advantages and is a great way to work intuitively especially when designing and testing game AI. Like you are suggesting with your engine; my engine currently supports FPS as well as RPG/Adventure game functionality (the hard coded side) and is pretty much data driven too. There is still some way to go as I guess there is in yours but essentially it sounds like a similar approach.

 

I really like your editor interface and tools, very nicely thought out and implemented. I look forward to seeing how you progress this, you are demonstrating some great skills and concepts here!

Link to comment

@Rick - The only reason I didn't make it dynamic for the editor is because there is no reason to. It's an unnecessary complexity at least in my mind and unlike the game UI, which you are likely to change, the editor can pretty much stay the same. I could have done it but I don't really see any point in doing it. Also I don't want the editor to be edited in game..... that would be a bit counter productive so I don't want editor buttons and game buttons to be treated the same at all.

 

As for your guess it is not correct. I don't have to assign elements to a function at all. They are capable of being completely dynamic and everything I could want to do with them is mapped out so It can totally be data driven.

 

@pixel cheers

Link to comment

Oh you meant your editor GUI not your the game GUI? I thought you meant the game GUI was hardcoded which is why I was confused. Makes sense the editor GUI isn't.

 

On your other topic, if I want to run code in a button click how are you doing that without having some kind of function executing when the button is pressed to do whatever needs to be done? Again, this is for the game GUI.

 

EDIT: nvm I see you connect them to states. Sorry saw this at work so couldn't see the video at that time. Just watched it and makes sense now that you connect them to states. Will that work for every aspect? Let's say you have ability buttons in your game that will cast a spell which will tell your player to animate and do the ability. Do you foresee taking the same approach?

Link to comment

Yeh basically I would do it the same. Just like the states are created dynamically from the database, the abilities in say and RPG game would be dynamically created from the database as well and stored in a vector. I would probably make a different type of button than a Gui element button for this otherwise I risk overloading the functionality of a button. However, just like the database specifies what state activates when you click a button, an ability button will have an ability ID target set. So when you click it that ability button would have a pointer to the ability manager and it would attempt to activate whatever its target ability is from within itself.

 

So basically I just have to itterate through every button and update it and based on the data installed into the buttons they will automatically manage themselves.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...