Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Zsolt Sandor
    @sz332
    @goqp how can I message you? I am looking forward joining the new chat.
    Victor Noël
    @victornoel
    @goqp just advertise it here, no?
    Stian Soiland-Reyes
    @stain
    @goqp looking forward to invite
    Stian Soiland-Reyes
    @stain
    will there be money for opinions? :)
    Josh Schwartzberg
    @dotjosh
    I just read both books -- anyone have any non-hello-world github repo examples of fully adopting the oop practices mentioned?
    Victor Noël
    @victornoel
    @dotjosh check cactoos and other projects by yegor256 on github
    goqp
    @goqp
    email me at goqp@outlook.com
    i added you guys to a list of people I am inviting personally
    @dotjosh Check out my github for an original OOP approach to Yegor's Hangman. Its beta. I will commit a reformatted version a little later.
    If you want Yegor style then I think one or two of the submissions on his challenge site fit pretty well, you can browse.
    Here is my approach: https://github.com/goqp/Hangman
    goqp
    @goqp
    Here are other people's submittals attempting the Yegor (EO) style: https://github.com/yegor256/hangman
    yohanmishkin
    @yohanmishkin
    @goqp could I bother you to add me to the list too?
    goqp
    @goqp
    I did : )
    I will msg you all when Ive got it up
    anyone around?
    goqp
    @goqp
    alright, anyone who wants to continue with research and experimentation, eventually production, is invited to come to my new group!
    Zsolt Sandor
    @sz332
    @goqp wrote you a private message on gitter,ű
    Joshua Light
    @JoshuaLight

    Hi guys!

    Need some help from OOP mind people. ))

    What if I have something like Item, which can be Weapon, Armor or whatever, and I want to render it on the screen.

    Method Direct3D.Render( Item item ) will render it through image path and some APIs, but Console.Render( Item item ) will render it using just type and name, for example, "Weapon: Frostmourne".

    In such approach there is no way to remove type casting or some kind of getters because every rendering method is tightly coupled with render-specific details.

    There is no way to generalize RENDERING (?).
    There is no way to use inversion of control (what I really want), because Item cannot depend on concrete rendering implementation.
    There is no way to create something like Direct3DItem or ConsoleWeapon, because if it's decorator of Item, it has access to only its public members, but wait, we have only behaviour here...

    Generally speaking, the main problem here is that logic of objects representation is conceptually needs to ASK for data (through cast or getters, whatever). But, for example, Yegor's printers (I like them, actually) are based on idea of TELLING object to print itself (or render itself).

    How this can be possible, if knowledge of object representation exists only in representation system and cannot be shared with object domain?
    Does anyone tried to generalize rendering through some kind of printers?

    Laurent V.
    @monsieurluge
    "Print itself" means, in my opinion, to know how to give the informations to the receiver. In your case, the Item knows how to give to the renderer the mesh, textures, etc
    Game send the [render(Renderer)] message to Item, then Item -> [mesh(data)] -> Renderer, and so on.
    I'm probably wrong but it's what i'll try if i need to do that kind of stuff
    Joshua Light
    @JoshuaLight

    I agree and really like such approach.

    But the problem here is the knowledge about "mesh, textures, etc". Item cannot have that knowledge. Why?

    Well, the easiest answer is just because there is a LOT of such knowledge. Item will blow. Sometimes I can't even access rendering library from domain model (physically).
    The other one is a metaphor of painting: I can represent every object in the world in a tremendous possible ways, and this object doesn't even know about that. Its behaviour remains unchanged.

    Laurent V.
    @monsieurluge
    The Item object is not the same as the RenderableItem. The first exposes the right behaviour to be wear, add bonuses to the player, etc, and the second knows only how to interract with the renderer
    The knowledge must be cut in parts
    Joshua Light
    @JoshuaLight
    But what RenderableItem will be kind of? Is it a decorator over an Item? If RenderableItem has access to data, that allows it to render an Item, then every other object can access the same data, so we already violated some principles.
    Laurent V.
    @monsieurluge
    For me its two different kind of objects, no decorator here
    The data of an Item (mesh, textures, etc) is not the same as the data used to give bonuses to the actor, the fire rate, etc
    Joshua Light
    @JoshuaLight
    Well, again, if RenderableItem can render an Item, then Item should have getters to allow that.
    Laurent V.
    @monsieurluge
    Why must the Item do know about rendering informations ?
    Maybe "RenderableItem" is not the right name for that object. It's a "renderable" something
    And an Item (Weapon, Shield) doesn't care about rendering.
    There is probably a high level object wich is composed with IRenderable and IItem objects
    Joshua Light
    @JoshuaLight

    So this is a question. I can use getters like getName(), getType(), getDamage() and render everything easily. This is the approach of most applications. But what if I want to use inversion of control and OOP? What if I want to tell object something like "Hey, render yourself to that canvas"?

    I think this is impossible, but maybe guys here have ideas or solutions.

    Laurent V.
    @monsieurluge
    Managing the side effects (here, in a canvas or through the rendering engine) is one of the hardest thing to do using a proper OO design
    Getting information from an object (Weapon.damage() for example) is not a problem as long as this information is not used to make decisions.
    Zsolt Sandor
    @sz332
    @JoshuaLight come to slack, write an email to goqp@outlook.com
    @monsieurluge the same
    Joshua Light
    @JoshuaLight
    +
    Silas Reinagel
    @SilasReinagel
    @JoshuaLight So, you can do pure OO with game design, and it works for simple games, but it doesn't work if you have to model physics.
    You can have objects render themselves to the SpritesBatch or render themselves into the world. That's easy
    Silas Reinagel
    @SilasReinagel
    But for physics based systems, in order to resolve collisions and proposed motion, it's necessary to delegate that to a physics engine, who needs to interrogate the state of various physics objects
    Furthermore, in game programming, immutability is generally undesirable. This is because high-performance game engines minimize memory allocation/deallocation. They way they do this is by reusing bits of memory, and changing values/resetting
    For simple games, you can use any paradigm you wish. I think for serious game, the Entity-Component-System pattern is probably one of the most important patterns.
    ECS Systems completely separate the data from the functionality. They are oriented towards the Functional Programming paradigm.
    Joshua Light
    @JoshuaLight

    Hi!

    You can have objects render themselves to the SpritesBatch or render themselves into the world. That's easy

    Can you explain, how? I really see this only as a beautiful idea, but unimplementable in practice.

    VytasGit
    @VytasGit
    @JoshuaLight Do you need any domain info (damage, weight, etc.) for rendering? If not, it seems to me domain Weapon and presentation RenderableItem could be totally different objects. Weapon could encapsulate/hide its damage and have only methods like hit(something), and RenderableItem could have textures, etc. (and maybe just the ID of Weapon so it knows which item it represents), and have a method render(canvas).
    Joshua Light
    @JoshuaLight

    @VytasGit

    Well, this is actually really depends on... But, in my example domain, I need at least one getter with resulting enum ItemType, so that I know, whether this is Weapon or Armor. Then I need to check it's durability to know, should I use broken texture or just simple. Also, it's very common that Item has rarity, so that I can render blue frame or green or orange etc.

    So there will be always GETTERS:

    • getItemType().
    • getDurability().
    • getRareness().

    And, as you can see, they depend on representation, not vice versa. I don't know a proper way to do correct encapsulation and OO for such things. Yegor offen says "The whole design is wrong", but it's not even design, it's just simple case. By the way, games development domain is far more richer, than any other, because sometimes to implement some features you must be really close to real world.

    What I think is may be a good compromise is when Item itself declares another interface like ItemDocument or ItemCanvas, that interface must generalize rendering for Item as much as possible. Then I can implement that interface in game client library and use it for a proper rendering.

    As renderer I still depend on some DATA, but this data (behaviour) is concentrated in some specific API, which is not mixed with actual Item interface. Maybe this is a good compromise, I don't know...

    Laurent V.
    @monsieurluge
    Yep, the whole design is wrong. The Item doesn't care about its rarity, type and durability. It's ok when you are not designing your objects using the "tell don't ask" principle but in a proper OO way it's not as good as it sounds.
    What is the purpose of an Item ? What an Item do ?