Banner advertising on our site currently available from just $5!
Midori RyuuMember Since 12 Aug 2012
Offline Last Active Sep 30 2012 10:03 PM
- Group Members
- Active Posts 10
- Profile Views 1,620
- Submitted Links 0
- Member Title Member
- Age 26 years old
- Birthday May 4, 1988
Posts I've Made
30 September 2012 - 10:05 PM
11 September 2012 - 10:06 AM
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 (now that he's busy working on Valve's Linux port of Source Engine and Steam client), then it'll definitely revitalize SDL interest.
I'm sure he'll release it before episode 3!
10 September 2012 - 10:31 PM
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).
~~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?
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++.
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.
~~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.
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.
~~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?
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)
~~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).
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)
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. A very detailed guideline of how you got started, how you progressed, and finally where you are at now! 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!
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))
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();
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.
10 September 2012 - 11:02 AM
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 Github for those who want to make me feel bad by telling me how bad it is.
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
20 August 2012 - 11:28 PM
Thank you all for your replies.
My reply may or may not make much sense. I'm quite feverish at the moment.
Thank you again for your patience to my noobiness!
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.
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.
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.
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.
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.
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!
I actually stumbled upon your website when searching about entity systems. I followed the links you gave as well. Lovely reads!
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 little series on component based entities systems a few years ago. Since then, I've extensively toyed with the idea, cleaned it up, and taken it much further.
A pure component system seemed either overkill, or rather, unintuitive, which is probably the strength of OOP.
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.
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.
Then a tank, a subclass of vehicle would inherit those components from it, and be given it's own "cannon" component.
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.
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! )
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!