• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

275 Neutral

1 Follower

About Seer

  • Rank

Personal Information

  • Interests
  1. What books, tutorials or other resources would you recommend for learning good architecture design for 2D games, where the concepts are well explained with clear implementation details and if possible where an actual game is developed using these design principles, being gradually built up in a step-by-step manner?
  2. Thank you for addressing my questions frob. However, I am still curious to know; could you successfully develop games with the scope of those I suggested above, such as Pokemon or Golden Sun or some typical GBA level 2D RPG, using sub optimal or plain bad design practices such as having objects refer to resources and having their own render function? Would it be possible? Would it be painful? I am not saying that I would want to willfully program a game poorly or advocate doing so if you have the capabilities not to, but if your skill is such that you don't know how to properly decouple rendering from game objects or implement an event bus (like me), would it be possible? At this point what I have mainly taken away from this discussion is to not allow objects to hold references to resources and instead have systems hold the resources, to not give game objects their own render function, and to set up some kind of messaging system using an event bus or observer-like pattern to keep objects decoupled from systems. If all of that is correct, then what I now need is to know how to do all of that. This means having implementation details be explained to me. If you don't want to demonstrate how such an architecture would be implemented I understand as I'm sure it would be quite a lot to go through. In that case, can you suggest any tutorials, books or other material that go through developing a quality architecture for 2D games such as the kind I am interested in? I would like to stress if I may that I am only interested in 2D, not 3D. There may be resources out there which explain and step you through implementing fine architectures for 3D games which may be applicable to 2D games, but I would like the focus to be exclusively on 2D if possible. The reason is because learning these concepts and how to implement them is difficult enough and I don't want the added complexities of 3D on top of that. I hope that's not being too demanding. Thank you.
  3. At what point is a game no longer considered small enough to be able to implement simplified patterns, such as objects referencing resources? Would games with the scope of GBA era titles such as Pokemon Emerald, Golden Sun or Dragonball Z: The Legacy of Goku 2 be considered sufficiently small enough in this regard? It is only up to the scope of games such as these that I am interested in making for now. I have no interest in making 3D games. I care about how best to handle sprite sheets, textures extracted from sprite sheets, animations made using those textures, sound effects, background music and fonts. That's basically it. I have a few questions related to these: Should a given sprite sheet containing sets of animations, such as character animations, have an accompanying data file specifying values such as X position, Y position, width, height, X offset from origin and Y offset from origin for every frame in the sheet, so that you can properly extract the frames with necessary data when loading the sprite sheet? Should sprite sheets be loaded individually? I ask because I have heard of something called an atlas which packs sets of individual sprite sheets into one big sprite sheet and supposedly it is what you should use. To be absolutely clear, if a resource manager is what loads and initially holds the various resources, should it only hold resources in separate containers of that type of resource? For example, all textures would go in a container holding only textures, all animations would go in a container holding only animations, and so on for every type of resource. Then, when a system needs the resources its domain governs, it just takes a flat container of those resources from the resource manager and works from there. With resource loading, generally what I do is load all resources at the start of the program so that they are all available and ready to be used. Only once everything has loaded does the program continue. For the scope of the kind of game I am interested in making, is this an acceptable approach? If so, at what scope, if any, does it become unacceptable or problematic? Would you recommend the observer pattern for sending messages from objects to systems? If so, would you recommend implementing it with a kind of one for all approach where every observing system acts on the same function call, such as notify(Event, Object), differing in how they respond based only on the Event Enum which is passed? This way, each systems notify() definition would be comprised of a switch over the Events which are relevant to it. Object would be passed so that any type of data that needs to be sent can be wrapped in an Object and sent that way. Object could be replaced by Data, passing derived Data types instead I think. If not that then would you recommend using a set of disparate Listener interfaces instead, where the type of Listener can be different with more pertinent, sculpted function names and signatures for the relevant system. I have not used this type of observer pattern before as I have never been able to get my head around it being so used to doing it the way I described above, so if this is how you would recommend implementing the observer pattern would you mind explaining how? On the issue of ordering objects for rendering, I can see how a dedicated Renderer system would be good because it can take care of rendering the objects in a certain order as specified by whatever value or values are meaningful to you. For example, in 2D games where sprites don't take up an entire tile for themselves and are able to stand behind one another, you would probably want to order the objects by their Y position value so that those who are "above" are rendered before those who are "below" and appear behind those below them should they enter the same space. Even in this case however, the Renderer, once finished ordering the objects, can still simply render them by doing something like: for(GameObject gameObject : gameObjects) { gameObject.render(...); } In this case the Renderer has properly ordered all the objects and all it then does is tell them to render themselves. Is that still not a good solution?
  4. May I please have some feedback?
  5. Then is something like this actually okay: public class Player { private Map<AnimationName, Animation> playerAnimations; private Map<SoundName, Sound> playerSounds; public void update() { // Control resources } } If that is fine then why not, for a simple game, allow the objects to render themselves? They have all the information they need to do so in this case and so long as the rendering takes place after all the updates I do not see why there should be a problem. Does passing resources from a resource manager when constructing the object count? If objects can hold their own resources (as references like in Java) and receive them from the resource manager at construction, what would be a good way for them to get just what they need from the manager without it costing many lines of code (assuming the manager has not pre-emptively tailored different sets of resources to specific objects, which I'm beginning to think is a silly thing to do)? That won't be the case for me, not right now anyway. Maybe when I have more experience and I see a need. Right now everything that needs to render renders after everything has updated, in the same frame every frame. That call renderer.render(Animation.NPC1_WALK_DOWN, position.x, position.y); was just an example of the Player sending a message to the Renderer to add the Animation described by the passed Enum to its Map of Animations to render in its own time, which would be after everything has updated that frame. It's not saying to the Renderer, "render this now while the updates are happening". I could have called it something better, like addToRenderMapToRenderLater(). Well maybe not better, but more explicit anyway If that is still not a good idea, then how should objects send messages to the various systems to tell them to do something?
  6. Thanks frob. To see if I understand you correctly: Game objects should not hold references to resources Game objects should never come in contact with the resource manager Systems such as a Renderer can interact with the resource manager to retrieve the resources they need, probably at startup Game objects should send messages to the appropriate systems so that operations such as drawing a texture or animation or playing a sound are performed by those systems Is that right? When sending messages to a system, would it be appropriate for the game object sending the message to do so via a held reference to the system? For example: public class Player { private Renderer renderer; public class Player(Renderer renderer) { this.render = renderer; } public void update() { // If I want to draw something renderer.render(Animation.NPC1_WALK_DOWN, position.x, position.y); } // render() method begone! } Here the call to render() would add an animation to a Map of Animations based on the Enum in the first parameter. When all the game objects have finished updating, the Renderer would then render all the things objects this frame have told it to render. Once it's done, it would clear the Map and await further instructions in the next frame. And so on. This is just a rough idea based on my current understanding of what you recommend. Does it have merit or am I thinking about this incorrectly? I know that adding to and then clearing from a Collection of things every frame could become expensive depending on the number of draw calls but it's all I can think of that would probably work at the moment. If it's definitely not suitable, what else would you recommend doing instead?
  7. For a sprite based 2D RPG style game, how should assets such as textures, animations, music and sound effects be distributed to and accessed by game objects? Assuming you have a resource manager dedicated to loading and containing the resources, should this manager be passed indiscriminately to wherever there is a need for a resource(s)? Should the resource manager segregate various textures and animations from sprite sheets as they are loaded and hold segregated sets (maps/lists) of these textures and animations based on a pre-determined need by different game objects so that they can be quickly set up? By this I mean, where you are certain object A needs only a set of X animations and Y sound effects throughout the lifetime of the program. If all textures, animations, music and sound effects should not be segregated as they are loaded and should instead each be stored in one big container of their respective type for all objects to freely choose from, how should the objects retrieve the resources they need efficiently and with minimal lines of code? Any object could hold any combination of textures, animations or sound effects held by the resource manager. I believe it would be easy with this approach to have very many lines of code dedicated to retrieving all the resources an object will need, for every object. Finally, should objects hold resources at all? At this point I don't see why objects shouldn't hold their own graphical resources since the objects contain the data such as position, width and height that the resources would need in order to be rendered correctly. However, I'm not so sure about resources such as sound effects, since these types of resources don't need any information from the object in order to play. Should they be held and controlled elsewhere, by dedicated music and sound effect playing systems?
  8. Java Input Handling

    What if instead you assigned fx1 = new Z(). Would gx1 change, since it points to fx1? I thought this since I was passing a State instance between classes without calling new State(). Since the final State reference was not the same as the original, I am wondering if when passing objects a copy is made or new is called implicitly. Is either case true? Maybe you've explained this already and I just haven't understood. What do you think about the way I am currently setting up State Transitions with the StateTransitionSets? Would you consider it poor design to create such classes to only ever do one thing once, just to make the State initialisation process more manageable? If this is a bad way to do it, what would you recommend instead? I would rather not do it all in initialiseStates() going TransitionCondition by TransitionCondition, Transition by Transition, for every InputHandler State. It's also hard to see how I can initialise in a loop due to all the different types of States and varying number of TransitionConditions per Transition and Transitions per State.
  9. Java Input Handling

    Ah, I see. This would be the exact same when passing objects to constructors of other classes then wouldn't it. I thought that object instances in Java acted as references to an object in memory and that a change made to one instance of that object would be reflected in every assigned instance, since they all reference the same object. From what you've shown me, it seems this does not hold true when passing instances out of scope. Then it seems, you're working with a copy of the instance. But wait, that can't be true can it? When you modified x2.b, the change persisted across scopes. If x2 was truly a copy, that wouldn't happen would it? I'm a little confused on that. I got the transitions to work thanks to your advice. All still in early stages, things may yet need to be changed, but I like the shape and flow of the transitioning process now. If you're interested, you can see how transitioning between NotHandlingInputState and HandlingUpKeyPressedState works by having a look at these classes. InputHandler -> NotHandlingInputStateTransitionSet, HandlingUpKeyPressedStateTransitionSet, StateTransitionSet -> NotHandlingInputState, HandlingUpKeyPressedState, State -> Transition, InputTransitionCondition, TransitionCondition The StateTransitionSets were made to break up each States Transition and TransitionCondition initialisation process into more manageable chunks. Is it acceptable to make classes like this whose job is to perform one very specific task such as in this case setting up a specific set of Transitions for a State? If not, what would you recommend to help manage setting up the States in InputHandler? Each State can be made with any number of Transitions, each with any number of TransitionConditions, where each TransitionCondition can be any specific type of TransitionCondition. If all of this was done in InputHandler.initialiseStates(), the method would be a huge mess. I would be interested to know your thoughts on the design so far if you have time to give it a look. Of course if anything is unclear I'll do my best to explain. Thanks.
  10. Java Input Handling

    Sorry for the delay in getting back. I've been working on this bit by bit and have made some progress. However, I have encountered a problem which I cannot get past. I have an idea as to why what I am trying is not working, but to confirm this I must ask: Will the final object reference of a sequence of same type object reference assignments still be a reference to the original object, regardless of how many object references were assigned beforehand or of changes in scope across multiple classes? Or, will the local scope of each new reference override the preceding reference from which it was assigned so that the newly assigned object no longer references the original, but instead is a new object in memory? I would have thought the former, but my program is not behaving as it should based on that. Of course, my assumption as to the reason behind the misbehaviour could be wrong, but I cannot see what else might be the cause of the problem right now. To show you what I'm actually talking about, step through these classes below and follow the progress of InputHandler.currentState as it is passed around and referenced. InputHandler -> NotHandlingInputStateTransitionSet -> Transition As you may see, when a Transition according to its TransitionConditions is successful, it assigns currentState to a reference to an appropriate predetermined newState, thus changing InputHandler.currentState and allowing different behaviour depending on which State it is referencing. Or at least this is what should happen and I cannot see why it does not. As I said, this may not actually be what's causing State Transitions not to work, but it is what appears most likely to me and I thought it worth looking into first. If you need more context or if anything is unclear let me know. Thanks.
  11. Java Input Handling

    I'm sorry but no, I don't really follow you. Would you be able to be more specific about how you would implement your idea? Is the idea of a Controller one which should be pursued? If so, in what way should it be structured? In a solution of yours for a problem like this, do states ever come into the equation? Are they suitable in some way, on some level, even if perhaps not at the object level? A thought, and probably not a well formed one, for a solution has occurred to me in which some sort of Event types would be generated depending on the value of keycode. The Events would be processed somehow so that depending on which ones are active at a given time, others can also be active or not active and perhaps can be forced to go from active to inactive. Then whichever GameObject is interested in dealing with these input events can process the active ones which are available. This would mean that if the Events manage themselves so that a moving left event for example is active, then a moving right event would not be able to become active and so in effect opposite movement while moving would be ignored. That's as far as that idea goes. I don't know how it would be implemented, if it would even be possible to. However, as an idea, does it sound plausible or is it far fetched? It would be very helpful if concrete examples of how to handle input in a correct manner could be provided. Remember, we're not dealing with the totally abstract here. I need to know a good way to get from the starting platform A which is the InputProcessor and its keyDown(int keycode), keyUp(int keycode) methods to B which is the Player so that input can be dealt with in a controlled way which so far I have only been able to do in what I believe is a very crude manner. I would like the manner in which input is dealt with to be less crude and less invasive of GameObjects. I just don't know how.
  12. Using the LibGDX InputProcessor, what can I do with the keycode integer values generated in keyDown() and keyUp() to handle input correctly? To expand, what I mean by handling input correctly is to handle it in such a way so that GameObjects which need to be controlled by user input, do not themselves actually handle the user input or hold any input related values such as key down/up flags, and are instead influenced indirectly by something else which handles the input. One way in which I feel this can be done is with a Controller object which can act as a mediator between the input values and the object you want to be influenced by the input. The Controller would hold a reference to the object and methods to receive the keycode input value. Depending on this value, the Controller would then, using a switch case or set of if-else's, call relevant methods on the object such as move(x, y) or attack(). This decouples the object from the input and allows you to control it in a top down way. The problem with this approach, in my case at least, is that it does not provide a fine enough level of control over the object so that it responds appropriately to different sets of keys. A concrete example of this would be if the object is moving in a certain direction because a key is held and another key is pressed detailing that it should move in the opposite direction, I would want the key that would make the object move in the opposite direction to be ignored so long as the first key remains held. With the Controller setup that wouldn't happen. The second input would override the first, causing the object to move in the opposite direction. The way that I have managed to achieve the level of control I need over how input is acted on by GameObjects, which in my case is primarily the Player object, has been by making the Player receive the keycode directly from the InputProcessor and handle it through the use of flags and states in the form of State objects. The flags represent the state of input which is relevant to it and the states determine explicitly the state of the Player and what it can do at any one time, including how it handles input state. The current state updates every Player update and based on a set of conditions, including the state of the flags, it either changes to another appropriate state or continues updating. This setup is bad for a couple of reasons. It makes it so that the Player is responsible for maintaining key state in the form of flags, essentially becoming an input handler. It also tightly couples the States it uses to itself, making it so that they can only be used by the Player and not another kind of object. The problem I am facing is that I don't know how to change the setup so that GameObjects which should act on input can do so while remaining decoupled from the input, while also maintaining the fine level of control that states and flags provide over how the input is processed. What can I do to achieve this? Thank you.
  13. Hey, that's fantastic Prototype, it worked!   Here's the improved animation. [media]https://youtu.be/OBz2nGaWd0s[/media]   The only problem is that now I have to go to every frame of every animation that needs it's position adjusted and manually give it a relative position to displace from the object position. This is time consuming, requires eye ball judgement for every animation and, probably worst of all, produces lots of extra initialise-esque code compared to what I had. Is that just something I'll have to live with or is there a nicer way of going about this?   Either way, thanks again Prototype, this has been something I've been unable to figure out for a good while. I'm delighted to have solved the problem.
  14. I have a problem in my game where the left sided meleeing animations get pushed to the right instead of pushing forward to the left as they should. The reason for this is because the sprite sheet frames are extracted with their x,y locations at the top left and LibGDX TextureRegions have their origin at the top left. This means that if the current frame in an animation has a greater width than the previous frame, then the current frame looks as if it gets pushed to the right, because it is drawn from the top left.   This video shows the problem with the meleeing left animation. As you can see, because each frame has its origin at the top left, the character looks as though it is getting pushed back when it throws a punch. [media]https://youtu.be/aNHzcwtSK4c[/media]   This shows the meleeing right animation. Since the origin is the top left, this looks natural. This is how I want the left sided animations to look, only in the opposite direction. [media]https://youtu.be/p3T9s4nllOo[/media]   The animation speeds have been slowed down to help you see the problem more clearly. In the game they would be faster.   I haven't been able to find a way to change the origin in the API. What can I do to fix this?
  15. State Design

    Are you referring to GameInputprocessor or InputController?   LibGDX has a set of what I think are enums which reflect the keyboard keys in Input.Keys. For example, it has Keys.UP, Keys.DOWN, Keys.DPAD_UP. Is this what you are referring to when you say the bools should be in the input system?   I'm just wondering where the 'things' that tell you what keys were pressed should be or if you even need to have a set of individual bools to reflect that.   I don't understand why methods like moveLeft() or jump() would change the entities state. Wouldn't they just be responsible for adjusting entity data, and perhaps handling logic around the data they're manipulating if necessary? I feel like one of the elegant things about states is that once set up, they take care of themselves, from within. I don't think they should be manipulated like that from without.
  • Advertisement