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

    Leadwerks 5 Beta Rollout

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    When I did UE4 I would simply get one month to get the software and then I was able to cancel and just not get updates but still use that version. I think they eventually stopped the monthly fee and I would think for that reason. They would pump out smaller updates and fixes weekly which I think they thought would be why people would keep thier monthly they subscription, but I don't think it worked out that way. I would renew about every 6 months just for that one mo th to get caught up on all the updates/fixes. 

    What is is your plan for making this subscription work? Will we not be able to use the app without an active subscription or will we not be able to get updates only without an active subscription? If we can still use the app but not get updates then I can't see people keeping an active monthly subscription. They'll just renew when they want an upgrade or a fix. This, however, means to incentivize people you have to be pumping out fixes and advancements every month to make it worth it for people.

    If you make it so we can't use the app then that only refers to the editor. People could still code in LE without issue. The editor isn't really required it's just a convience thing. They could easily build most of thier levels and such in a modeling package.

    I don't see how a subscription base works in today's world which is why I think you see engines dropping that idea now. Your pricing models are always about 2-3 years behind the big engine leaders. Learn from thier mistakes.

    People come to Le because it's easy and it has no royalties. I think they also liked just putting up a reasonable amount of money every year or so and forgetting it. If people can still use the software and just not get updates you'll end up with probably $5-$-10 a year from a person. Probably just best to charge $25 per major update which should be yearly. You'll get more money and people won't have to screw around with the monthly game of subscribing and unsubscribing based on what and when they want to update to current. Most people probably see $25 a year for updates as very fair.

    • Upvote 4
    Marcousik

    Posted

    It looks like each segment is its own model. Maybe the towers all grow segment by segment over time and randomly and you have to shoot the tower to lower it by one segment. If any segment reaches a certain height you lose. Each round could be time based and each round gets faster and faster. Each new level has a different pattern of towers and more towers.

    Its just the first thing that popped into my head when I saw the image.

    Josh

    Posted

    That async loading style seems to be a pain. Ideally I'm guessing there would be one place where the event loop exists, but loading of models may exist in another place. So how do you get the resulting model thst was loaded to the place that called the load async function?

    C# handles this with an idea of async/await. It's a form of coroutine where you prefix an async function with await and it'll leave that function and continue with the main app loop and enter back in where it left off when that operation is finished. From the programmers point of view you write sequential code that's doing asynchronous stuff. Sadly C++ doesn't have this directly but it is proposed. However all that's really doing is a state machine behind the scenes to make it seem easy. It seems like C++ has some built in libraries that can mimic this behavior in c++11. It's called future library. I haven't used it but it may help get a more streamlined way of loading stuff async without needing some kind of event loop to go through which messes up the program flow and will probably result in bad designs and/or global variables required.

     

    Rick

    Posted

    I'll give a real world example that can help people get in the event action component mindset.

    Tjheldna and I are making an rpg turned based fighting game. Think old school final fantasy like. So you have your characters and enemy characters. When it's one of your characters turn you select an ability and then select a target to do that ability on. Ultimately a message is sent to that entity to do damage to it. I call that message "do.damage". The target entity gets onReceivedMessage event raised whenever it gets a message. We then hook up components actions we want to do functionality to this entities onReceiveMessage.

    So in my example case I'm getting a "do.damage" message. So my thought process was I need health in order to take damage so I create a health component. It's a pretty basic component to start with. Simply has a health variable, and an action I named doReduceHealth(args). The arguments table that came along with the "do.damage" message has a 'value' variable with the amount of damage to be done. So inside doReduceHealth() action I reduce my health variable by args.value. I then add the health component to my character entity and hook up its doReduceHealth() action to the entities onReceiveMessage event and part of that subscription I have a filter function that returns true when the args.Message == "do.damage" so that when onReceiveMessage is raised it'll only call my health components doReduceHealth() action when the message we received is "do.damage".  Now my health is being reduced!

    So we were rocking that for some time and all going well. The next part shows the lego like idea of this system. It's very much like snapping legos together ifeach lego was a piece of functionality. Because this is an rpg we need stats like armor, strength, etc. In our specific case one enemy has an aura that reduces all damage by 50%. So another stat would be damage reduction. So I know I need these stats thst kind of all play together in some way. So I create a Stat component. Inside I create a variable named damgeReduction which holds a percent value. The point of this component at this point in time is to reduce the damage trying to be done to me. So I create an action named doReduceDamage(args). One good side effect to our system is that actions are called in the order they were hooked up to the event. So clearly I need to reduce the damage coming into use from the "do.damage" event our entity gets before the health component does the damage to our health. So before the health event hookup of the "do.damage" message event I hook up this stats doReduceDamage() action. The other benefit to this system is that arguments to actions is a table and tables are passed by reference. Which means if I modify a variable value that is part of thst table in one component action, the other component actions thst get called after that will see those changes. Perfect! Since our stats doReduceDamage action is called first I'll reduce the args.value number by whatever our stats damageReduction variable is. Now when the health components doReduceHealth action is called the args.value variable is lower. I just easily and in an isolated way snapped on functionality.

    The last day or so I've made posts trying to figure out how to draw to a texture and then put that texture on a sprite. The reason I'm doing this is because I need to show the player how much damage was done. I needed the value of the damage being done to show up on screen above the characters head and then rise up a little over time. So guess what? New component! I created a RiseText component. It has an action named doRise(args). I hooked this up to the entities onReceiveMessage event and raise it when it gets the "do.damage" message but it's hooked up AFTER the stats actions so that args.value is already modified and the true value that is being done to that entity's health component. This is where the benefit of coroutines come in. doRise() action of this component does everything right inside itself. It creates the needed variables for buffer, material, etc. draws the text and then loops and tweens the text upward while yielding out. It's nice and more natural to be able to do that all in that one actionvs having to set state variables and do it in that components update() function. An added benefit to why it's nice is because when an action is raised a unique coroutine is created that wraps it. This means that even if the same action is called multiple times each one is ran in its own contained state. So one instance of that action might not be finished while another is called again but because they are wrapped in thier own unique coroutine they don't effect each other. If we didn't have this then calling the doRise() while another rising text was still happening in its update() function would cause thst one to stop so it can do the new request of rising text. If we didn't want that then we'd have to get into possibly storing multiple instances of possible rising text ourself. What a pain. With actions being wrapped into unique coroutine objects we don't have to worry and we can code more naturally.

    So I hope this illustrates the mindset of this system. Snapping smaller fairly isolated pieces of functionality together to get complex functionality. Maintaining each component is extremely easy since thier code is usually fairly small and it's contained in its own "class" and file. Removing its effects is simply commenting out its event hookups which are usually just a couple of lines of code.

    The only "coupling" components have is through the arguments. You need to know what variable names are part of the args table from within a components action when you hook up to an event. It's as loose of coupling you can get. It doesn't have anything to directly do with components structure themselves. I remember when josh first started this version of Leadwerks where he allowed multiple scripts to be attached. He found himself querying the other attached scripts to see if a certain script existed and then directly calling its functions. He didn't like that and he was right. That sort of defeats the purpose of components being isolated and creates a spaghetti mess of code. People in Unity still do this and I think it's a mess, and bug prone issue. Once you start working with hooking up actions to events things just become so much easier to work with.

    Learning what size scope to make your components (not too big not too small in scope) takes a little practice and feel but once you get the feeling down you are off and rolling.

    • Upvote 2
    Rick

    Posted

    We have a long term goal of allowing, from the editor, pulling down and publishing from/to github components that people create for this system. GitHub has a web API and if people use a certain tag on thier components on there we can easily query those and display them in a list to pick from. Sort of like a package manager. However, getting multiple people to use the system will help better define it before we do that. At that point we would want to have everything solid for a version 1 release.

    We think that it's really easy to create actions and events and then visually hook those up together to make more complex functionality. 

    • Upvote 2
    AggrorJorn

    Posted

    The zone really does have a special place in LE history so it should really be made an official mini game with functionality. Maybe  FPS with some mutant dogs that hunt you down with guns, ammo, and med packs scattered around. The dogs can just randomly spawn every once in awhile near the player. 

    • Upvote 1
    AggrorJorn

    Posted

    I wouldn't hold your breathe on the ui part. We just really need to come together and create a good community one with a wysiwyg editor to be complete. I have a ui library that I use for our games that handles screen resolutions correctly, does some tween animations if needed and is image based (vs drawing lines) but it's not complete as I use it for what I need at the time. I think tonight I'll make a post and show it and ask for help to make it more complete. It's sort of HTML /CSSish in style where there are no controls just an element that can have a bunch of styles and properties that determine how it looks.

     

    Honestly even if josh does release something it won't meet most people's need and it'll be fine for development as it gives something but for production you'll be asking for a lot of additional features that'll take forever to be implemented because he's doing lots of other things. Josh doing a ui to completion implementing tons of features people would want would take a good year of focus which isn't going to happen in my view.

     

    In all honestly the ideal would be to recreate an HTML and CSS parser to LE drawing commands but that's s huge effort that nobody is going to do so a close idea to that is easier.

     

    Sorry didn't mean to high jack thread.

     

     

    A 3D minesweeper should be fairly easy and gets more into 3D. Could just make boxes for tiles with a slight angle of camera to see them all. When not a bomb a 3D number or sprite appears and rotates around itself.

    Josh

    Posted

    I really like XML for storing website data. It's a lot more transparent than a MySQL database.

     

    Transparent for who? Normally you'd have a web API of DB data to make it transparent for the users and so it's not much difference for us. A URL returning data is the same. If more transparent for you on your web server I can see that. I think it's probably just easier to describe something like this data outside a relational database.

     

    As long as we can get the data in a nice format like this I think everyone will be happy. Opens the doors for more possibilities.

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