Jump to content
Ultra Engine Community

Rick

Members
 View Profile  See their activity

  • Posts

    7,936

  • Joined

  • Last visited

 Content Type 

Blog Comments posted by Rick

    Josh

    Posted

    4 minutes ago, Josh said:

    The box material will turn red when the box collides with something.

    I just want to note that the high level concept you are doing in that example is basically connecting event(s) to functions. A great way to program :). I have multiple blogs on that from Roland and me back a  year or so ago. It handles arguments and other things like criteria to call the function or not (returns a boolean to call or not. comes in handy).

    Josh

    Posted

    25 minutes ago, Josh said:

    I think this design makes it a lot easier to plan and visualize. Looking at my AI alert example above, basically, what it is doing is taking a function that is like this:

    I'm well aware of the benefits of adding multiple scripts to entities. Some have been asking for it and simulating it in LE for a long time :). That's not the question. The question really is the best way to do it. Giving the ability while not pigeonholing you into a style is generally what I think is best/safest for the core part of the engine. Then you can add something like this on top of that.

    The value attaching thing is a great idea for sure!

    Josh

    Posted

    13 minutes ago, GSFC_1 said:

    wait, why is this a bad idea rick? Scratch has been very popular with incumbent youth seeking programming knowledge. I think josh could write:

    "Did you ever use Scratch on R-pi? Well then you will dig the skittles out of this" 

    I hope my post didn't come off as it was a bad idea. I said there are pluses to doing it this way and just needs to be promoted and supported by Josh (he can't just tell people to name their functions this way he needs to built them into entity scripts just like UpdateWorld() and others are).

    I mentioned that this is completely different from what Josh has wanted in the past. Josh was always more of a library vs framework guy. LE was always a library. it gave you generic ways to create games and/or multimedia apps. What he's saying now is way more specific and funnels people towards a common way of creating these apps/games.

    A library is more like a bunch of baking tools and ingredients. You have everything you need to bake something but it's 100% up to you on how to use those tools and ingredients to do it. A framework is more like following directions on how to bake something. It gives detailed guidelines on how to do it, but still has a little room for you to add your own special mix to set it apart. Josh was always a library guy with LE and with this blog we can see the shift which is surprising to us who have been around awhile.

    Josh

    Posted

    9 minutes ago, Josh said:

    It would be a good idea to start planning out some common functions and building a set of common behaviors, like below:

    I'm very shocked I'm hearing you say this. This is a complete 180 from your normal style. There are pluses to doing this but it would have to be built in and promoted by you, the creator, to work. You're basically making more game specific UpdateWorld() type script functions. I never thought I'd see the day.

    • Haha 1
    Josh

    Posted

    30 minutes ago, reepblue said:

    I see this as another tool in the toolbox. As long as it doesn't hinder what a programmer wants to do (Like if Rick wants to use an event system.) Its fine by me.

    It currently does cause issues with script variables being overwritten. You can't have independent script variables with the same name as they'll just merge into 1 variable that all scripts share. So people have to be careful with their script variable names especially if using a script someone else wrote as it could cause unforeseen and hard to track issues. What you just said is the main reason to just create a table on the entity for each script attached to store the instance of that script and then reference any function or variable by using that scripts instance because it's the most flexible way that satisfies the most use cases, which is not what this system is doing. Surprisingly, since josh usually hates forcing convention, this system forces convention even if you don't want it. ie. if 2 scripts have the same function name calling one anywhere will automatically call both every time no matter what. To get around that is a naming convention that you hope other scripts from other programmers don't have a collision with your function names. I'm assuming a very specific use case for the NASA stuff Josh is working on caused this.

    Josh

    Posted

    1 hour ago, Josh said:

    What this really helps with is scripts that add behavior and interact smoothly other scripts.

    In practice I don't think you will get this smooth interaction. If you look at the examples in this blog you'll see that 3 different people named a function with similar functionality differently. ReduceHealth()/TakeDamage()/HurtEnemy(). The chances that different programmers all name their functions the same in order to add different functionality is pretty slim. There will just be little cohesion to make this act as the bridge for adding different scripts from different programmers who weren't working together.

    While this helped your situation, which unless you had 25+ different scripts attached I don't see why calling the specific scripts reset is that huge of a deal, this is a pretty specialized situation for the NASA stuff you're working on.

    I think you'd be better off using an event system to get what you want so things are more explicit. Define an event in one master script on the entity and in it's Start() get references to all the scripts attached and add their Reset() methods to the event. Then raise the event and it'll chain call all those methods. While for your specific case it may seem like more work, for a more generic case, like our games, it gives more flexibility in chaining functions with different names by raising 1 event, it gives explicit intent which makes debugging easier, and it makes it so the community isn't trying to come up with consistent naming conventions which will never happen.

    Josh

    Posted

    I've waited a few years for this. Hooray! Why the change of heart?

    The implementation seems a little strange to me. I get you're trying to keep it simple and avoid having to prefix variables and methods with the script name but sometimes you may just really want to call one scripts function and not have all the ones with the same name called.

    I would rewrite your HurtEnemy() method like the below and then it's not that bad. This assumes GetScript() on an entity gets the instance of said script on that entity and that system is in place. This allows us to not have to type self.enemy as much and also reduces the indentation so it's easier to follow.

      

    function Script:HurtEnemy(amount)
	if self.enemy == nil then return end
	
	local healthMgr = self.enemy:GetScript("HealthManager")
	
	if healthMgr == nil then return end
	if healthMgr.TakeDamage == nil then return end
	
	healthMgr:TakeDamage(amount);
end

    I don't see anything wrong with the above. It's short and to the point. It really only does 1 extra check that a script with that name is attached. To call multiple functions have some sort of self:CallMethods("TakeDamage", args)? This might not be bad anyway as it can do the check internally if it exists so we don't have to continually do that check each time we want to call a function that we think might exist.

    • Haha 1
    Josh

    Ultra Engine Beta Update

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    Have you ever considered switching to a text map format on a flexible format like Json that allows for expansion, addition of fields, without breaking the loading of the map itself? The idea being we can add fields to entities and if said entity has a script those fields get added to the script? It could aid in external tooling. Just a thought.

    • Like 1
    Josh

    Posted

    Not that I know a ton about this but 256 may be guaranteed but what is the reality for most cards? I have to imagine it's higher.I mean there is the OpenGL spec but then there is the reality of the most popular gfx cards on the market.

     

    Did a quick search and was seeing that in OpenGL 3 this size was 1024. What version does LE use again? 4 right? I would think that size would be larger than 256.

    Josh

    Posted

    1. I feel like I asked this already but does a clustered forward renderer add to the dev by having to be lightmap steps like older forward renderers did? Part of the cool part about the deferred rendering I always thought was you just put in a light and ran the game and didn't have to worry about that stuff wher ewith forward renderers you had to do the light baking step which always took a decent amount of time with big scenes.

    2. Does a clustered forward renderer run on mobile? Not that is the focus just curious if it's a nice side effect?

    Josh

    Posted

    Do you feel the future of the flexible pipeline on the GPU will be 2 way communication? It seems that would help in this specific case and I would imagine others. I say this being ignorant of the effort the gfx card creators would have to do to get this, but at a high level it seems like it's an advancement in that field that could be helpful.

    Josh

    Posted

    For me the biggest thing would be getting the feedback to know what "frame" (I know it's not frame based) the animation is on as that's when you run certain logic to sync things to an animation. Would we get that if another thread was doing the animation from the main thread?

    • Like 1
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...