Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2012
Offline Last Active Apr 25 2016 01:09 PM

#5081228 Where Do I Start? So Many Possibilities

Posted by on 28 July 2013 - 11:24 AM

My experiencie




Just start working in the IT world programming in J2EE, it means a lot of money, less work and more reputation and career.


Then later you can start any videogame project for fun. Or you could start a project while you are working.


IMHO, i was shocked to know that some half baked programmers earned the double than my salary of indie game developer, working trivial business projects (in fact, most business projects are database, logic,web and security. Rinse and repeat thousand of times).


Why are you even here? :/

#5081078 Jittery Movement and Uncontrollable Rotating

Posted by on 27 July 2013 - 05:41 PM

Did a bit of adjusting and stuff so that I move according to WASD.



Here is the result of your help :3


#5080229 Data Driven Design: Part 2

Posted by on 24 July 2013 - 02:18 PM

Since there is nothing like an ECS Pattern, your approach is neither right nor wrong, but a few things:


I dont think you need different Managers for different Componentpools, first of all you don't want to write one for every new component and second I cant think of anything they would handle in different ways, in C++ I used a templateclass for the componentpool, so every pool can be used like Pool<ComponentType>, I believe there's something similar in C#




Anyway, a while ago I was at the same point, googling ECS gives lots of sites which introduce this "crazy new" system to do things, but only a few go into detail, i guess that's just something you have to learn by trying what works best for you.


Did you read the first post I linked in the top and how that went?

I would like to make an engine so I split it into smaller bits and work on it one bit at a time using the Data Driven Design methodology.


My approach is inspired by how the creator of...I think Dungeon Siege? Made his game and explained in great detail some of the thoughts and considerations that went through the design process. Was also inspired by a few other articles to allow very minimal form of OOP.

#5080144 Data Driven Design: Part 2

Posted by on 24 July 2013 - 09:38 AM

Part 1: http://www.gamedev.net/topic/645745-data-driven-design-questions-and-answers/


So in continuation from my last post I was confronted with what seemed to be my problem with this methodology.


Your problem appears to be that you are suffering from design paralysis because you're trying to take in the entire scope of everything that could be considered data-driven design at all once, including complete existing implementations, so you can rebuild it yourself. This is bound to result in frustration and failure. You need to start small, and build systems that you need for your games. Reading other people's code can be interesting, but often lacking in a lot of critical detail about the why of various decisions that can easily lead you astray.



You can read Josh's entire comment in the thread.

I looked over what I wanted to do and is now trying to split it into very small bites and take it a step at a time.


I was advised to look at parsing XML or JSON but I wanted to try something else first as I like visuals. Parsing, in my experience, is not that hard.

So I started designing a flat hierarchy structure which seems to be common for DDD software. From what I understand this design below should follow the philosophy of DDD.



The system is build up of Entities which consist of Components, each defining a behaviour or attribute that the entity can have. So an entity is defined by it's components and is otherwise an empty shell without behaviour or attributes.


Each Entity got an ID specified by a simple Int. Might change in the future of course. The ID is given when the Entity is born. It got a list of Components which is done by making a list that contains objects which implements IComponent. Every component will implement IComponent and if in the future every single Component needs a certain behaviour or attribute it can be implemented via the Interface.

In this case, since I want to just render a sprite on screen, I've made two component classes. The SpriteComponent and the MovementComponent. They don't contain any logic whatsoever only fields.


They both use objects from the SFML Framework which is also shown in this picture.


My goal this time around is simply to render a sprite on screen given X,Y Coordinates.


Am I on the right track?
Would you suggest different naming given what I want to achieve above?


The reason I called it "MovementComponent" is because I want it to signal that this entity can move from A to B, rather than PositionComponent which would indicate that it's stationary. (At least that's what I think, correct me if you feel it's backwards).


Now to handle Components and Entities I use Managers. Some seems to call them Systems, but if I understand it correctly it simply comes down to preference as they do the same thing.


In DDD you want to update things in pairs rather than in sequence. So instead of doing ABC, ABC, ABC which will have a horrible impact on performance, you do AAA, BBB, CCC and so on.


So for every component type you need a ComponentManager. The following design should illustrate it.




The EntityMgr holds a reference to one of each Component Manager which in turn will hold every single component of their type. They all implement the IManager Interface since they will all need their implementation of the Update() Method. So if in the future you want to extend the engine with more managers and component types this should be easy to follow.


