Vanilla Forums has been nominated for a second time in the CMS Critic "Critic's Choice" awards, and we need your vote! Read more here, and then do the thing (please).
Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it, follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!

Game Development Omni-thread [Unity, XNA, UDK, etc]

24567100

Posts

  • NamrokNamrok Herndon, VARegistered User regular
    edited April 2010
    GnomeTank, I think you have a very specific way you like to code that works for you.

    But this is devolving into a "No, MY coding practices are the best" type argument.

    XNA and C# is a poor fit for you. Thats ok. You asked how things can be done in XNA, you've been told, and you've said quite profoundly "BUT I DON'T WANNA!".

    Moving on, I'm hoping to steal away some time this weekend to work on my game stuff. Lazy sunday hopefully.

  • gjaustingjaustin Registered User regular
    edited April 2010
    GnomeTank wrote: »
    gjaustin wrote: »
    GnomeTank wrote: »
    If you're in a situation where you're writing "vastly different implementations" per-object, you may be designing something wrong to begin with, or your original base was not general enough.

    I don't have the code here, so I can't post the header for any of my components, but basically if you look at Scriptable it contains all the pieces you need to wire up scripting for an object: storage for the script context, script context initialization, generic methods to call script functions, generic ways to load a script in to the context. These are operations that should, if things are designed correctly, be absolutely 100% the same for everyone object. If you do need to overload the default behavior, everything is marked virtual (except getters and setters, makes them too slow).

    The inheriting component object can then use those generic facilities to wire up scripting in an object specific way.

    I think in all my years of programming I've run into a situation where I needed multiple inheritance once. And it only came up because I had to create an extension to an existing class hierarchy that I couldn't change.

    It sounds like you're designing much more monolithic classes than would work in C# and XNA. My design is split into more interchangeable parts.

    I make heavy use of utility classes and methods. So while your class might look like:
    public class Entity : Object, Scriptable
    {
       public void RunScript()
      {
          this.ExecuteScriptAction();
      }
    }
    

    Mine looks like:
    public class Entity : Object implements IScriptable
    {
       public void RunScript()
       {
           this.ScriptAction.Execute();
       }
    }
    


    So they work fundamentally the same way, but mine is less tied to a specific implementation of scripting, since I could always just instantiate a different class.

    Edit: To be fair, yours has the advantage of saving a few lines of code in the Deserialization method.

    The problem here is that you have to re-implement IScriptable every time you want to create a scriptable object. You don't get any advantages of having the most mundane, completely generic, parts of scripting be drop-and-drop mixable.

    I have several places this makes a lot of sense to me. For instance, my Actor class is Scriptable, so is my CombatEngine class. They share no other similarities, except they both need a place to store a scripting context, and both need a way to call methods inside that context. My Static class and my Actor class are both Scriptable, and both game Objects, but one is a AnimatedRenderable, the other is a MeshRenderable...because static object's don't need to render an animated mesh. Yes, I could have had an IAnimatedRenderable and an IMeshRenderable, but again, I would be stuck reimplementing the same interface twice on two separate objects.

    I could have an IScriptable interface, but then Actor and CombatEngine would both need to implement IScriptable (or would need to aggregate an object that does, which is by no means any cleaner). I need to do neither, I just need to publically inherit Scriptable. The illusion that using interface implementation and aggregation gives you the magic bullet so that you can easily change scripting engines is just that, an illusion. It's no easier, or more difficult, than for me to simply change the Scriptable base class implementation.

    Object composites are that edge case where multiple inheritance clearly outshines interface implementation and aggregation. This is why there are several C# engines out there trying to provide object composites that don't look horrible in the framework of interface implementation and aggregation.

    e: Also, by the very definition of my system, my classes are not monolithic even in the slightest. Scriptable does scripting, that's it. It does it very well, and in a completely sub-class agnostic way. I can hang Scriptable off of anything, not just game objects sub-classing from Object. And I do, given by my CombatEngine v. Actor example. Both are Scriptable, but share zero similarities beyond that. That's is the exact definition of extensible and reusable (aka not monolithic).

    Object -> Scriptable -> CombatEngine
    Object -> Scriptable -> Renderable -> AnimatedRenderable -> Actor
    Object -> Scriptable -> Rendarable -> MeshRenderable -> Actor

    Why aren't all your meshes inheriting from Scriptable? Alternatively, if they need a Script Context, why don't you have a ScriptContext object?

    And the definition of a monolithic class I've always heard is a class that tries to do too much on its own. You're pasting all these objects together into something enormous, when you could be creating other objects to handle their own tasks.

    Your belief is not required
  • SeolSeol Registered User regular
    edited April 2010
    GnomeTank wrote: »
    Seol wrote: »
    You keep talking about object composites. So... why not use composition, instead of inheritance? It sounds like you're creating things like scripting contexts as standalone conceptual entities: so make them member objects, not base classes?

    edit: Yes, this is a bit more of a pain in the neck to implement: you need a scripting context getter, and interfaces to support accessing contexts, and it makes it more awkward if you want to access two conceptual entities at the same time. On the other hand, it protects you from the reasons why multiple inheritance was considered dangerous in the first place: if you do something in ScriptContext which conflicts with AnimationContext - give two fields the same name, for example - then that's not a problem, because they're entirely separate entities.

    You answered your own question in your edit. If I was doing this in C#, I would have no choice but to do what you suggest (which is composition through aggregation, btw). The "danger" of multiple inheritance is not lessened in C#. I can still have two interface that have a conflicting method, or property, signatures. I just have to implement one of the interfaces explicitly (IInterface.ConflictingMethod), rather than implicitly.
    That's if you have two separate interfaces with methods with the same signature that are intended to invoke different behaviour, and that's only if you specifically go out of your way to make it happen.

    I'm relatively new to C#, from a Java background, and I'm unconvinced about the usefulness of that device, and at my current level of experience with the language I'd agree that explicit interface implementation seems unnecessary and a crutch for poor interface design: I'll freely admit I may be missing contexts where it's particularly useful.

    And yes, by properly designing the code from day 1 you can avoid the dangers of multiple inheritance: it's much more of an issue in larger projects where different people are maintaining and extending other people's classes, where work on one class could break other classes that extend it due to unexpected interactions. Y'know, the sort of projects C# was designed for.

    So the argument against composition by aggregation is: it's a little more verbose to implement, right?

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Seol wrote: »

    So the argument against composition by aggregation is: it's a little more verbose to implement, right?

    That's the main argument yes, it can be way, way more verbose to implement as your interfaces grow in size. It can also lead to a lot of cut-and-paste boiler plate code, rather than sticking very cleanly to DRY.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    gjaustin wrote: »

    Object -> Scriptable -> CombatEngine
    Object -> Scriptable -> Renderable -> AnimatedRenderable -> Actor
    Object -> Scriptable -> Rendarable -> MeshRenderable -> Actor

    Why aren't all your meshes inheriting from Scriptable? Alternatively, if they need a Script Context, why don't you have a ScriptContext object?

    And the definition of a monolithic class I've always heard is a class that tries to do too much on its own. You're pasting all these objects together into something enormous, when you could be creating other objects to handle their own tasks.

    Because CombatEngine doesn't need to be an Object, it needs to be a Scriptable. Yes, I could create one gigantic single inheritance tree to get what I wanted. It would be a mess. Not every Renderable needs to be Scriptable, not every Scriptable needs to be an Object. Not every Object needs to be Scriptable. So I would end up with wacky base classes like "ScriptableRenderableObject", just to enforce the proper inheritance chain.

    And your definition of a monolithic class is very wrong. A monolithic class would be if I tried to implement the ideas behind Scriptable, MeshRenderable and Object as one gigantic class. A monolithic class is not one that is composed of smaller, non monolithic components, to create one larger logic object. That's good OO design. Classes should do one thing, and do them very well. That doesn't preclude that class from needing do the exact things it's composite bases provide. If I tried to rig up Actor, CombatEngine and Trigger all to be Scriptable, without a common base (or at the very least an aggregate interface implementation), that would be monolithic. Having those three classes all inherit Scriptable, which does it for them, is not monolithic. It's extensible, reusable and follows DRY.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • DelzhandDelzhand motivated battle programmerRegistered User regular
    edited April 2010
    I admit most of this goes right over my head. The most complex hierarchy I've ever had was Object>Entity>PhysicsObject>Actor>Player.

    Hell, in my SRPG, it's even simpler. Unit is extended by UnitPC and UnitAI.

    jk0Btsj.png
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Namrok wrote: »
    GnomeTank, I think you have a very specific way you like to code that works for you.

    But this is devolving into a "No, MY coding practices are the best" type argument.

    XNA and C# is a poor fit for you. Thats ok. You asked how things can be done in XNA, you've been told, and you've said quite profoundly "BUT I DON'T WANNA!".

    Moving on, I'm hoping to steal away some time this weekend to work on my game stuff. Lazy sunday hopefully.

    Uhh, actually, it's just an interesting discussion about game engine design, in a thread that prior to me asking the question had almost no movement or discussion. I know how to achieve what I am doing in C++ reasonably well in C#, I write C# for a living after all, and have been using it since .NET 1.0 beta.

    I was simply starting a discussion about game engine design, and how the language your using (in my case C++, yours C#) changes (sometimes fundamentally) how you design your engine.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Delzhand wrote: »
    I admit most of this goes right over my head. The most complex hierarchy I've ever had was Object>Entity>PhysicsObject>Actor>Player.

    Hell, in my SRPG, it's even simpler. Unit is extended by UnitPC and UnitAI.

    Hehe, it's okay man. Frankly, my engine is probably a tad over designed in places, but god damn if the code doesn't look gorgeous. And that's what matters, right? RIGHT GUYS?!

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • SeolSeol Registered User regular
    edited April 2010
    GnomeTank wrote: »
    That's the main argument yes, it can be way, way more verbose to implement as your interfaces grow in size. It can also lead to a lot of cut-and-paste boiler plate code, rather than sticking very cleanly to DRY.
    Well, that depends on how you implement it. If you have the IScriptable interface as having all the scripting methods, that could get very verbose. If you have the IScriptable interface as having nothing but a getScriptContext() method, which returns the script context which you then act on, then each interface only needs one method.

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Seol wrote: »
    Well, that depends on how you implement it. If you have the IScriptable interface as having all the scripting methods, that could get very verbose. If you have the IScriptable interface as having nothing but a getScriptContext() method, which returns the script context which you then act on, then each interface only needs one method.

    Which leads to problem #2: Repeating a lot of boiler plate code cut and paste style, because there will end up being a common set of operations you can distill out of those disparate IScriptable implementations.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • DelzhandDelzhand motivated battle programmerRegistered User regular
    edited April 2010
    What kind of game are you making, GT?
    GnomeTank wrote: »
    Uhh, actually, it's just an interesting discussion about game engine design, in a thread that prior to me asking the question had almost no movement or discussion.

    It's less than a day old, mang. The last XNA thread only managed 100 pages in a year+ of discussion. It tends to be a long-haul thread.

    jk0Btsj.png
  • SeolSeol Registered User regular
    edited April 2010
    GnomeTank wrote: »
    Seol wrote: »
    Well, that depends on how you implement it. If you have the IScriptable interface as having all the scripting methods, that could get very verbose. If you have the IScriptable interface as having nothing but a getScriptContext() method, which returns the script context which you then act on, then each interface only needs one method.
    Which leads to problem #2: Repeating a lot of boiler plate code cut and paste style, because there will end up being a common set of operations you can distill out of those disparate IScriptable implementations.
    Yes, but it's all basic getter code. DRY is important for two reasons: firstly, repeating yourself is often wasted effort, but FAR more importantly, if you have a critical piece of code duplicated in different places, you end up with a maintenance nightmare. Fixing a bug in it once won't fix it everywhere: so, don't copy/paste logic.

    getScriptContext() doesn't contain any logic. It just returns a field. Which means, really, only argument 1 - that it's a bit more work - applies, and in a case where you don't have multiple inheritance at your disposal, you're looking at approaches which will require more effort, and this isn't much more effort for a very similar effect.

    Hell, I'd say this is a case of DRY. Maybe not quite so direct as multiple inheritance, but the sort of situations you're describing sound to me like a natural fit for composition by aggregation.

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Delzhand wrote: »
    What kind of game are you making, GT?
    GnomeTank wrote: »
    Uhh, actually, it's just an interesting discussion about game engine design, in a thread that prior to me asking the question had almost no movement or discussion.

    It's less than a day old, mang. The last XNA thread only managed 100 pages in a year+ of discussion. It tends to be a long-haul thread.

    Not dissin the thread mang, just pointing out, I was just starting a discussion, and it's gotten the thread hoppin', I might add.

    Anyway, I am making an 'evil' comedy action RPG. Basically everything is reversed. You live in the evil cave, the evil wizards are your beer buddies, and it's your job to go slaughter the inhabitants of every town, temple and castle you find. I'm working the loot angle in to the story, where the constant pursuit of "phat lewt" actually has a story reason, inside your evil brotherhood.

    The classes available will be an offering of evil: Demon Lord, Warlock, Succubus and Despotic Warlord.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    Seol wrote: »
    Hell, I'd say this is a case of DRY. Maybe not quite so direct as multiple inheritance, but the sort of situations you're describing sound to me like a natural fit for composition by aggregation.

    If the tools you are working with have no multiple inheritance available, then absolutely, composition by aggregation is exactly how you would achieve what I am doing. It would be the only (smart) way to do it.

    In the presence of multiple inheritance, that obviously becomes the preferred way to achieve object compositing. Why would I do composition by aggregation in C++ when I can do the less verbose composition by inheritance? :)

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • gjaustingjaustin Registered User regular
    edited April 2010
    GnomeTank wrote: »
    gjaustin wrote: »

    Object -> Scriptable -> CombatEngine
    Object -> Scriptable -> Renderable -> AnimatedRenderable -> Actor
    Object -> Scriptable -> Rendarable -> MeshRenderable -> Actor

    Why aren't all your meshes inheriting from Scriptable? Alternatively, if they need a Script Context, why don't you have a ScriptContext object?

    And the definition of a monolithic class I've always heard is a class that tries to do too much on its own. You're pasting all these objects together into something enormous, when you could be creating other objects to handle their own tasks.

    Because CombatEngine doesn't need to be an Object, it needs to be a Scriptable. Yes, I could create one gigantic single inheritance tree to get what I wanted. It would be a mess. Not every Renderable needs to be Scriptable, not every Scriptable needs to be an Object. Not every Object needs to be Scriptable. So I would end up with wacky base classes like "ScriptableRenderableObject", just to enforce the proper inheritance chain.

    And your definition of a monolithic class is very wrong. A monolithic class would be if I tried to implement the ideas behind Scriptable, MeshRenderable and Object as one gigantic class. A monolithic class is not one that is composed of smaller, non monolithic components, to create one larger logic object. That's good OO design. Classes should do one thing, and do them very well. That doesn't preclude that class from needing do the exact things it's composite bases provide. If I tried to rig up Actor, CombatEngine and Trigger all to be Scriptable, without a common base (or at the very least an aggregate interface implementation), that would be monolithic. Having those three classes all inherit Scriptable, which does it for them, is not monolithic. It's extensible, reusable and follows DRY.

    Clearly we're using different words here to mean different things, because a CombatEngine is by definition an Object.

    Since we're not getting anywhere, I'll just leave it with this: I've had to use all of one interface in my engine design: ICollide. Each of my classes has a couple lines of code to try and decide what shape it is. If I implemented Collider, as you seem to be suggesting, I'd still need that code.

    My class is what my object is, the interface is what is done to the class.

    Your belief is not required
  • tastydonutstastydonuts Registered User regular
    edited April 2010
    So I just the whole not-wanting-to-deter-other-readers-who-aren't-interested-in-deep-coding-or-convos-related-to-deep-coding thing just went out the window, eh? ;p
    Izzimach wrote: »
    I imagine I will repeat this cycle again a few more times before I get to the point of putting a game out there, or just go "screw it" and charge forward, horrible animations and all.

    Just go "screw it" dude. Have you seen some of the available games? Some of them are terrible, terrible abominations, even for 80 points. Plus, rough animation and graphics isn't a death sentence; games like Johnny Platform's Biscuit Romp are still pretty good even if they look like they're done with MS Paint.

    In the end, that's what will happen. but the artsy-side of me is also my own worse critic, so ideally it may look rather functional. Just getting the niggling details out of the way while learning how to use a product at the same time (I bought 3ds, moved from blender) is what makes it fun and exciting … in its own hair-pulling-out way.

    and dude, MS Paint was/is a pretty good sprite editor if that's all you got. plenty of my time was spent in 800x zoom with grid mode on years ago before I just wrote my own 256 color sprite editor, lol. ;p

    edit: I thought JPBR's graphics were nice and fit the style of the game too.

    “I don't know the key to success, but the key to failure is trying to please everyone.”
    ― Bill Cosby
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    gjaustin wrote: »
    GnomeTank wrote: »
    gjaustin wrote: »

    Object -> Scriptable -> CombatEngine
    Object -> Scriptable -> Renderable -> AnimatedRenderable -> Actor
    Object -> Scriptable -> Rendarable -> MeshRenderable -> Actor

    Why aren't all your meshes inheriting from Scriptable? Alternatively, if they need a Script Context, why don't you have a ScriptContext object?

    And the definition of a monolithic class I've always heard is a class that tries to do too much on its own. You're pasting all these objects together into something enormous, when you could be creating other objects to handle their own tasks.

    Because CombatEngine doesn't need to be an Object, it needs to be a Scriptable. Yes, I could create one gigantic single inheritance tree to get what I wanted. It would be a mess. Not every Renderable needs to be Scriptable, not every Scriptable needs to be an Object. Not every Object needs to be Scriptable. So I would end up with wacky base classes like "ScriptableRenderableObject", just to enforce the proper inheritance chain.

    And your definition of a monolithic class is very wrong. A monolithic class would be if I tried to implement the ideas behind Scriptable, MeshRenderable and Object as one gigantic class. A monolithic class is not one that is composed of smaller, non monolithic components, to create one larger logic object. That's good OO design. Classes should do one thing, and do them very well. That doesn't preclude that class from needing do the exact things it's composite bases provide. If I tried to rig up Actor, CombatEngine and Trigger all to be Scriptable, without a common base (or at the very least an aggregate interface implementation), that would be monolithic. Having those three classes all inherit Scriptable, which does it for them, is not monolithic. It's extensible, reusable and follows DRY.

    Clearly we're using different words here to mean different things, because a CombatEngine is by definition an Object.

    Since we're not getting anywhere, I'll just leave it with this: I've had to use all of one interface in my engine design: ICollide. Each of my classes has a couple lines of code to try and decide what shape it is. If I implemented Collider, as you seem to be suggesting, I'd still need that code.

    My class is what my object is, the interface is what is done to the class.

    I think you misunderstand. C++ does not have a base Object class like C# does. Classes do not automatically inherit from anything in C++. A class in C++ with no inheritance, simply has no inheritance. It's identity is itself.

    Object is an actual C++ class in my engine that represents a game world object, at the highest level. It could be a sword, a potion, a player, an NPC. Just something that lives in the game world. In my case, CombatEngine does not need to live in the game world, but does need to be scriptable. Does that make any more sense?

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • RainbowDespairRainbowDespair Registered User regular
    edited April 2010
    Whew, I just finished adding and testing the obstruction & animation matrixes to all of the tilemaps in Breath of Death VII (to tell the program which tiles are walls & which tiles are animated). Man, that took a lot longer than I expected. Now all I have to do is play through the game, adjusting the monster stats as I go. Once that's done, the game'll be ready to put into playtesting later tonight.

  • SeolSeol Registered User regular
    edited April 2010
    gjaustin wrote: »
    Since we're not getting anywhere, I'll just leave it with this: I've had to use all of one interface in my engine design: ICollide. Each of my classes has a couple lines of code to try and decide what shape it is. If I implemented Collider, as you seem to be suggesting, I'd still need that code.

    My class is what my object is, the interface is what is done to the class.
    Really? That surprises me. Does everything inherit from some base class which implements everything to do with updating and rendering? No IDrawable? IPhysics?

    I agree with the distinction of: the class is what it is, interfaces describe what it does, and that's an important aspect of polymorphism for games. But shouldn't the stuff in the game do.... quite a lot?

  • tastydonutstastydonuts Registered User regular
    edited April 2010
    Whew, I just finished adding and testing the obstruction & animation matrixes to all of the tilemaps in Breath of Death VII (to tell the program which tiles are walls & which tiles are animated). Man, that took a lot longer than I expected. Now all I have to do is play through the game, adjusting the monster stats as I go. Once that's done, the game'll be ready to put into playtesting later tonight.

    I'll have to try and pull myself away from grinding achievements out to give it a playtest! hehe.

    “I don't know the key to success, but the key to failure is trying to please everyone.”
    ― Bill Cosby
  • SeolSeol Registered User regular
    edited April 2010
    Whew, I just finished adding and testing the obstruction & animation matrixes to all of the tilemaps in Breath of Death VII (to tell the program which tiles are walls & which tiles are animated). Man, that took a lot longer than I expected. Now all I have to do is play through the game, adjusting the monster stats as I go. Once that's done, the game'll be ready to put into playtesting later tonight.
    Interesting approach - you separate the graphics and behaviour for tilemaps, and have separate approaches for implementing each? My instinct would always be to create a tilemap format which had tiles which encapsulated both graphics and behaviour - it's got a number of advantages in the long run with the downside of work up front. Any reason for doing it that way, or was it a case of unnecessary effort?

    Also: good luck with the testing :D

  • DelzhandDelzhand motivated battle programmerRegistered User regular
    edited April 2010
    GnomeTank wrote: »
    Anyway, I am making an 'evil' comedy action RPG. Basically everything is reversed. You live in the evil cave, the evil wizards are your beer buddies, and it's your job to go slaughter the inhabitants of every town, temple and castle you find. I'm working the loot angle in to the story, where the constant pursuit of "phat lewt" actually has a story reason, inside your evil brotherhood.

    The classes available will be an offering of evil: Demon Lord, Warlock, Succubus and Despotic Warlord.

    Now that's what I'm talking about. Proactive evil. 8-)

    jk0Btsj.png
  • gjaustingjaustin Registered User regular
    edited April 2010
    Seol wrote: »
    gjaustin wrote: »
    Since we're not getting anywhere, I'll just leave it with this: I've had to use all of one interface in my engine design: ICollide. Each of my classes has a couple lines of code to try and decide what shape it is. If I implemented Collider, as you seem to be suggesting, I'd still need that code.

    My class is what my object is, the interface is what is done to the class.
    Really? That surprises me. Does everything inherit from some base class which implements everything to do with updating and rendering? No IDrawable? IPhysics?

    I agree with the distinction of: the class is what it is, interfaces describe what it does, and that's an important aspect of polymorphism for games. But shouldn't the stuff in the game do.... quite a lot?

    I use GameComponent and DrawableGameComponent, so I don't need to worry about IDrawable. And ICollide basically is my IPhysics.

    There is one other place where I could potentially use an interface (ILoadFromXml), but since I have to use reflection anyway to get my class, I just went ahead and used it to grab my method too.


    GnomeTank wrote: »
    I think you misunderstand. C++ does not have a base Object class like C# does. Classes do not automatically inherit from anything in C++. A class in C++ with no inheritance, simply has no inheritance. It's identity is itself.

    Object is an actual C++ class in my engine that represents a game world object, at the highest level. It could be a sword, a potion, a player, an NPC. Just something that lives in the game world. In my case, CombatEngine does not need to live in the game world, but does need to be scriptable. Does that make any more sense?

    Yeah, I knew that about C++. I guess I assumed that since you named it Object, you wanted to create something that filled that "gap". I probably would have called it Entity myself.

    Your belief is not required
  • RainbowDespairRainbowDespair Registered User regular
    edited April 2010
    Seol wrote: »
    Whew, I just finished adding and testing the obstruction & animation matrixes to all of the tilemaps in Breath of Death VII (to tell the program which tiles are walls & which tiles are animated). Man, that took a lot longer than I expected. Now all I have to do is play through the game, adjusting the monster stats as I go. Once that's done, the game'll be ready to put into playtesting later tonight.
    Interesting approach - you separate the graphics and behaviour for tilemaps, and have separate approaches for implementing each? My instinct would always be to create a tilemap format which had tiles which encapsulated both graphics and behaviour - it's got a number of advantages in the long run with the downside of work up front. Any reason for doing it that way, or was it a case of unnecessary effort?

    It was mostly a matter of that being the first method I came up with that made sense to me. I have an array that indicates which tilemap to use for each map in the game. For each tilemap, I have 2 arrays - one that indicates obstruction level (0 = move through, 1 = wall) & one that indicates whether or not to animate that tile. Made sense in my head to separate them since one deals with the internal workings of the game and the other deals with what's displayed, but I'm sure there are more elegant ways to do it. But hey, it works and that part is done so I'm pleased.

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    gjaustin wrote: »

    Yeah, I knew that about C++. I guess I assumed that since you named it Object, you wanted to create something that filled that "gap". I probably would have called it Entity myself.

    Entity is a good name, but the reason I didn't use it as that OGRE has the concept of Entities (as the class Entity) in the graphical sense, and I didn't want to confuse myself. My other choice (and the one I may still go to) was Thing, which I found sort of on the comical side, which works for an engine crafted to make a comical ARPG. Because, you know, everything is a thing.

    My Object does basically the same thing as C#'s Object (in concept, not actual functionality...it doesn't provide ToString, GetHashCode, etc, hehe), but not for the entire object model, which doesn't need it. Only (as you say) entities in the actual game world need that particular chunk of base functionality.

    e: In fact, I just refactored it to Thing. Thanks Visual Assist, for offering me C++ refactoring tools that Visual Studio kindly left out.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • gjaustingjaustin Registered User regular
    edited April 2010
    No GetHashCode?! How do you C++ programmers do it?

    On the bright side our little disagreement actually got me to open up my XNA project and get some ideas.

    Your belief is not required
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    We don't need GetHashCode when we have std::hash :P

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • AlejandroDaJAlejandroDaJ Registered User regular
    edited April 2010
    This thread's more text heavy than my entire lineup of QBasic games.

    Let's fix that.

    http://www.youtube.com/watch?v=5_yYL54qOTE

    Work continues apace on Around The World, the game that Delzhand left out of the OP, god what a meanie! Anywho, to entice buyers to pick up my humble geography quiz game on the cheap (thinking $1), I've added a Screen Saver/unlockable wallpaper system as encouragement. None of the unlocks are unreasonably hard, but that's okay since some of these images are just wonderful. I snapped pretty much all of the U.S. and Canada photos, but seeing as how North America != the world, I raided the Public Domain stuff on Wikipedia and found some real winners.

    FYI the quick flipping through the images in the video isn't the actual automated Screen Saver, it's just me flipping through them quickly on the DPad.


    Question: My 2D skills are really, really limited. I need to fill in the cracks of the artwork, and my ingame menus are notably lacking titles. Do any of you guys recommend any articles/tutorials describing how to make snazzy titles and bringing some sort of aesthetic idea to life? Rather than hitting the Text tool in Photoshop and typing "Hurf durf durf I maek title nao"?

  • DelzhandDelzhand motivated battle programmerRegistered User regular
    edited April 2010
    the game that Delzhand left out of the OP, god what a meanie!

    I think you need to check again
    Spoiler:

    jk0Btsj.png
  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    So this is what I am thinking for the class break down (only Demon Lord has any code put to it yet):

    Demon Lord: Fisted (and tailed) melee, demonic buffs/debuffs, strong pbae
    Succubus: Root, stun, mind control, whip (decently long range) attacks
    Warlock: Standard dark caster + self heals (life drain)
    Despotic Warlord: Heavy armor melee + summonable pets (serfs) with varying uses

    I guess I should add that there is an element of a 4x game here as well, as the towns you destroy and take over become sources of income and resources, which can be used to forge epic items , buy various realm wide upgrades, and upgrade the towns in various ways. The game engine will generate attacks against your town by the forces of light, and if your towns built in defenses aren't strong enough to repel it (they can be upgraded), you have to go back and slaughter the good guys.

    The actual combat gameplay is pure APRG click, click, click. But the overworld map gameplay is 4X.

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • RainbowDespairRainbowDespair Registered User regular
    edited April 2010
    It's done! It took drastically longer than I expected, but I have now officially gone through an entire game of Breath of Death VII from start to finish (correcting bugs and balancing skills and enemies along the way of course). I'm currently uploading it to the playtesting forum on xna.creators.com so it should be available for playtesting later this morning.

  • HandkorHandkor Registered User regular
    edited April 2010
    It's done! It took drastically longer than I expected, but I have now officially gone through an entire game of Breath of Death VII from start to finish (correcting bugs and balancing skills and enemies along the way of course). I'm currently uploading it to the playtesting forum on xna.creators.com so it should be available for playtesting later this morning.

    Great, now another reason to procrastinate my own game dev :p

    Can't wait to playtest this.

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    It's done! It took drastically longer than I expected, but I have now officially gone through an entire game of Breath of Death VII from start to finish (correcting bugs and balancing skills and enemies along the way of course). I'm currently uploading it to the playtesting forum on xna.creators.com so it should be available for playtesting later this morning.

    Very cool. You have to be a paid member of the club to get things from the playtesting forum, right?

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • RainbowDespairRainbowDespair Registered User regular
    edited April 2010
    GnomeTank wrote: »
    It's done! It took drastically longer than I expected, but I have now officially gone through an entire game of Breath of Death VII from start to finish (correcting bugs and balancing skills and enemies along the way of course). I'm currently uploading it to the playtesting forum on xna.creators.com so it should be available for playtesting later this morning.

    Very cool. You have to be a paid member of the club to get things from the playtesting forum, right?

    Yeah, you need to have paid for a Creator's Club membership.

  • GnomeTankGnomeTank Registered User regular
    edited April 2010
    GnomeTank wrote: »
    It's done! It took drastically longer than I expected, but I have now officially gone through an entire game of Breath of Death VII from start to finish (correcting bugs and balancing skills and enemies along the way of course). I'm currently uploading it to the playtesting forum on xna.creators.com so it should be available for playtesting later this morning.

    Very cool. You have to be a paid member of the club to get things from the playtesting forum, right?

    Yeah, you need to have paid for a Creator's Club membership.

    Welp, guess I get to wait until it hits XBLA Indie and I'll just buy it :)

    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh
  • fragglefartfragglefart Registered User regular
    edited April 2010
    Yeah, so bought the second I see it. Well done RD, finishing a serious project is hard.

    fragglefart.jpg
  • AlejandroDaJAlejandroDaJ Registered User regular
    edited April 2010
    Delzhand wrote: »
    the game that Delzhand left out of the OP, god what a meanie!

    I think you need to check again
    Spoiler:

    Ha, thanks dude!

    Rainbow, I'm buying the hell out of that game the moment it comes out.

  • tastydonutstastydonuts Registered User regular
    edited April 2010
    Somewhat embarrassingly random question here... I know the maths to do it, but is there a built-in function for finding the location of a point along a circle?

    “I don't know the key to success, but the key to failure is trying to please everyone.”
    ― Bill Cosby
  • DelzhandDelzhand motivated battle programmerRegistered User regular
    edited April 2010
    Vector2 p = new Vector2();
    p.x = Math.Cos(angleOfDesiredPoint) * radiusOfCircle;
    p.y = Math.Sin(angleofDesiredPoint) * radiusOfCircle;
    

    Edit: Oh, duh. You asked if there was an automatic way to do it.

    jk0Btsj.png
  • tastydonutstastydonuts Registered User regular
    edited April 2010
    Delzhand wrote: »
    Vector2 p = new Vector2();
    p.x = Math.Cos(angleOfDesiredPoint) * radiusOfCircle;
    p.y = Math.Sin(angleofDesiredPoint) * radiusOfCircle;
    

    Edit: Oh, duh. You asked if there was an automatic way to do it.

    lol, yea. ;p

    just tossing an idea ball around in my head and I wanted a cleaner way to place objects along the circle. as it is when the parent object is drawn it would, on paper at least, go through its child objects and rotate/place them along the circle as they're drawn. I wanted to clean up how it tells its children where they should be.

    edit: what made that an issue was my wondering if the parent should rotate along its axis too, which would add to the angle of is location and relative rotation.

    BUT! from a gameplay perspective I'd imagine that would be very busy for a player to follow. Yes? No?

    “I don't know the key to success, but the key to failure is trying to please everyone.”
    ― Bill Cosby
This discussion has been closed.