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

    Rick

    Posted

    OK the team is set. I'll be drawing up details and tasks for everyone to do over the next couple days and make a forum post to kick off the project.

     

    I'll be in contact with group members also. Stay tuned! LCP 2.0 is about to kick off!

    • Upvote 1
    Rick

    Posted

    @YouGroove Would you be ok with making some props for the scene if we request some from you at some point? Not sure what it would be right now but we can let you know in a week or so if we need some extra ones that aren't already in the last LCP. Thanks!

    Rick

    Posted

    @beo6 Welcome aboard! I'll mark you down as a programmer and assign a task next week when I get the design finished. Thanks for the offer on the SVN and Redmine. I'll consider it and let you know about that next week also.

     

    We now have 2 programmers. Need 2 more of these and the remaining requirements of artists/level design/sound.

    Rick

    Posted

    @Furbolg Come on man embrace Lua :)

     

    I want people to compare the results and maybe team members who were on LCP 1 and join LCP 2 to compare the process. I think the point of these LCP's should be to learn and find what works best when working in a team just as much as getting the game finished.

    Rick

    Posted

    Sweet Aggror! Thanks for joining. Do you know if it's the source for the models though or just the gmf files? When I tried to import some of the weapons they looked messed up. Example was the bat first person view the hands were all screwed up when I imported into LE3 so was thinking we might need the source for the modellers to modify/fix for LE2?

    Josh

    Leadwerks 3 Update Available

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    You'd have to define "core of gaming" and then decide if the money is there or not. My mom and dad aren't buying PC games, but they will spend .99 on a mobile game for my daughter to play while they have her. Can we simply throw casual games to the side just because they aren't the OMGSWEETFPS game we all want to make? If you are running a game company and aren't hitting mobile in some way you are either massively established or about to go under :)

     

    Mobile is a fact of life and it's not going away.

    Josh

    Leadwerks 3 Update Available

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    @beo6 I understand the other side of the coin, I just would like the option to really do component programming (and I think leaving the multiple script logic in doesn't really hurt much).

     

    From the example Josh gave he/they weren't going about it "correctly". With component design you don't hook the wiring up directly inside the scripts/components because that creates exactly the issue he ran into. Those scripts are meant to be generic and only do their specific task without knowing about any other script. How can that be possible you might ask? Well, it takes more thought about each component. You need to expose events/messages and fire events/messages and do the hooking up of these in what would be a game specific script/way. The flowgraph is one way to act with this so it's not a total washout for us.

     

    So even though Aggror's way is decent too, if you do that inside the actual components/scripts there is a reliance there that you don't want.

     

    This is a really different way of thinking about how a game works. Instead of following the logical flow from top/down and programming it that way, you have to think about what events each component could trigger from within and what functionality it should expose. Then at the start of the game you do all the wiring between components instead of interacting directly with the components during run-time.

     

    The best thing about the component design is making very robust/reusable components that are completely isolated. This means working in teams becomes that much easier as long as you have thought out the design of what components you need, you can give components to people to make with no fear of them colliding or requiring other components. It makes your code more reliable and stable as well as something with no outside dependencies is easy to test and make less errors with.

     

    In short, I think Josh tried to use conventional programming mixed with component programming and that doesn't work. I don't see the harm in allowing multiple scripts for those who want to use that style. If you don't want to you can still just make 1 script. All the code is already there for multiple scripts so why disable it? Just doesn't make sense.

    Josh

    Leadwerks 3 Update Available

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    Yeah SendMessage() would be good too, however there is still a level of dependency with that, it's just not as hard as an actual object or function. I still think a script that attaches functionality from script to script that we create specifically for the game in question would be cool too.

     

    Oh well. :/

     

    edit: The other side of this coin is being able to attach multiple scripts that don't have anything to do with each other or need to communicate at all. For example having a rotation script and a moving script attached to a platform or something like that. They don't need to talk, they just need to do their own thing. Without this we are duplicating code inside the 1 script. Now that's a simple example but there can/is more complex situations just like that also.

     

    I just don't see what the harm is. If you only want to use 1 script then use 1 script, but leave the multiple script functionality there for those who want to use multiple scripts.

    Josh

    Leadwerks 3 Update Available

    in Ultra Software Company Blog

    A group blog by The Ultra Software Team in General

    Posted

    Can't say I'm thrilled about losing the multiple scripts attached. The animation manager along with other stuff was a good example as to the benefit of this system. Guess we have to copy/paste animation manager code into our 1 entity script now, or rewrite animation code for each entity?

     

    At least logical entities will come to the flowgraph, which will add some power to the flowgraph, even though we can do that today but just need to use a pivot to attach the logical script too.

     

    Once we got into more advanced scripted gameplay, we found that a component approach turned out to be very tedious from a programming perspective.

     

    Can you explain how you found it tedious, or maybe explain how you didn't see the benefit of reusable components that other people could use or better yet programmers could eventually sell? Multiple scripts was meant for the programmer who wants the benefit of reusable scripts and also for the non-programmer who just wants to plug and play functionality. I would rather add 5 different specific scripts that I can reuse over and over again in different situations than recode or copy/paste code into 1 master script per object.

     

    Also, couldn't you just leave in the fact that we could add multiple scripts and those who don't want to do that can just make the 1 script? Allowing multiple scripts doesn't hinder the person who wants just 1 script, unless it was causing you bugs behind the scenes and you just didn't want to deal with it wink.png

     

     

    Rereading: In my view components need to interact via events, and the attachment of these events is what's specific to the object so as to not break encapsulation of the scripts. This is basically what the flowgraph is doing and why it's needed in a situation like this and does work if we have multiple scripts just like in the script link I provided above.

     

    Another option for the programmers would be to make 1 script that is just the glue attaching the events to the functions of the other scripts attached and then gives a more event oriented programming model.

    • Upvote 2
    AggrorJorn

    Posted

    I think he means store like components in their own lists like in his first post " list/vector for each componenttype (vector<movecomp>, vector<guicomp>...).".

     

    When you process stuff you process a list at a time so that all/most of the memory that list refers to is in cached memory making it faster to deal with.

     

    On a side note, the event code I posted on the asset store works great with this style of design because it lets components fire events and register to get events and helps with decoupling the classes. Your connection becomes hooking up events between components. I'm not sure if you thought about how components communicate together but this is a great way to do that and not have each component need to know about the other in terms of it's insides. The generic GameObject is where they know about the other components attached.

     

    I was playing with this style in C# in LE2, but I stored it all in 1 list because my components were plugins (dll's) and loaded dynamically at run-time and added to generic game objects at design time. This is very dynamic and easy to extend functionality and didn't require creating extra containers for a new component.

     

     

    This is a pretty good article that takes you through the thought process http://gameprogrammi.../component.html . However, I don't like the idea of having the specific components in the game object that they stay with. They do talk about another communication method of messages.

     

    The funny thing is all of this is basically how Lua/Flowgraph works in LE3 smile.png

     

     

    Here is the method that really takes this to the extreme, and should help explain why and how to do this.

    http://gamesfromwith...oriented-design

     

     

    Look at the first answer. I think that helps describe witih a small example the idea. It's for sure a different way to think but it produces faster code.

    http://stackoverflow.com/questions/1641580/what-is-data-oriented-design

    • Upvote 1
    AggrorJorn

    Posted

    Yeah I've seen the extreme of what can be done to avoid memory cache misses and it can totally change how you have to think and design your code. I can't remember the name for that style now, but I find it a pain to read myself. This little example isn't the extreme but you can go far beyond this to get the speed. Where does it stop and what do you sacrifice?

     

    I think some of the benefits of having the 1 list is the flexibility to it. There are always trade-offs between flexibility and speed. That might be more relevant in a more dynamic language than C++, but if he creates more components later, the maintenance is more involved as he'll have to create separate lists. This may seem small, but it can start adding up if he has 100 different components over time. It also adds in complexity.

     

    That guys says one of the primary benefits is reducing cache misses, but I'd argue one of the primary benefits is also flexibility.

    AggrorJorn

    Posted

     

    When the processor needs to read or write a location in main memory, it first checks for a corresponding entry in the cache. The cache checks for the contents of the requested memory location in any cache lines that might contain that address. If the processor finds that the memory location is in the cache, a cache hit has occurred. However, if the processor does not find the memory location in the cache, a cache miss has occurred. In the case of:

    • a cache hit, the processor immediately reads or writes the data in the cache line.
    • a cache miss, the cache allocates a new entry, and copies in data from main memory. Then, the request is fulfilled from the contents of the cache.

     

    IMO this can get pretty advanced and you can get pretty extreme with it and unless you are creating the next gen game isn't something you really have to worry about, but it allows you to get max performance which sounds great until you realize to really max this in your entire application it really changes the structure of it. Often to the point of making it confusing to understand and maintain if you aren't used to it.

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