The EntityMgr also creates entities and gives them an ID. The EntityMgr can also remove an entity and all of it's components when we don't need the entity any more. When Create is called it's supposed to put the components in their rightful manager. I am still debating the idea whether an Entity will just be there so that I can assemble it and its components from it's ID or if I should keep a reference for every single Entity in the EntityMgr.


Am I on the right track? And if so:

Which do you think would be the smartest in this case?


This could turn into a series of threads where I get from zero to hero happy.png

#5079915 Map Generation: Code vs from File

Posted by on 23 July 2013 - 12:20 PM

Well if you want to do external retrieval of data for your game, I suggest XML/JSON or serialize your map data as binary data files.

#5079860 Data Driven Design: Questions (and Answers?)

Posted by on 23 July 2013 - 09:12 AM

Never heard of design paralysis but I guess it makes sense, given your description.


When I learned about Object Oriented Design for my first courses in Java, I sat down and read a book about Java for about 5 months. Then it finally clicked and all the theory I had read over time about how OOD works, suddenly made sense and I could pretty much utilize it all from the get got. It was the same concept I wanted to apply to learning Data Driven Design. When it clicks I learn incredibly fast and can apply the theory I've previously read with ease. I wanted to understand DDD in it's simple form. Which I do. I understand, in theory, how it works. I just can't apply it to code. It's just very different from OO.


I am not reading others code to get there but now I've reached a point where reading code is beneficial because I understand most of the theory behind it. It's just how I learn unfortunately.


My dream is to end up with a very flexible engine, yes. I am no fool though and know it will take time and effort to get there at least. It won't happen overnight ^_^

I just really hate the notion of starting to code something and have no one by my side to consult with over it. Which is why I like getting taught by teachers rather than reading books or courses on the internet. If I make things wrong from the get-go and learn nothing I feel I've wasted my time.

#5079713 Data Driven Design: Questions (and Answers?)

Posted by on 22 July 2013 - 07:17 PM

I've been reading up on a lot of articles which covers the subject of Data Driven Design (DDD) when making games.


It seems to come down to:

  • No Hard Coding
  • No Game Specific Code in Engine
  • Scripting (ai, cut scenes, etc.)
  • Generalizing Code for Max Reusability
  • Component Design
  • Modularity
  • Low Coupling
  • Editors (Data, Map, Scripting)
  • External Data Retrieval
  • Constants kept in Text Files (INI or otherwise)
  • Expose Data through Editors for Scripting/Manipulation for Designers

Now, my first question is of course: Is this understanding correct? (From an Objective Point of View if possible)


One of the editors I looked at was Warcraft 3's Map Editor (WC3 ME) since I've had the most experience with it over my years of obsessive gaming. For those who don't know, the WC3 ME is the tool used to make custom maps in WC3. You had the power to pretty much alter anything within the engines limitations be it Units/Abilities/Items (Raw Data Editing like in a Database), Maps (Level Editor) or Triggers (Event Based Scripting Editor). You could also write in Blizzards custom language called JASS to gain absolute control of the language the the Trigger Editor tried to cover in as much detail as possible. The WC3 ME was often considered the "Engine" of the game.


My dream is to make an engine for my games which can be as extensible, modable and easy to configure engine as the WC3 Engine. Other examples from more recent games would be Starcraft 2 and Skyrim both also following DDD. Popular DDD engines are UnrealEngine (UDK) and UnityEngine (Unity). Some would argue Torque, but from what I understand it violates some of the core principles of DDD. Especially with it's heavy realiance on the scripting system that kind of developed into it's own programming language which is not part of DDD.


The problem I seem to have though, is where to start. I can't wrap my mind around how to execute this methodology in code. The engine needs to be very abstract so that I can make many different games with little to no edits in the engine itself. My goal is to first make a simple (at least in theory) 2D tile engine to follow styles such as that from Pokemon or A Link to the Past. Moreso the latter because it uses a tile system but got free movement in all 8 directions.


My second question is: Do you have any points on where to start?


I would use an already existing framework to make the engine and not make my own OpenGL bindings and such. Something like Tao or SFML.


So that is that. I hope we can have some good discussions in this thread and perhaps get together to get resources on these subjects as they are very sparse...from what I have tried to find any way!