boagz57

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About boagz57

  • Rank
    Member

Personal Information

  • Interests
    Art
    Programming
  1. Pitfalls of pixels as unit in game

    @JulieMaru-chan What about for things like collision detection and physics? Do pixels still work out okay for these kinds of calculations? @lawnjelly What about for a 2d game using vector graphics?
  2. So I've been trying to develop my own little c++, 2d fighting game from scratch and I'm hung up on what exactly I'm suppose to use as 'units' for my game. Currently, as suggested here on another game dev site, my game screen is thought of as a 160x90 grid. So if my game is being run at 1080p screen resolution, that would equal exactly 12 pixels per 1 grid unit (which I call a world unit). For example, I will have code in my game where I will tell my sprite to move 10.0 units/sec in the positive x direction. This means at 1080p my sprite will move 120 pixels/sec when run (12 pixels/unit * 10 units). Recently though, I've started trying to add some collision detection to my game and I've run into a bit of an issue with when to convert my world units into pixels and getting my collisions to work properly. While I'm sure I can fix this after some time, this got me thinking what exactly are the problems with just assuming a certain screen resolution and working strictly with pixels in my game? So instead of saying 'move my sprite 10 game units/sec' just say 'move my sprite 100pixels/sec', avoiding and unit conversion techniques. Then, if I want to, I can come up with some way just to upscale to higher res images or whatever for denser screen resolutions. The reason I ask is on a lot of forums people seem to be against using pixels as units when it comes to collision and physics, even for 2d games.
  3. I'm thinking of developing a 2d fighting fame for pc and I was curious as to how much animations would cost per character. I would also like to know the difference between hiring for traditional sprite sheet animation, where an artist would develop each frame of an animation, vs creating animations through something like spine. I read somewhere that artists can charge anywhere from 8-15 dollars per frame for sprite sheet animations, so for a 300 animation requirement at $10 per frame, that would be around $3,000. Does this sound like a reasonable estimate for 2d animators today? What about the cost of a single animation from the use of something like spine where animations are created through skeletons and keyframes? Any info on the subject would be appreciated.
  4. After looking around at game engines the other day I came across the godot engine. From what I could gather, it seemed to be the most programmer friendly engine in that it allows you to script natively (GDnative) and even extend engine functionality through C++ 'modules' (as described here). Being a C++ programmer I like to have full control over my game and how it runs but I don't necessarily want to start from scratch and godot seems like a good middle ground. However, when looking at the pros and cons of the godot engine I found this site which lists a con for godot as difficult to optimize since: I'm curios if anyone has any experience creating modules with godot and what exactly their limitations are in regards to optimization/control over your game code. According to godot's author you even have the ability to utilize a different renderer through modules making me believe that even though godot has something resembling an OOP architecture at its core, you can still implement a data oriented render engine if you so pleased.
  5. @Kylotan I'm really finding this to be quite true so far. Everytime I think I've grasped a concept and implemented things well I run into another 'design decision' I have to make no to far down the line. For anyone considering implementing this architecture I will give a quick overview I've what I've gone through so far. For example, at first I had decide my basic component architecture. Since I will only have two characters on screen with a background image (for a 2D fighting game) both characters will be almost identical in their makeup. So I have components that are statically added to a 'Fighter' class like so: class Fighter : public ComponentHolder<Comp::Transform>, public ComponentHolder<Comp::Velocity>, public ComponentHolder<Comp::SpriteTileSheet>, public ComponentHolder<Comp::Animation>, public ComponentHolder<Comp::Input> { public: Fighter() = default; ~Fighter() = default; template<class T> const T GetComponent() const; template<class T> void Insert(T comp); }; template<class T> inline const T Fighter::GetComponent() const { return this->ComponentHolder<T>::component; } template<class T> inline void Fighter::Insert(T comp) { this->ComponentHolder<T>::component = comp; } My Component holder class is just a class which contains a single protected templated 'T component' member which I can access via 'Fighter' class. This provides a quick way to get and insert components. Okay that part done. Then, not too far down the line I discovered the issue I wrote about for this thread, which was how I'm suppose to decide what should be a component and what shouldn't? How granular do I need to be? After coming to the conclusion that I shouldn't be making things to granular and should think of broader components such as animation component and Input component, I ran into another issue of how components are suppose to talk to and use one another. This is where some suggestions came in of creating one or two explicit dependecies inside components if you need to or just parameterize components within component systems (which are just functions) which will help provide the glue to combining components, or both I'm sure in some cases as some components will probably need information provided by others. Even after all that there are still many design issues that come up almost every day on how to implement this custom ECS like architecture. Obviously design is important in software, but sometimes the design might just be way to complicated and unnecessary for a lot of non-triple A style games. So, hearkening back to what @Kylotan , as well as a few others throughout this post, has said I wouldn't recommend trying to implement this sort of architecture in any serious game you want shipped without already having a lot of experience with ECS in the past and having mentally resolved all of the issues mentioned above. Obviously if you're just trying to learn to develop an ECS like architecture and see how exactly it can be used in games then definitely go for it as you will learn a lot about the backbone of some of the major game engines such as Unity and Unreal.
  6. @Servant of the Lord Great! Thanks for clarifying and being very active on this post.
  7. @0r0d This is one of the major problems I'm having with trying to design my code base. Deciding when something needs to redesigned. I've heard all the horror stories about software going down a certain path and then after a while having problems that require massive amounts of work to try and fix. Every software article/book you read is almost entirely about how you should try and avoid these kinds of problems. Because of this I'm constantly second guessing architecture and spotting potential issues here and there. I guess programming is about finding the right balance between clean code and moving forward despite obvious issues. The problem is I rarely see more pragmatic discussions on developing and designing software architecture which can make it difficult to develop in my day to day software design. If anyone has any advice on this aspect I would love to hear it. That is how do you typically design an architecture and balance the need to constantly refactor your code (due to obvious potential issues) and the need to move forward in a project? Does it make sense to treat refactoring like optimization? That is, only refactor when any of the 'potential issues' really do start effecting your code base? Or is that too much of a risk as this can leave your architecture a mess after too long.
  8. @Oberon_Command Would you be able to provide a quick pseudo code example of what your talking about here?
  9. I had a discussion above with @Servant of the Lord concerning component granularity: So if I try and think of components more broadly then I'm sure other components will inevitably start needing the functionality of other components. @Servant of the Lord suggests passing in components to other components to help with dependent functionality. You were saying that components needing other components should just go through the Entity. I know you described this a little bit but would you be able to give a quick pseudo code example? And would this be any better than just adding components as parameters in other component functions/constructors?
  10. @Zipster This was exactly my concern earlier when @Juliean suggested to just grab the components and set them. I always felt as though components should not be exposed at a high level. But without enough experience it's hard to figure out ways to separate out an abstraction that will work for all systems I will eventually implement. All that you mentioned are some of the same reasons I hate using getters in code because they often expose implementation details and couple code. If a getter pulls out an int from say Transform.GetLocation() but then later on I decide to change location variable type to float, then I have to change that everywhere GetLocation() is called. Also, if for some reason I just wanted to get rid of a Transform component and do something else, then I also have to get rid of that component from all high level code as well. I like your example and will consider experimenting with it.
  11. Haha, this is exactly how I was feeling when you were describing just manipulating components directly "yeah.....no?" Obviously because ever since you start programming your always taught to encapsulate and data hide and all that. But I think your final sentence explains it all Sometimes the cost of bending/breaking the rules a bit is far less then adhering to them. Maybe this would be one of them given components are really theoretically just data containers and high level code is easier to deal with. Though I will say then when it comes to my systems I like the idea of trying to implement no side effects by either just taking copies of components within systems and returning new components or taking const references and just pulling out the data I need from the components and again returning a new component.
  12. @Juliean Let me ask you though, how do these kinds of systems usually allow users of the engine (typically implementing the game logic layer) to access and set the values of the component variables? Are users typically given knowledge of this underlying engine component or do they typically manipulate these values indirectly via the containing entity class member functions or some other mechanism?
  13. @Juliean Fantastic, that helps a lot. This seems to be inline with what @Servant of the Lord was getting to as well, which was to not make components too granular.
  14. Thanks for the reply. I think this: really hit the nail on the head. I'm kinda like you where I've read up on ECS systems and game engines but again this is my first time trying to implement these things into an actual project. Right now my animation system really isn't doing a whole lot lol. I know that, from what I've read, animation and graphics are usually very tightly coupled but I would still see them implemented as 'separate' systems in some code samples so that's why I'm starting out with two separate systems. It helps me reason about things better while I'm learning. Basically my animation system is just setting an index from a 'spritesheet' texture to a spritesheet component. The spritesheet comp holds the texture's current UV coordinates and has a SetUV function which set's the UV coords for whichever index is specified. In the graphics system I then just check that spritesheet component's current UVs set and renders the image found at those coords. More refactoring required but a good start for me :->
  15. Background: So I'm developing my first 2d C++ fighting game (for learning purposes) and I have a setup where I have 'components' which are really just data holders with maybe some simple utility functions such as GetComp(), AddToComp(), etc. All components get passed to component systems which are just functions which act on certain components (e.g. MovementSystem(PositionComp pos, VelocityComp vel), etc.) which are split up into their respective domains (Graphics, Animation, Physics, etc.). All components are held by 'Fighter' class which acts as the component holder that keeps everything together. Issue: The problem I'm having is I'm not sure how I decide what exactly should be made into a component vs what shouldn't. For example, for my animations I have a system which essentially takes a 'spriteComponent' and a 'animationClip' obj like so SetAnimation(spriteComponent sprite, animationClip anim). As it stands, my animationClip class is not considered a component and is not currently attached within my Fighter class, though I guess I could implement it that way. How do I decide what classes/types should be made into components? How is this typically handled in other ECS (entity component) like systems?