• Advertisement

Midori Ryuu

  • Content count

  • Joined

  • Last visited

Community Reputation

177 Neutral

About Midori Ryuu

  • Rank
  1. Either use libraries and frameworks to abstract that work for you, or you can always try going into modding games! There are even games like Starcraft 2 for example that come with a GUI for making mods.
  2. A set guideline for beginning video game programmers!

    [quote name='Servant of the Lord' timestamp='1347377522' post='4978923'] That's good! SDL hasn't had an update for years and though it's supposed to be receiving a major '2.0' update, an official release (aside from minor bug fixes) hasn't actually been released. If the head developer actually goes through with the major 2.0 release ([size=2]now that he's busy working on Valve's Linux port of Source Engine and Steam client[/size]), then it'll definitely revitalize SDL interest. [/quote] I'm sure he'll release it before episode 3! [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] [img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img]
  3. A set guideline for beginning video game programmers!

    [quote name='bloisch4' timestamp='1347307058' post='4978679'] ~~What programming language should I start out with? -So I heard C++ is a hard language to go with first, but I like the logical design of it! I can't help but keep going with it. Should I switch to Java since it seems it has basically everthing a beginner would need? [/quote] I think you should choose a language depending on what your target platform is, rather than how hard it is. C++ allows multiplatform (if you used the right libraries). Java does allow that too, but also has more additional platforms such as Android, but at the cost of some performance. (Believe it or not, automatic garbage collection is more of a hassle than a convenience when it comes to mobile development. And please no one mention the NDK) Personally I prefer Java (even if I weren't targeting Android), but that's because I'm focused on making small, 2D games, and Java is perfect for that. 3D... I'd switch to C++. [quote] ~~Use an engine, make one, or don't use an engine? -Ok ok, I know making an engine is way to hard and time consuming so I'll skip that idea! -I am very confused when it comes to learning a language well, especially when it comes to using a game engine or not. So I want to get the very most out of my learning, does that mean I should use a game engine and start making games just like that? Or should I take the long run and get the experience working with a graphics library making 2D games without an engine? I figure this because I would get a better, more indepth experience making games. [/quote] I think there is no need to go as high as using a game engine, nor as low as using just a graphics library. I'd say use a framework (read:a game library) that gives you just what you need to get started, and nothing more. I'm not familiar with C++, so I don't know if SFML would qualify as such. [quote] ~~How to pave my own way? -Ok, so I see people who have made 2D games and I am like, "HOW DO THEY DO IT?!". So I am so engrossed with the thought of how to make a game that I really have no idea how! What I would want(not saying what I need, so correct me if I am wrong) is personal experience from others. I want someone to tell me how they did it, going from learning a language, to making 2D or 3D games! How? [/quote] Trust me it's quite easy to make a 2D game with the right tools. Once you have enough experience, you will be like "OMG it's this easy??!!". Making a simple 2D game is quite easy in itself. The real trick is, just like Servant said, making a -good-, -complete- (polished) game is the real hard part. A menu? That's added difficulty of learning how to implement game states. An interface? That's the added difficulty of learning how to integrate a GUI library, and how to forward input listener events (and general events) from the GUI to the game, and vice versa. Physics? Well, you get my drift! Adding things like the player jumping in an arc, or making the player not move when he's walking and facing a wall (something that always annoyed me in games, but now I know why they didn't fix it), or to implement player animations, these are the things that really will take up the bulk of your time. The first game I had I got up and running, it took me 3x time to add the things I mentioned above than it was to finish the game. Of course, the good news is that it will only be hard the first time you do this and you're still learning the things. Afterwards it will come quite easily to you, and you will think "OMG it's this easy??!!" when you are done with them too. (Not to mention you will be able to reuse some of your code, which will make it take you 1/3x the time, rather than 3x) [quote] ~~What graphics library to use? -This isn't so much as an issue, but I've heard things of SDL(it's C based and old), tried SFML(hate the setup with any IDE) and don't even want to think about Allegro! Can anyone give me some advice when choosing a graphics library-(choose this one, it doesn't matter what you choose, try them all). [/quote] Well I can't advise when it comes to C++, but if you ever pick Java, LibGDX (framework) is always great to use. Slick2D is good as well, but kind of getting abandoned I think. And of course there's always the good ol' LWGL which is a bit too low level for my taste.(The other libraries are essentially wrappers for it) [quote] I am at the utmost confusing time in learning game development. What should I do? Where should I start? What should I learn? How can I do it? I make it to generic, sorry. The most important thing I think every beginner looking into game development would want, is some personal experience of another person.[color=#00ffff] A very detailed guideline of how you got started, how you progressed, and finally where you are at now! [/color]So... Thank you very much for answering my questions, I hope this helps all the people who read this and the questions/comments that follow! ~To all you people game developing away, keep it up, you guys rock and give us beginners something to think about! [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img] N,n,n,NINJA![img]http://public.gamedev.net//public/style_emoticons/default/ph34r.png[/img] [/quote] It's not detailed, but... Well, I got started learning C++ in college, after which was followed with Java. I got forever scarred of C++ due to the data structure and algorithm course (run while you still can), so I kept with Java. In my OOP class I made what Servant of the Lord suggested you do, a text based RPG, with armor, etc.. This will help you learn the main game logic. (Adding graphics is just a simple additional step once you learn that. Really, I'm not joking, just look at my render method which does the rendering (then again I used a framework)) [CODE] camera.update(); camera.view.setToOrtho2D(viewport.x, viewport.y, viewport.width, viewport.height); camera.projection.setToOrtho2D(viewport.x, viewport.y, viewport.width, viewport.height); Gdx.gl.glViewport((int) viewport.x, (int) viewport.y, (int) viewport.width, (int) viewport.height); spritebatch.begin(); renderManager.render(spritebatch); spritebatch.end(); [/CODE] This small function is all that separates a text game from a 2D graphic game!! Where was I? Oh yeah! Once I knew the game logic, I started searching for a game library, and I fell upon Slick2D, which I used to make a small top down shooter. Then I started doing the things I told you above, integrating a GUI library, physics, menu, etc.. Right now I'm aiming at doing a fully fledged platformer, but I'm still getting used to LibGDX which I started, as well as revising my game architecture, since I was pretty much abusing OOP in my previous games. So yeah, good luck! And whatever happens, don't give up!! If I didn't keep giving up (and coming back later) I would probably have finished many games by now! Keep fighting! Things may seem hard and long, but it's only temporary. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  4. Hey all~ I am back after a somewhat long absence, as I've been busy acclimating into my new job. I wanted to update you guys who took the time to help me with what happened! (And I might hope for a little feedback for how right (or how less wrong) I did things.) So, after some more search, I fell upon the Apollo entity framework. It is built by the same folks who has made the Artemis entity framework, but is more 'object-oriented' in its thinking. I fiddle around with it in the past couple of weeks, and I must say I really do prefer it a lot over Artemis, which I wasn't planning on using. This on the other, I loved! I'm not using the platform in its entirety (yet), and I have made some modifications of my own to suit my programming taste (to the builders, etc..) I have made a small, small demo where I integrated it with LibGDX and Box2D, and I have the code up on [url="https://github.com/Midori-Ryuu/Black-Horne"]Github[/url] for those who want to make me feel bad by telling me how bad it is. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] My architecture is essentially having the Apollo world contain the Box2D world (though I keep a separate reference for the Box2D world for convenience). I have a Renderable component, along with a collidable component. The collision component depends on the Renderable component, but for the time being only, and only for practicing/experimenting with things, but they should be completely independent, and only separately depend on the Transform component which holds the position. I have a collision detection listener which doesn't itself act on the bodies, but triggers a flag in the Collidable component and forwards it the needed information to handle the collision (the other body, its type, etc..) I haven't used the event listeners built into Apollo, so I cant' say anything about that, though I might use it later on. Sorry about that, Gabriel, but I hope I can still answer some of your questions in the code. I'm using builders like Apollo recommends, though I have modified those to take several parameters. This broke the methods related to builders (which was rather convenient) but it's nothing fatal. (To those who made Apollo, my sincerest apologies for butchering your framework!!) So yeah, that's pretty much it! Don't judge too harshly.~ I wonder if I should start my own game dev diary.. But I don't want to infect people with bad code. xD
  5. Wow a lot of replies since yesterday! I didn't think this topic would get that much attention! [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img] Thank you all for your replies. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] My reply may or may not make much sense. I'm quite feverish at the moment. [quote name='Telastyn' timestamp='1345465639' post='4971448'] [quote name='Midori Ryuu' timestamp='1345459416' post='4971406'] Thank you again for your patience to my noobiness! [/quote] Just to intrude for one moment: your posts are well formed and ask good questions. Frankly, most professional programmers I've worked with (albeit in non-gamedev) wouldn't even think to look into how to design things better; let alone speak intelligently about how/why they did their design a certain way. Being humble is good, but make sure your self-evaluation is accurate too. [/quote] Thank you for the compliment! Maintaining the balance between humble and cocky is a bit difficult for me, so I prefer to stay on the safe side. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] [quote name='dmatter' timestamp='1345469895' post='4971464'] [quote name='Midori Ryuu' timestamp='1345459416' post='4971406'] I do agree with you that it's better to compose here, but I kind of feel that as long as I don't allow the inheritance to expand more than 2-3 levels deep it's an acceptable tradeoff to the advantages given by composition.[/quote] I tend to think that more than 1-2 levels is questionable. Where 1 level obviously means you're extending an interface or abstract base class and 2 levels typically means you've introduced an abstract helper class that implements some or all of an interface and maybe applies the Template Pattern to simplify things for subclasses. Any deeper and it starts to smell and I begin to wonder whether something has gone wrong. Obviously "is-a" is itself a multi-faceted concept and I have long since decided that using inheritance to model the structural or logical is-a relationships is not the way to go. These days things like LSP teach us that you should really just use it for just the behavioural is-a relationships, in other words whenever you need polymorphism. Some concrete examples: Tank is-a Vehicle (logical) Duck is-a Bird is-a Animal (logical) Square is-a Rectangle (structural) RoomWithTwoDoors is-a RoomWithOneDoor is-a Door (structural) Tank is-a GameEntityEventListener (behavioural - tank will polymorphically respond to game events such as onUpdate) XMLParser is-a TextParser (behavioural - subclass implements parse(String text)) (Note: Please don't think that my distinction between structural and logical is-a relationships is a formal one, it's more intuitive than anything). So I would say there are two okay reasons to use inheritance, first and foremost is this: 1) Use inheritance to gain polymorphic behaviour (but if you need polymorphic behaviour, otherwise you're over-engineering). The second I permit for pragmatic reasons in languages that don't support mixins as a first-class concept: 2) May use inheritance as a way to mix-in or reuse an implementation of a public class interface. The key part to point 2 is the word "public", if you're using inheritance just to gain reuse of private code then it's likely you've modelled a structural is-a relationship (which is bad) and is also subject to Hodgman's explanation given earlier about whether Tank should inherit or compose Vehicle. Point 2 is easily abused though, think of it simply as a get-out-clause for when it's pragmatic :-) The logical relationships in particular may well fall out naturally anyway - you could imagine renaming GameEntityEventListener into simply Entity and then you have achieved both logical and behavioural subclassing, in this case it is okay since it was the behavioural aspect that you designed for and the logical aspect is purely cosmetic but aids in your comprehension. The real point is that inheritance is not being used to model real-life, or mimic some scientific classification of types - in software it is merely a tool that allows us to separate specialised implementations from generalised implementations from interfaces. [/quote] Yeah, I am starting to see how just because something -seems- "logically" correct, doesn't necessary mean it -is- correct. OOP does seem like a double edged sword from that point. I am guilty of using inheritance to gain reuse of private code too.. Being fresh out of college and having worked only for a month now, I still have the whole "Inheritance, inheritance, inheritance" thing glued to me, along with the use OOP to model real life. I didn't even know about composition until a couple of days ago! Thank you again for your great reply! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [quote name='nox_pp' timestamp='1345476649' post='4971493'] I'm not much of a proponent of OO in general anymore, so take what I say in light of that fact. I wrote this [url="http://purplepwny.com/blog/component_based_entity_system_design_part_1.html"]little series on component based entities systems[/url] a few years ago. Since then, I've extensively toyed with the idea, cleaned it up, and taken it much further. [quote name='Midori Ryuu' timestamp='1345442448' post='4971354'] A pure component system seemed either overkill, or rather, unintuitive, which is probably the strength of OOP. [/quote] Why does a pure component system seem like overkill? I understand that the idea can be repulsive at first, but only given a prior history in adherence to strict OOP principles. It's a perfect fit for the inherently dynamic nature of video games. [/quote] I actually stumbled upon your website when searching about entity systems. I followed the links you gave as well. Lovely reads! Yes it does seem a bit "repulsive" to me, especially the pure component (no entity) style. It's why I was trying to mix in a "flavor" of inheritence to sweeten the taste. It seemed overkill though, because I will be mostly working on small games, and I already have made a game using the traditional system, so as Hodgman said, it "worked". But on the other hand I know that if I want to move on to larger games, I will have to learn to do things the right way in small games first. Mostly, a lack of experience is making me tread these things lightly. [quote] [quote name='Midori Ryuu' timestamp='1345442448' post='4971354'] Then a tank, a subclass of vehicle would inherit those components from it, and be given it's own "cannon" component. [/quote] Isn't the definition of tank rather arbitrary though? What if, without recompiling, you could compose a completely new sort of vehicle at runtime? Is your base vehicle class compatible with a flying vehicle? Or do you have to derive a flying and non-flying vehicle from it? And then, what if you have something that occupies a middle ground...like a "hover tank?" As you can see, a class hierarchy still causes a combinatoric explosion of rigid classes. I'm retreading ground that other posters have covered, but my main point is to cause you to rethink your attachment to OOP with regard to entity systems. It's just not a good fit. [/quote] I was thinking of making things rather static, and try to think of all possible combinations and hard-code them. Though with this thread, I see how things would have gone wrong. (Which was actually my question! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] ) ------------------------------------------------------------------- I really wanted to jump straight to programming and start to get familiar with LibGDX after moving to it from Slick2D, but it's probably better now to take some time to think thoroughly how I will implement all this.. I will just have to ignore this programmer's itch for the moment.. Thank you all again for your great replies!
  6. [quote name='Hodgman' timestamp='1345450591' post='4971378'] [quote name='Midori Ryuu' timestamp='1345448868' post='4971370'] How is this different from adding the vehicle's components inside the tank through inheritance and then adding a cannon component? They really seem the same to me. Will it cause the same problem as the one in your second example? [/quote]In practice, in effect, there's no apparent difference... but you need to distinguish between OOP and OOD. Lots of people use inheritance when writing OOP code out of convenience -- "I want all this stuff in my new class, so I'll inherit it" -- n.b. this same goal can be achieved via composition or inheritance. However, when designing in OOD, the concepts implemented in OOP languages have very specific meanings and using these concepts implies that you're promising to follow certain rules -- e.g. making a class implies you'll follow the [url="http://en.wikipedia.org/wiki/Single_responsibility_principle"]SRP[/url], and inheriting a class implies you follow the [url="http://en.wikipedia.org/wiki/Liskov_substitution_principle"]LSP[/url]. All these inflexible, monolithic, inheritance-based designs of the past have be born out of teams who understood OOP, but not OOD. That's fine -- the majority of code written in OOP languages probably isn't following OO rules at all, and at the same time, OO designs can be implemented in non-OOP languages, such as C... but it's important to note the destiction between the OO theory of design, and the OOP features in certain languages. They're meant to go together, but don't have to. Back to the choice of inheritance vs composition here though -- 1) The main difference in this case is that with composition, Tank only gains access to Vehicle's public interface, whereas with inheritance, Tank gains access to it's protected interface. This is probably bad as it increases the potential to extra unnecessary coupling. 2) If using inheritance, it would also be valid for Tank to inherit from Cannon, and then compose in a Vehicle... so how do you choose which one is right? If it's an arbitrary choice between the two, then it seem that inheritance is unnecessary, and should probably be avoided. If the answer is to inherit from both, then what happens when you want a tank with 2 cannons, or if you make a transforming super-tank made up of 2 vehicles? Common wisdom is that you should default to composition for code re-use, and only use inheritance where necessary. [/quote] The problem is I am trying to keep the layout of my code intuitive (to me at least). As in, a tank "Is a" vehicle but "has a" cannon. So that is why I opted to go with limited inheritance in some places, despite composition being a better solution, since the damage that it might cause will be rather small in comparison to large inheritance chains. I do agree with you that it's better to compose here, but I kind of feel that as long as I don't allow the inheritance to expand more than 2-3 levels deep it's an acceptable tradeoff to the advantages given by composition. Then again, it is the (bad) OOP thinking that's immersed in my head thinking that, and the examples you keep giving are really helping to dispel that kind of thinking (Transforming super-tank made up of two vehicles! [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]) It will be a pain, and probably cost me more development, but I will try to do things the correct way this time, since I know that once I do things the right way, it will be much easier doing it the right way the second time, and third time and so on. [quote] [quote name='Midori Ryuu' timestamp='1345448868' post='4971370'] If so, then the will the character class have a polymorphic reference to the BaseController which can be either an instance of PlayerController or AIController? [/quote]I had it the other way around, where Character is unaware of the controller classes at all, and the controllers have a polymorphic reference to the character. You should design your code in layers, where each layer only uses classes in layer below it, or the same layer. You should also generally avoid designs where two classes both know about each other, i.e. dependencies should almost always be 1-way, not cyclic. For example, C is in the top layer and knows about the public interfaces of A and B. A+B are in the layer below, and each have some complex private details that are wrapped up in a simpler public interface. Also, A and B don't know about each other at all - they're decoupled, [url="http://en.wikipedia.org/wiki/Coupling_(computer_programming)#Disadvantages"]which is good[/url]; they rely on the next layer of code to glue them together in some useful way. See also the [url="http://en.wikipedia.org/wiki/Law_of_Demeter"]Law of Demeter[/url] on principles about loose coupling - you generally want each class to have knowledge of as few other classes as possible, and use sensible layering to glue different bits together into a useful whole. In this case, the controller is in the top layer ©, and AI and characters are in the bottom layer (A & B). C makes use of A&B's public interfaces, inside it's private details, and then wraps this behaviour up in a new public interface (which might be used by another layer above this). [source] +-----------+ | public | | interface | |-----------| |Component C| |-----------| | private | | details | +-----------+ | | | | \|/ \|/ +-----------+ +-----------+ | public | | public | | interface | | interface | |-----------| |-----------| |Component A| |Component B| |-----------| |-----------| | private | | private | | details | | details | +-----------+ +-----------+ [/source] [/quote] Ah yes, that makes a lot more sense, since the player might be in control of many characters, and it also enables the AI to reason in term of groups (cooperation, etc..) instead of just simple characters. That and once the lower layers are taken care of, I assume programming the game and scripting will be a breeze! On another forum where I asked this question it was also pointed how I the setup I made would have caused, for example, the coupling of the characters and rendering to be coupled, which will come in the way in case of a server-client architecture is done for multiplayer. By following your way the rendering will be decoupled from the characters and allows for client side rendering only. Thank you for the time you're taking to answer my questions and all the free tips you're giving us! Just a small question though, (I know it's example and implementation specific and doesn't have much to do with the thread but) why is the AI in the layer below the controller? Is it because it will ask C to provide the public interface of B? You say that I should talk to the below layers, and the dependency should be 1 way, but won't this be better achieved if the A.I is above the controller for it to be able to control the characters, tanks,etc.. through the Controller which provides a public interface wrapping the lower layer? Thank you again for your patience to my noobiness!
  7. [quote name='Hodgman' timestamp='1345445335' post='4971360'] [quote name='Midori Ryuu' timestamp='1345442448' post='4971354'] I would have a small tree for vehicles. The root vehicle class would have a rendering component, a collision component, position component etc.. Then a tank, a subclass of vehicle would inherit those components from it, and be given it's own "cannon" component. [/quote]This is still an abuse of the OO concept of inheritance. You could compose your tank out of a vehicle and a cannon -- e.g. [code]struct Tank { Vehicle vehicle; Cannon cannon; };[/code] [/quote] How is this different from adding the vehicle's components inside the tank through inheritance and then adding a cannon component? They really seem the same to me. Will it cause the same problem as the one in your second example? [quote] [quote name='Midori Ryuu' timestamp='1345442448' post='4971354']The same goes for the Characters. A character would have it's own components, then the Player Class would inherit it, and be given an Input controller, while other enemy classes would inherit from the Character class and be given an AI controller.[/quote]As an example of how inheritance is causing unnecessary restrictions here -- what if you want the ability for the player to take over an AI character, and let the AI take control of their previous character? Decoupled composition allows for this:[code]struct BaseController { Character* controlled; } struct PlayerController : BaseController { InputDevice inputs; void ReadInputsAndControlCharacter(); }; struct AiController : BaseController { CharacterAi brains; void UpdateBrainsAndControlCharacter(); }; void SwapControl( BaseController& a, BaseController& b ) { std::swap( a.controlled, b.controlled ); }[/code]N.B. in the above, CharacterAi, InputDevice and Character are completely decoupled - they don't know about each other at all. The player and AI controller classes form a 'bridge' between these decoupled components -- reading intentions from inputs or AI and passing them on to the character interface ([i]and reading character state ans passing it to the 'brain'[/i]). [/quote] I was actually thinking about similar problems when I posted. I thought of doing some sort of duck-typing in a scripting language to solve this, but I didn't have an actual idea how to. The way you implemented the controllers is much more elegant. I assume this removes the need for a player and an enemy class and the distinction will be made at runtime when the components are assigned? If so, then the will the character class have a polymorphic reference to the BaseController which can be either an instance of PlayerController or AIController? [quote] [edit]Sorry for the C++ examples [/quote] It's perfectly fine as long as you excuse my inexperience with C++, as I may have understood the example you gave a bit wrong.. >_<
  8. I admit, I have made the sin of overusing, and even abusing inheritance. The first (text) game project that I made when I was taking my OOP course went as far as "Locked door" and "unlocked door" from "Door" and "Room with one door", "Room with two doors", and so on from "Room". With the (graphical) game I worked on recently, I thought I had learned my lesson and put a limit on using inheritance. However I noticed the problems soon beginning to appear. My root class was beginning to bloat more and more, and my leaf classes were full of duplicate codes. I thought I was still doing things wrong, and after looking it up online I discovered that I wasn't the only one with this problem. It's how I ended up discovering Entity systems after some thorough research (read: googlefu) When I began reading on it, I was able to see how clearly it was able to solve the problems I was having with the traditional OOP hierarchy with components. These were in the first readings however. When I stumbled upon more… “radical” ES approaches, such as the one at [url="http://t-machine.org/index.php/2007/12/22/entity-systems-are-the-future-of-mmog-development-part-3/"]T-machine[/url]. I began disagreeing with the methods they were using. A pure component system seemed either overkill, or rather, unintuitive, which is probably the strength of OOP. The author goes so far as to say that ES system is the opposite of OOP, and while it may be usable along OOP, it really shouldn’t. I'm not saying it's wrong, but I just didn't feel like a solution I would like to implement. It was then that I stumbled on [url="http://www.gamedev.net/topic/623358-component-based-inheritance-based-design/page__p__4930875#entry4930875"]Hodgman post[/url], and it really made sense to me. I really didn’t see any conflict between OOP and composition; rather, the two seemed as one. So to me, and to solve the problems I was having at the beginning of the post, without going against my intuitions, is to still use a hierarchy, however it won’t be a monolithic hierarchy like the ones I used before, but rather a polylithic one (I couldn’t find a word opposite to monolithic), which consists of several, smaller trees. The following example shows what I mean (this is insipied by an example I found in Game Engine Architecture, Chapter 14). I would have a small tree for vehicles. The root vehicle class would have a rendering component, a collision component, position component etc.. Then a tank, a subclass of vehicle would inherit those components from it, and be given it's own "cannon" component. The same goes for the Characters. A character would have it's own components, then the Player Class would inherit it, and be given an Input controller, while other enemy classes would inherit from the Character class and be given an AI controller. I don't really see any problems with this design. Despite not using a pure Entity Controller System, the problem with the bubbling up effect, and the large root class is solved by using a multi-tree hierarchy, and the problem of the heavy, code duplicating leafs is gone since the leafs don't have any code to begin with, just components. If a change needs to be done to the leaf level, then it's as simple as changing a single component, instead of copy pasting the code everwhere. Of course, being as inexperienced as I am, I did not see any problems when I first started using the single hierarchy, inheritence heavy model, so if there are problems with the model that I'm currently thinking of implementing, I wouldn't be able to see it. Your opinions? P.S: I am using Java, so using multiple inheritance to implement this instead of using normal components is not possible. P.P.S: Intercomponent communications will be done by linking dependent components to each other. This will lead to coupling, but I think it's an ok trade off.
  9. [quote name='nox_pp' timestamp='1344956313' post='4969484'] I can't speak much to the Java/Slick2D specifics, but the following two patterns/idioms are the answer to your first problem. [url="http://en.wikipedia.org/wiki/Flyweight_pattern"]Flyweight Pattern[/url] [url="http://en.wikipedia.org/wiki/Copy-on-write"]Copy on Write[/url] Use the flyweight pattern to easily share resources between entities, and then use copy on write so that you can "add a frame to a particular entity's animation," without effecting the other entities. [/quote] Thank you for the link! I had implemented (or at least think I had implemented) the Flyweight Pattern in my design, as the images are shared by the animations. However I did not know about the Copy on Write! That will probably help me fix the animation problem I'm having. If anyone has any other solutions, I'm always looking for insight! And thank you again nox!
  10. Hello all. I am using Java, particularly the Slick2D library. So far things are going well (at least I think they are). However I have stumbled into a problem. Seeing as this is my first game, I have no idea how I should manage the Animations and the textures in the game in a way to be both memory efficient and processing efficient. I was wondering if I should give each and every entity I have its own animations and its own textures. Currently, the way I'm doing this is by making a limited set of images, which are then shared by the animations. These images are only created once in memory. The animations, however, are done by creating a separate and new animation for every new entity I have. I have also created a class specifically to handle the resources. I was wondering if this is the correct way of doing things, or is it not memory and/or performance efficient, or should the entities with similar animations share the same single animation in memory? I find this a bit inconvenient since if I want to add a frame to a particular entity's animation, then all the entities with those animations will be affected. Or is it perhaps the other way around, and I should even make new textures for every single entity, from which I create new animations. The main reason I can think of for doing this is the effects I might want to do later on on a frame in an animation without affecting the other animations that might use this texture. My second question is, I'm letting the resource class decide which animation it should send to an entity, depending on the state it's in. For example, it will see if the player is walking left, and give it the according animations, if he's walking right, then the right animation. I wonder if it's more correct to let the Player class decide which animation it will request from the resource class. This is my resource class: [CODE] package blackhorn; import org.newdawn.slick.Animation; import org.newdawn.slick.Image; import org.newdawn.slick.SlickException; public final class CAnimations { // Player walking left Image playerWL1; Image playerWL2; Image playerWL3; Image[] playerWL; // Player walking right Image playerWR1; Image playerWR2; Image playerWR3; Image[] playerWR; // Player standing Image[] playerS; // Enemy standing Image[] enemyS; //Ground Image[] groundS; //Bullet Image[] bulletS; public void init() throws SlickException { playerWL1 = new Image("data/playerWL1.png"); playerWL2 = new Image("data/playerWL2.png"); playerWL3 = new Image("data/playerWL3.png"); playerWR1 = new Image("data/playerWR1.png"); playerWR2 = new Image("data/playerWR2.png"); playerWR3 = new Image("data/playerWR3.png"); playerS = new Image[] {new Image("data/playerS1.png")}; enemyS = new Image[] {new Image("data/enemyS1.png")}; groundS = new Image[] {new Image("data/groundS.png")}; bulletS = new Image[] {new Image("data/bulletS.png")}; playerWL = new Image[] { playerWL2, playerWL1, playerWL3, playerWL1 }; playerWR = new Image[] { playerWR2, playerWR1, playerWR3, playerWR1 }; } public void getCurrentAnimation(Player player) { if(player.getSideSpeed()<0) player.setCurrentAnimation(new Animation(playerWL, 500)); else if(player.getSideSpeed()>0) player.setCurrentAnimation(new Animation(playerWR, 500)); else if(player.getSideSpeed()==0) player.setCurrentAnimation(new Animation(playerS, 500)); } public void getCurrentAnimation(Enemy enemy) { enemy.setCurrentAnimation(new Animation(enemyS, 500)); } public void getCurrentAnimation(Ground ground) { ground.setCurrentAnimation(new Animation(groundS, 500)); } public void getCurrentAnimation(Bullet bullet) { bullet.setCurrentAnimation(new Animation(bulletS, 500)); } } [/CODE] And this is my player class. [CODE] public class Player extends Character { private boolean hasFired = false; public Player(float x, float y) { super(x, y, 1, 1, 1, 1, 0, CConstants.ROTATION_RIGHT, CConstants.PLAYER_JUMP_SPEED, CConstants.PLAYER_WEIGHT); } public void init(GameContainer container) throws SlickException { MainGameState.animationList.getCurrentAnimation(this); super.init(container); } public void update(GameContainer container, int delta) throws SlickException { super.update(container, delta); } public void render(GameContainer gc, Graphics g) throws SlickException { MainGameState.animationList.getCurrentAnimation(this); //animationList is the CAnimation class instance super.render(gc, g); } } [/CODE] [url="https://github.com/Midori-Ryuu/Black-Horn/tree/master/Black-Horn"]The full code is on Github for those who are interested.[/url]
  • Advertisement