Jump to content

AggrorJorn

Members
  • Content Count

    4,780
  • Joined

  • Last visited

Community Reputation

1,678 Excellent

4 Followers

About AggrorJorn

  • Rank
    Aggror
  • Birthday 12/18/1989

Profile Information

  • Gender
    Male
  • Location
    The Netherlands

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. AggrorJorn

    Using Multiple Entity Scripts in Turbo Game Engine

    hehe, starting to have a déja vu again. I think for the past 5 years there has always been a topic each year mentioning the 'similar named' functions like "Kill", "Hurt" as well as using events. I don't see an event system happening for Turbo either unfortunately.
  2. AggrorJorn

    Using Multiple Entity Scripts in Turbo Game Engine

    I see your point Josh and the advantages to this method are plentiful based on your examples alone. It is an interesting idea with lots of flexibility. Maybe this is just me, but I see the level of flexibility as an increase to the complexity of the game. New users will lose track of what functions are attached to an entity. I am not trying to shoot down your ideas here btw, I am just trying to see if the advantage way up to possible disadvantages. For instance, I wonder how this works in practice when you are debugging an enemy hat has 8 different scripts applied that all have the Kill() function. With this method it seems that infinite recursion and stack overflow exceptions are constantly lurking around the corner here. If I have a bug and start debugging I would expect some sort of ListAllFunctions() that gives you an overview of all execution ordered function (duplicates) on an entity. As long as you can properly see the stack trace and easily verify which Kill() function has already been called you can can away with it. Either way, the concept of attaching these scripts is interesting and the discussion about it as well. Keep on improving and blogging.
  3. AggrorJorn

    Using Multiple Entity Scripts in Turbo Game Engine

    This is to this day how I would have liked the lua scripts to have worked in Leadwerks. Albeit slightly differently scripted. The example you give really describes the problem with singular scripts. The player script has no business seeking out a healthmanager subscript that should be managed by the enemy. It is the enemy's script responsibility to expose any of its subcomponents to the outside world. Personally I never check if something is a function either. By convention variables are lowercase and function are not. In this case the player only check if it has enemy and that gives it damage. --player function Script:HurtEnemy(amount) if self.enemy ~= nil then self.enemy:ApplyDamage(amount) end end The enemy has a reference to the health manager which it retrieves in the start function. If it is not there, the game should simply report an error since something is wrong in your setup. Lastly, the enemy script passes the damage value on to the right component(s). In this case only the healthmanager. Ideally you would set this up by events. --enemy script function Script:Start() self.healthManager = self:GetScript("healthManager") if (self.healthManager == nil) error("Enemy has no healthmanager. Something is wrong in your setup.") end function Script:ApplyDamage(amount) self.healthmanager:ReduceHealth(amount) end The health manager finally actually does something with it. The amount variable should only be changed by the healthmanager itself and not by other scripts. --healthmanager function Script:ReduceHealth(amount) self.amount = self.amount - amount end Now you have the logical separated scripts that are far easier to maintain due to small amount of code lines, the absence of constant nil checks and by keeping responsibility to the component and its owners. This would be my choice too Rick. Maybe that is because this is far more similar to how Unity does it with GetComponent<> or Godot with get_node. I think what plays along here is that Josh really likes to implement his own methods rather than just 'copying' the same methods others use. Both systems work, and Lua is awesome in this kind of flexibility. @Josh: have you considered using a GetComponent feature? People using other engines will recognize this function and find it perhaps an argument as too why they could potentially switch. A future documentation page I would recommend: Switching from Unity to Turbo/Leadwerks. "If you are used to using GetComponent<>(), with Leadwerks you are just as easy on your way with GetComponent(YourScript)." From the day I learned that this was possible I never even considered using multiple return values. Not that is not powerful, but merely the complexity this suddenly adds, stops me from using it. This already happens when you have a function that can have any number of arguments. If you don't deal with all these arguments you will eventually kick yourself in the knee. Especially if you program in a team, you expect that a user does something with the given values or you would need to have strict guidelines in how to deal with them. Thought you would never ask. Lets start with some basics: Zooming in and out of a current layer. Flowgraph works by creating scene level graphs and prefab/model based graphs. Level based Layers: When working with FPS levels (like the elevator demo), you want to add level logic for a certain area in a layer. eg: Starting area layer Elevator room area layer Panels These are more UI containers for your 'graph nodes' to attach to. Naming or colouring the panels is a nice addition. Improved input types: curve property material selector More advanced: Nested flows/ Object flows. Nested flows are excellent for reuseablity. Nested flows are fixed flows per entity/prefab. This means a flow is always similar regardless of what level you are playing. Example Lets say you have to 3 script in a flow: CollisionTrigger, timertrigger and EnemyTurret. The CollisionTrigger.OnCollision can activate the Turret The TimerTrigger.OnCollision can also activate the Turret after a given time Double click on the EnemyTurret opens the subflow of this turret. This flow is on an object level instead of scene level. The subflow always has its parent entry arguments coming in The subflow always has its parent exit arguments going out. This subflow produces a rocket that can again also be double clicked since it is an object flow.
  4. AggrorJorn

    Trademark for "Turbo Game Engine"

    So what exactly does the trademark in this case entitle? Others are not allowed to use the word 'turbo' when they make something similar like a game engine?
  5. AggrorJorn

    Cutscences

    When you say cutscene, do you mean playing a video/animated gif or an ingame animation/camera path?
  6. AggrorJorn

    Leadwerks Editor UI Themes?

    Not beyond these options:
  7. Congrats Josh. As stated before in your blogs: unlike the mobile direction, VR is actually bringing back the power to the engine. So leadwerks 5 will contain the Turbo changes, minus the new editor. Do you think you will expand your team, now that you have a contract?
  8. AggrorJorn

    Why Isn't Leadwerks More Popular?

    If you don't mind video tutorials, this entire list of videos should be a good start to getting to know all lua basics including some leadwerks specific lua scripting:
  9. AggrorJorn

    Why Isn't Leadwerks More Popular?

    There have been many times this forum was rather empty, but right now it has hit one of the lowest in a very long time. I have been active in this community since Leadwerks 2.2 (about 10 years ago). There are various events and reasons (of which some were already mentioned) that cause the community activity to diminish. The largest change was going to Leadwerks 3. We lost several core features: the powerful and ahead of its time real time deferred renderer was not ready at the launch of Leadwerks 3. For a year or so we had to bake our lights. Terrain and vegetation were also gone. It would take several years before it would return. Especially the initial announced price (I think something around 800 dollar scared a large part of the community away). I was very skeptical but I didn't have any large project in development so I just played around with the engine. Mobile support. I get it that a business has to be run and that Josh needed to inovate. Josh tried really hard to make it happen but it was not meant to be. Many people didn't like the mobile direction since Leadwerks's strongpoint was its renderer. Flowgraph: This is something I never understood. Flowgraph was there from the start of Leadwerks 3. Since then, nothing has happened to it. Why? The core mechanic is there and it works. I remember that Rick and I made 2 little scripts in the first days of its release and they were so much fun to play with. But without zooming, layering and grouping, the flowgraph is just an empty tool that is pretty much useless for an actual game. For a small tutorial or demo scene, it it useful, but after that it becomes unmanageable. The website, forum and documentation have had soo many changes during the last years. At some point it looked like this was the only thing that was in development. Of course maintaining and having a proper website is necessary to a certain level, because it attracts new customers, but it really felt like this was taking a lot of time of engine development. That said: The current forum, with documentation and store it the best version yet. Steam: Moving the selling of Leadwerks to Steam was a needed step. Not everyone liked it (I personally did like it) as they wanted to have a separate installer rather requiring Steam for the editor to run. I think it made spreading the software easier. Especially with beta branches, features could be tested more frequent. Steam workshop: From my own experience: just plain awful. This has nothing to do with Leadwerks in my opinion. The Steam interface was (and still is) outdated in design, sluggish and lacks to many common features for it to be attractive. Luckily this is replaced now with the forum's integrated web shop which already works 10 times better than Steam. Game launcher: Conceptually really great but for me it never really took of. Often it didn't respond and without curating any games, it scared more people away than that it actually attracted. Default Lua editor: the highest level of frustration of working with Leadwerks came from using the embedded lua editor. For beginners it already didn't help that there was no auto-completion (this was added later). Proper documentation popups like most mondern IDE's do was not possible. If you compare that how other default tools do that, then you are going to have a much more difficult time as a starter. Luckily Visual Studio Code is going to change that. Debugging: maybe that is just me, but debugging always felt like a pain. I would end up iterating over some weird table over and over again or I would hit breakpoints that came out of nowhere. Again, especially for beginners this is a real demotivating factor. Editor customisabilty: Again something personal: the biggest issue that I think causes people to go away is the editor customisability. No assigning of custom hotkeys. Not being able to add shortcuts to toolbars ("Create pivot" for instance). No multiscreen support or customizing the editor layout. No custom editor plugins or tools support. How many tools haven't I made in Unity and unreal, that extend my workflow. From simple drawing lines to see where my characters waypoints are to generating structures in the scene tree like ropes. Maybe performance may be an issue in those engines, but the workflow for creating gameplay and level design is so much faster because of it. Documentation: @gamecreator already said it: there is never enough documentation. Ironically the documentation website looks pretty good in its current state, but really needs some updating. In the private Turbo section of the forum, I hoped to convince Josh to move the entire documentation (including API) to github so that the community can help out. With Turbo I would really like to help out were I can making new tutorials, templates and what not. Many of the issues above are going to be solved with Turbo. Josh's blog for the last few months have been a joy to read. Josh figuring out all these insanely crazy and complex technological things is amazing. I certainly couldn't do it.
  10. AggrorJorn

    Pre-Alpha v1.0

    That looks interesting. What a cool concept.
  11. AggrorJorn

    Headshot Kills?

    When you shoot you perform a pick. If it is an enemy the Hurt function is called right? Pass along the pick position with this hurt function. Inside the hurt function, you need to have a reference to this box. You can do this by creating entity properties, or by looping over the entities children until you find the name of your headshot box. (note that when you loop, the pivot might not have been called yet and the box could possibly not exist.)
  12. AggrorJorn

    Headshot Kills?

    Can you show a screen of your enemy in the scene tree? When the pick takes place, you get back the entity it picks. Since this is the enemy with (I assume) the AI script, you call its Hurt() function. You can pass along the hitposition with that function. In the hurt function you start looking for bones or boxes that represent body parts like the head. It would be even better if the references to the boxes are there before the Hurt function is called. Enemey (AI script) BodyHead BodyLeftArm etc
  13. AggrorJorn

    Headshot Kills?

    A cheap way to determine if it is a headshot is by creating a box that covers the head. When you do a succesful pick on the enemy, you get an entity and a pick position back. The entity (enemy) should have a reference to the headBox. Now simply check if the picked position is in the bounds of the entities headbox. Another basic way is iterating over the enemies bones and see which one is the closest. If the bone has the name 'head' (or whatever it is called), you register it as a headshot. This might give some false positives in some situations depending on the bone structure.
  14. AggrorJorn

    Function on Lua

    Put them in a separate lua file and the in main.lua use import "myscript.lua"
  15. AggrorJorn

    Massive FPS Drop

    That looks pretty good too.
×