Scarlet Thread Studios' Blog

Absolutely amazingly clever.

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?

Hehe thanks guys. The reason it's called HAARP is... well a secret XD for now. Maybe I'll let y'all know when its finished.

..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

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?

very well thought out approach...

 

--Mike

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.

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.

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!

@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

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?

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.