Rick

Nevermind, I got it. Needed the % difference between the default & actual screen resolutions and multiply that by each widget's x, y, w, h. All good now!

How are you offsetting the clicking regions? I tried finding the difference between the base res to the actual res and then subtracting those values for each widget but doesn't seem to work. The mouse over and clicking isn't registering correctly for any resolution but the base resolution picked.

Thanks, this combined with using %'s for size and position gives me exactly what I'm looking for with scaling fonts! I'll have to find a resolution for each aspect ratio to use as the base.

So you do something like: TEntity ui = CreateBuffer(800, 600, BUFFER_COLOR); // before drawing our widget textures to our UI buffer, clear and set ClearBuffer(); SetBuffer(ui); // draw to ui bufferhere // set back SetBuffer(BackBuffer()); // draw our ui buffer to screen DrawImage(GetColorBuffer(ui), 0, 600, 800, -600); // this flips the image also How do you handle transparency? I would think you want the buffer itself to be transparent besides the widgets you draw on it.

So you draw all your widgets on a buffer, and then scale this buffer (instead of each widget) to fit the resolution of the screen? If so, how is that working out? Does it look good? Sounds like a good approach although I have to imagine would still need unique widget positons per aspect ratio to avoid stretching right, which is fine it's a problem no matter what approach is used I think. Besides doing 1 scaling of the buffer vs each widget, does this bring any other benefits to table from scaling each widget? Could you give an example of how you are doing this? It's been ages since I've used buffers. Since the framework was introduced I never had much need to mess around with worlds or buffers. I assume you draw your UI at a constant resolution size buffer that you have tested to look good with the images drawn to it (say 1024x768) and then scale that to the actual resolution the user selected when you draw it on screen? Then you just have to scale the clickable areas of the controls so they will register events?

I never really put much thought into this before, but with my current game and how I handle the UI and really thinking about so many different resolutions when we get into the mobile space it's been at the front of my mind. Curious how others would handle this issue, but for me I've designed a small/medium/large value to all the fonts I would use in a game. When the game starts, based on the current resolution, it'll pick the "best" actual values to represent small/medium/large from a config type file which links in resolutions to size. Reasons for doing this. I define my UI by aspect ratio via % values of the resolution (or parent widget). So I may put a button at 10% x position, 10% y position, with a 25% width & 25% height for the 4:3 aspect ratio. Once I play around with the position/size on one 4:3 aspect ratio to my liking all other resolutions at the same aspect ratio will scale up/down the images of the UI based on the resolution and the screen looks the exact same, and this works perfectly! Except for the font size on the widgets! Since the fonts don't seem to be scalable I needed a system to figure out what size fonts I should use per resolution, but I don't want to define the layout of my UI (widgets) per resolution as doing 1 layer up to aspect ratio works for that. What this means is for LE2 I have add a bunch of font images to cover all sorts of different resolutions. It's nice in LE3 that we wouldn't have to do that, however, the system to figure out what size to use based on screen resolution would still be needed. Honestly, it would be nice if we could scale fonts by a % value. I'd love to define the font size as a % of the button size it's used on, and then when the button gets scaled so does the font to match, just not sure if that works.

My understanding is the flowgraph "blocks" are made from the scripts themselves. They get constructed based on what you define in the scripts.

If this system works out well me and Pancake helped with the idea, otherwise it was all your idea

That's the nice thing about this system CGMan. We can make these scripts ourselves and the layout is defined for us so they will all fit together!

Volume triggers like this open up the door (some pun intended) for so many things! It's really something so simple, but can have many game interactions from it.

http://www.leadwerks.com/werkspace/page/Documentation/le2/_/tutorials/introduction-to-animation-r474 Look around the middle of this tutorial and Josh does what you are trying to do.

The first thing I would do is make sure FindChild is getting the right bone. Just make a small example program where you aren't animating the entire thing, and just mess around with that bone to make sure you visually see the results. Also, I think there is a tutorial about this. The animating one.

I'm with Furblog, you have to get the head bone entity, animate the model as normal, and then move the head bone with your own logic. I did something like this a few years ago and it works.

This is why I like separating all these things into their own classes. As things get more complicated you end up with many of these, what I call, helper, variables and things start getting messy fast and if you have all this basically in 1 class it can end up getting very big and unmanageable. So what you are doing is basically what I was talking about.

lol wtf classic. Is this a "smart" bot or something

Decision Trees are sweet but to make a good one is complex. Their entire purpose is to basically allow non programmers (designers) to make the logic of the game with visual tools and system that the programmers made for the game, and be very flexible. They can easily edit the flow. No doubt the code for all the actions has to be programmed, that's a given. But giving all these actions to actors and having them make decisions and do these actions and testing all this out over and over again while making tweaks is basically what AAA game dev these days is all about. However, if there were a nice decision tree editor for an engine it would open up the door for some complex gameplay done by designers. Some actions & conditions can be basic and reusable but some are still very specific to the game too and need to be programmed still. This is what I like about "action" based or component based programming. You program very specific low level actions and you then chain together to make complex actions. If something is complex what as programmers are we told to do? Break it into pieces. Actions and behaviour trees basically do that to the extreme. On the other hand, making such a system can be complex to the point of saying what's the point

@Josh, Good old skettie code! Sometimes I want to go back to it because it's easier while you are writing. @Red, I do enjoy putting an object into the world and just having it work. It is intersting how the game industry is really putting programmers on making tools and systems more for designers to actually make the game. I can see why they do it that way.

I was hoping we weren't trying to convience each other of anything but instead just having a conversation of design and showing our designs. No right or wrong, just talking about design. Maybe you saw this as me saying mine design was better than yours? If so I'm sorry as I did not mean for that. Simply looking for what's the same what's different. I know these can be hard discussions to have because people often get attached to their systems and fight to the death to defend them and I hope I wasn't coming off that way. For sure. For me it's just about separation. What kind of action though? I'm curious to see how you do it for learning purposes because the actions I've seen were all higher level actions that when you break them down were really many lower level actions all done in the 1 state, which can start making the state complex and a bigger class. If you treat it differently I'd love to see example because maybe I haven't seen the right examples (the inet is full of junk ). If I've missing something with my understanding I'd like to know about it ya know

They would be different class entirely since the functionality is different. It's of the thought process of each different set of functionality at it's lowest form gets it's own action class to do that functionality. You could create a hierarchy at this level if you wanted though to share functionality. Maybe our transition to and from we want the same, but just the update we need to do something differently. You can make a base class so the enter/leave transition methods are called from the base while the update is specific to the child. All these actions have their own parameters as well, so you can get some custom stuff that way if needed. Notice the data contract idea that is required for an action. You can branch this way by querying the object information that the action expects the object to have to do some branching if required, but I think making a new action class would be better myself for code separation and maintainability. Can you give a pseudo example of your MoveTo? I think the actions idea might just work within FSM.

No, the objects (if meaning like actors, trees, weapons, etc) don't know how to do the tasks, they just know about the task classes. Classes for each task knows how to do the task on said object. The more actions you have the more your object code starts getting big and messy if the logic of doing said actions are directly in these object classes. So I would make an Action/Task child called MoveTo, which takes the object to work on and the destination to move to, and it's update method gets called over every frame and actually does the Action on said object. I like this style because technically speaking ANY object can do these tasks without having to be part of a hierarchy as in most cases to inherit the task functionality if it's directly in said object. You could put a MoveTo() function inside a MoveableObject, which is parent to Actor, etc, but now you are tied to this hierarchy for functionality, where in my example the hierarchy is more for data instead of functionality. It breaks functionality down to classes to avoid having to mess around with hierarchy restructuring that often happens. Now I know this breaks some idea behind OOP, but it adds benefits that I find very attractive escpecially in game dev. Adding a factory design to these actions can then make things very dynamic where any object can perform said task via a string representation of the action. You can also make a plug-in system for new actions because they are their own classes are not tied so close to a hierarchy of existing objects. I believe this system opens the door for a very flexible game dev experience and would be great in an actual game engine where people can just define actions in isolation. The only thing needed is a data contract between what actions need data wise from the objects they do their action on. I love talking about this stuff btw

Yeah, Behaviour Trees can sort of handle this but they generally are used for AI to make decisions. The things I describe above aren't making "decisions", they are doing what the player wants to do. The player made the decision already, and now the actions just need to play out and should not make decisions on their own as they are playing out. Slightly different than what Behaviour Trees are generally used for. I think the Task system I decribed can be looked at as sort of a State Machine that chains the states together to be played out in sequence which sort of blends State Machine and Behaviour Tree ideas together. The chaining part being Behaviour Tree and the executing each state being State Machine.

I find myself thinking about these design things inbetween or on the side of making a game. It's sort of like baseball. During practice I might try different kinds of pitches but during a game I stick with the pitches I know, but over time because of this practice I'm doing I'll soon know and use a pitch I practiced in a game. So given this practicing time, that's where I like trying to make it "pretty" and "neat" in isolation and not part of a game I had a game I was working on where I created a queueing task system like The Sims. I'd have a Tasks class which held Actions. Actions were like MoveTo, Speak, ChopWood, and they would be done in sequence. The biggest reason for doing something like this was because of the time it takes to do the action. They are not actions that can be done instantly. They need to be done over time and so the game loop has to keep going while this is happening. Without some kind of system like this I find the code ends up getting pretty messy and hard to maintain trying to manually handling all these states.

@Furbolg I understand that, but there are often other systems that maybe we haven't thought about before and can learn from each other and so I enjoy talking more system design than the normal "When is LE3 coming!!!!" topics that are dominating the forums. Trying to get the creative juices and ideas flowing.

Yeah, there you go. That's more like what I was looking for. I'm interested in systems, not health++. Thanks for sharing your system.

I'd argue that it makes your program more maintainable and extendable which are some of the main reasons it exists. We have to learn from our elders who created OOP for a reason.