View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Data Driven Design: Part 2

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

18 replies to this topic

### #1vipar  Members

Posted 24 July 2013 - 09:38 AM

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.

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

Edited by vipar, 24 July 2013 - 10:00 AM.

CEO of Dynamic Realities

### #2BloodyEpi  Members

Posted 24 July 2013 - 01:52 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#

Now to handle Components and Entities I use Managers. Some seems to call them Systems

System usually process components, your managers just hold them, I would make this difference because you will have more then one system running on your components.

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.

This sounds very OOP like, some people will probably tell you that components shouldn't inherit anything.

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.

I would try to do something which actually needs an ECS, in your case you could just write 2 functions, try something like one sprite is static the other one moves(see next point), or they should behave differently, so you can actually use your components and systems.

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.

You could split those 2 up, your movementcomponent would hold a vector, your positioncomponent a point.

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.

Edited by BloodyEpi, 24 July 2013 - 01:53 PM.

### #3vipar  Members

Posted 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.

Edited by jbadams, 26 July 2013 - 02:28 AM.
Trimmed unnecessary quote text.

CEO of Dynamic Realities

### #4ZeroBeat  Members

Posted 25 July 2013 - 11:34 AM

Hi, I still think you are over thinking/overcomplicating things.

What Josh Petrie advised on the other post was to try and finish a small complete game/s without worrying so much on the data driven design and ECS. Just concentrate on making the game. Like having a main menu, gameplay, sound, input and rendering. eg Pong,

After you have done this very small game, you would have learned a lot. Plus it would feel really great to finish something. My advice set a deadline of 48 hours to make it.

As the game is done it will have

- some way to render 2D sprites

- some way to play sound

- some way to hold entity information

- collision detection code

Hopefully the time constraint will help to make a game rather than thinking about class design. The code will be quite "ugly/hacked in/not very reusable/" in general. The entities would be defined in code and may have their own update and draw/play sound functions..Probably during development, ideas would have emerged like why not store the entity template in a file or use a component entity system to make things more reusable? Write these thoughts on paper to remember for the next projects.

As you start your second (again small project), some parts could/should be done better given the previous learning experience.

Eg. Maybe this time, it would be better to let the user set the game window's width/height, and sound from a file.

Also it could be a good idea to store entity information for each game state in a file so that its easier to play around/experiment during development.

For example something like MainMenu.txt: (can be XML or JSON)

//entity type       //X and Y positions

buttonplay         100 100

buttonoptions    100 200

buttonexit           100 300

levelone.txt:

enemy           100, 200

boss              800, 300

You would then have a factory system which will read the information from the files and generate the right entities. The game just became even more data driven

On the next project, you can take a step further and have the entity template information stored in files rather than hard coded.

And so on until things become even more generic. As you start 3/4th project, probably you would be able to re-use quite alot of your previous code.

Slowly you will build up a robust re-usable set of libraries to draw entities, manage them, play sound, have physics <<< ie you have a game engine

Additionally, making a bit larger games will become easier as you already have the tools/experience needed.

You are on your way to make ever better data driven engine with games to prove that its functional.

Probably you would also be thinking how to implement an entity component system (which you already trying to design hehe)

Like BloodyEpi said, there is no set pattern for Entity Component Systems. There are so many implementations and ways of doing it.... Generally there seems to be two thoughts:

1 - Components just hold data and have systems which operate on them.

2 - Components hold their own logic. Systems may store the components/call their functions.

End result is king here. If it works, it works. Nobody will really care when they play the game so don’t worry if its not the best thing in the world.

Implement it and see if it works. If it doesn’t try to improve it.

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.

By updating systems by type  (AAA..., BBB....., CCC.....) its possible to use parallelism and improve performance. Eg Physics System divides 2000 components in 5 threads. Each thread updates 400 components. Overall taking less time. Also its cache friendly (should be faster).

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.

What component systems allow is for minimal entity hierarchy by inheritance. Rather than using aggregation to develop entities, composition is used. This in turn keeps the entities more lean (as they have components which they need only) rather than extra blob which appears in deep inheritance hierarchy.

Overall the code base is easier to maintain, more reusable and adaptive to changes.

The system is build up of Entities which consist of Components, each defining a behaviour or attribute that the entity can have.

It may be better to split behaviour and attributes. By having some components with logic while others not, it can become confusing over time what should go where...

Think Single Responsibility Principle.

- Some systems will have no components. For example some of the systems which define the gameplay will just have some logic in them to check for game rules.

- How will you handle communication between components (if they have logic)  and systems?

- Also some components will need data from other components. How will they access it?

ECS are quite a complex beast to tackle hehe. Truthfully, the best way to get an idea if the system makes sense is to implement it. One great approach (imho) is to convert some small existing game/prototype from a hierarchy design to component based one.

(hope this is actually useful, off to work again hehe)

### #5vipar  Members

Posted 25 July 2013 - 01:39 PM

Hi, I still think you are over thinking/overcomplicating things.

What Josh Petrie advised on the other post was to try and finish a small complete game/s without worrying so much on the data driven design and ECS. Just concentrate on making the game. Like having a main menu, gameplay, sound, input and rendering. eg Pong,

[...]

(hope this is actually useful, off to work again hehe)

All of that is useful yes.

I just...I don't know. It's kind of annoying the frak out of me that I have to do this kind of..guerilla warfare on DDD before I should be able to get it. Why not use the tools I got from the past and design something? (Mind you I've already made small applications with SFML to just render a sprite on screen, handle basic WASD movement (not pretty Lol) and such smaller things. I want to try and take it a step further :3) Just try and make small designs, try and implement, iterate and continue? I mean sure, when you learned a new language and such you did it by trial and error. But can't we learn/work smarter than that when we get something new to tackle?

It's all Logic after all. It must be logically possible to dechipher this pattern/philosophy/methodology one bit at a time until I got a certain whole :3

I will take in what you said though. Good ideas for a newb like me ^^

Edited by jbadams, 26 July 2013 - 02:30 AM.
Trimmed unnecessary quote text.

CEO of Dynamic Realities

### #6vipar  Members

Posted 25 July 2013 - 02:27 PM

CEO of Dynamic Realities

### #7Alpheus  GDNet+

Posted 25 July 2013 - 03:20 PM

My interpretation of the downvotes is twofold. One, you're biting off more than you can chew. All of these acronyms: OOP, ECS, DDD take experience. Which means you should have a few years of actual software design and architecture under your belt before undertaking the newer paradigms. Two, another thing is that with software development is you learn more by doing, not just reading. Unfortunately, it seems you're wanting to do the opposite.
External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science

Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley

If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

### #8frob  Moderators

Posted 25 July 2013 - 03:38 PM

It looks like you are over-engineering a solution for a problem you don't really understand.

The process is not as complex as you make it out to be.

You open a file. If there is data you read in the object. Read in a header.  The header gives you an object ID and a size of the data.  You pass that to a factory method, which in turn passes the data to sub-classes as needed.  The result is a game object. Init the object, place it in the world, and continue to the next object.

Creating the factory method is just looking up the right constructor that accepts a block of memory or a file stream, and calling it.

Keep it simple.  Start with the simplest thing that works. After you discover flaws in the system or useful additions, slowly expand it as your system needs.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #9vipar  Members

Posted 25 July 2013 - 04:18 PM

My interpretation of the downvotes is twofold. One, you're biting off more than you can chew. All of these acronyms: OOP, ECS, DDD take experience. Which means you should have a few years of actual software design and architecture under your belt before undertaking the newer paradigms. Two, another thing is that with software development is you learn more by doing, not just reading. Unfortunately, it seems you're wanting to do the opposite.

I have already been programming for 2 or 3 years. Mainly in Java. Learned C# and have been using it for about a years time. I am a computer science student and finish my profession bachelor in January. I am not trying to use the expressions losely :/

All of the programming I've done though followed OOP and OOD. Hence I try to learn something different.

And yes you learn by doing. But with everything you do you'd most likely want to make less mistakes and get more actual results, right? Yes, you learn from making mistakes. But making less mistakes in favour of better results is beneficial right? That's at least why I read up on how to program in the first place so that I could understand what I was doing and then I also had an easier time solving my problems.

It would just be nice if those who downvote would tell me why they did so, so that I could take in their feedback and hopefully learn from it. I came here to learn. Downvoting me for "biting off more than you can chew" is quite silly.

It looks like you are over-engineering a solution for a problem you don't really understand.

The process is not as complex as you make it out to be.

You open a file. If there is data you read in the object. Read in a header.  The header gives you an object ID and a size of the data.  You pass that to a factory method, which in turn passes the data to sub-classes as needed.  The result is a game object. Init the object, place it in the world, and continue to the next object.

Creating the factory method is just looking up the right constructor that accepts a block of memory or a file stream, and calling it.

Keep it simple.  Start with the simplest thing that works. After you discover flaws in the system or useful additions, slowly expand it as your system needs.

I can understand this way of developing and that is also what I aim to do (Currently). I just can't really get my head around the actual implementation in code. That's all.

Edited by vipar, 25 July 2013 - 04:21 PM.

CEO of Dynamic Realities

### #10Washu  Senior Moderators

Posted 25 July 2013 - 04:42 PM

Sounds pretty simple to me... not sure why you're going to all the effort to significantly complicate it.

    public static class WidgetFactory
{
private static Dictionary<WidgetType, Func<WidgetType, Stream, Widget>> widgetCreator = new Dictionary<WidgetType, Func<WidgetType, Stream, Widget>>();

public static void AddWidgetType(WidgetType widgetType, Func<WidgetType, Stream, Widget> creator)
{
}

public static Widget CreateWidgetFromType(WidgetType widgetType, Stream data) {
return widgetCreator[widgetType](widgetType, data);
}
}


Edited by Washu, 25 July 2013 - 04:46 PM.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX

### #11Alpheus  GDNet+

Posted 25 July 2013 - 05:24 PM

Sounds pretty simple to me...

Take what he says with a grain of salt. He's been programming in C++ since it was C.
External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science

Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley

If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

### #12vipar  Members

Posted 25 July 2013 - 05:34 PM

Sounds pretty simple to me...

Take what he says with a grain of salt. He's been programming in C++ since it was C.

I kind of get the idea behind it. Just not something I could have made up.

CEO of Dynamic Realities

### #13Alpheus  GDNet+

Posted 25 July 2013 - 08:53 PM

I have already been programming for 2 or 3 years. Mainly in Java. Learned C# and have been using it for about a years time. I am a computer science student and finish my profession bachelor in January.

The helpful side of me knows that a good start but still not enough experience to really grasp what the paradigms do and when to use them properly. If I really wanted to scrutinize, I'd ask what major projects you been on and have written.

External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science

Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley

If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

### #14ZeroBeat  Members

Posted 26 July 2013 - 02:14 AM

I've already made small applications with SFML to just render a sprite on screen, handle basic WASD movement (not pretty Lol) and such smaller things.

Now build it up. Eg:

- Draw a box on the screen. Make it move. Add another box (enemy). Check for collision.

- Next show that the boxes have collided somehow on the screen (eg a new box is drawn on the screen).

Congrats you just made you first game.

(I would seriously put a time limit like 24/48 hours to finish it, even less. That way I hope your design paralysis wouldnt get in the way of doing stuff.)

It can be something like a 2D shooter with one level where you shoot at a incoming wave of enemies. It can be pong. Whatever it is, it needs to have sound, game states (main menu, one level), rendering, input, (hopefully collision), AI. Then make something else, then again.

That is the only way to see/experiance/understand game design. You will see how all the different aspects are connected together to make a game. As you make more small games you will start to understand why more advanced paradigms are needed and what problems they solve.  As you experience increases you will be able to actually make better designs as you will start to forsee upcoming problems using your past projects as a starting point.

It's all Logic after all. It must be logically possible to dechipher this pattern/philosophy/methodology one bit at a time until I got a certain whole :3

The pattern is loading data from files so less parts are hard coded. However without understanding the need for it, its pretty useless. The understanding part comes from experience.

I can understand this way of developing and that is also what I aim to do (Currently). I just can't really get my head around the actual implementation in code. That's all.

Because its like trying to force a solution for an unknown problem. Hint: It doesnt work like that.

I have already been programming for 2 or 3 years. Mainly in Java. Learned C# and have been using it for about a years time. I am a computer science student and finish my profession bachelor in January. I am not trying to use the expressions losely :/. And yes you learn by doing. But with everything you do you'd most likely want to make less mistakes and get more actual results, right? Yes, you learn from making mistakes. But making less mistakes in favour of better results is beneficial right? That's at least why I read up on how to program in the first place so that I could understand what I was doing and then I also had an easier time solving my problems.

Maybe this is the reason for your Design Paralisys. Some of my friends have the same problem coming from academia. They spend soo much time on design, wanting to build their first game. It will be perfect they say, telling me how these systems will fix all the problems. Guess what? When they actually start implementing them, they realise how worthless the designs are. What looks great on paper doesnt look so good when you start implementing it. On top, their systems are soo complicated, it actually makes things worse. Most of the time they cant even implement them hehe. So those friends start small/simple, increasing the complexity with each new game.

Dont worry so much about making mistakes, think about them as learning experiences. As I said End result is king here.

Like everybody is saying stop thinking and start doing hehe.

Edited by ZeroBeat, 26 July 2013 - 02:29 AM.

### #15vipar  Members

Posted 26 July 2013 - 02:53 AM

I can't just blindly do something. It's like asking a blindfolded person to make a card house. You know what you need to do, you just don't know how.

And we did spend a good time on design because designing a system ahead of time saves you a great deal of headache and frustration. I don't think I've done anything overly complicated in my initial post. And your idea is nice. I can do that with extremely inefficient and ugly code. I don't see how that teaches me much :/

Edited by vipar, 26 July 2013 - 03:00 AM.

CEO of Dynamic Realities

### #16ZeroBeat  Members

Posted 26 July 2013 - 03:26 AM

I am tryitng to show the importance of finishing projects.

Finishing projects makes a person better designer, not spending large time upfront on design with no project made beforehand.

Thats why I am trying to push you soo much to make a smal game like Josh did. Then to make another. With each new project, not only will the code become better, you will also start to realise why ECS, DDD, OOP...ect is used when developing games. How they help improve the code base and make it more re-usable code.

In a sense its like driving a car. Its possible to imagine what it will be like beforehand. However when you actually start driving, new problems occur. Things were not as they seemed they woud be. Imagination can only take you so far.

Edited by ZeroBeat, 26 July 2013 - 03:31 AM.

### #17vipar  Members

Posted 26 July 2013 - 03:35 AM

I am tryitng to show the importance of finishing projects.

Finishing projects makes a person better designer, not spending large time upfront on design with no project made beforehand.

Thats why I am trying to push you to make a smal game like Josh. Then to make another. With each new project, not only will the code become better, you will also start to realise why ECS, DDD, OOP...ect is used when developing games. How they help improve the code base and make it more re-usable code.

In a sense its like driving a car. Its possible to imagine what it will be like beforehand. However when you actually start driving, new problems occur. Things were not as they seemed they woud be. Imagination can only take you so far.

But with that analogy we both agree on one thing: Theory before practice.

Theory and Practice doesn't always follow each other, which we also agree on.

It just baffles me that I am almost shunned for trying to design something simple before putting it into code :/

"Shame on you, you designed something instead of just coding. How dare you. So complicated." This is the feeling I am getting. It's not helpful at all.

The other things you said about how to do the small projects and advance, I can get behind that. Just how to do it bothers me. When I iterate over my software I usually have someone by my side (like a teacher) to consult with. When I consult here, which I did above, I am told that everything I do, is just wrong and over complicating things. And I kept being told so instead of concrete examples on why what I do is wrong and why what you suggest is right.

CEO of Dynamic Realities

### #18ZeroBeat  Members

Posted 26 July 2013 - 06:42 AM

Hehe, you have a very interesting idea for simple.

With that analogy, I was trying to say that, imagination(theory) can only take you soo far. Practice is more important as it shows how stuff really is...Too much time spend on theory is not good (like in this case) as people generally learn by doing. Sorry, I am really bad at explaining things .

The other things you said about how to do the small projects and advance, I can get behind that. Just how to do it bothers me.

When you have developed something, don't you get a feeling like: I could have done X differently. Maybe by using Y it would have been a better idea. If I do Z next time not W, things could work out better. Listen to your gut feelings and try new ideas for your next project/s. Experiment.

Unfortunately there will not be always somebody to help along this all the time.

GameDev.net practicies a bit of tough love. Hehe. I am sure we are all just trying to help

I am quite positive that if you try to make the engine now. For one it will take you very very long time. As you said, you are not sure yet how systems will fit together. It will be such a massive project. There will be a lot of new things to learn. Learning new things generally takes alot more time. It may be soo hard, that I am quite sure that you would give up. There will be massive revisions as well. As you learn more concepts and implement more stuff, the want to revisit and improve old parts will be quite high too...

If you actually finish the engine and try to use it, you would probably realise that its over engineered and not useful at all.

(I actually wished you realised this yourself, rather than spelling it out so plainly:)

Now imagine that you spend the same amount of time by making games. The goal is still the same: 2D tile generic engine.

You just made you first game. Took you a day or two. Yes, its not the prettiest code. However you made it. Now you have some idea how to handle game state, collision, rendering, input. How they all connect together to make a complete experience.

case MainMenu:
PlayButton.Update()
PlayButton.Draw()
ExitButton.Update()
ExitButton.Draw()
break;
case GamePlay:
Player.Update()
Enemy.Update()
CheckCollisions(Player, Enemy)
Player.Draw()
Enemy.Draw()


Yes, the above is stupid simple, However every game has a gameloop, render, input, physics, ai.

Now you are starting your second game. You realise that the above code is not very reusable. What if you wanted to have more enemies?  We have an actual problem to solve. You may search online/ask teatchers and get some advices.  Then you actually try them out. See what works for the game you are making. There is no right/wrong here. If it works great.

Maybe by your third game your entity hierarchy is a monster like this:

Basic
- Rendable
- Movable
- Collidable
- Flying
- Boss
- MegaBoss
- SuperDupperMegaBoss


On your next project, you realise that the cool MegaBoss cant really be adapted to your new project. As the game was developed, you realised that maybe the entities or the code will not be very reusable next time. Hell it was a bit hard to work on it as it was, such a large hierarchy. You have heard of ECS which can actually fix this problem.

This in turn helps you appreciate what ECS is about. So you make a smaller game/project or convert an existing one to use components. Small = less things to worry about

Now the next project uses the ECS developed beforehand.

Given the experience of using your own system, you realise that some parts can be improved. So you go and do that before starting next project.

Maybe next time, scripting will be added.

On the next game, even more parts are stored in file. eg the game name, window measurements,

Because each new concept is tackled seperately, rather than simultaniously, it would be much more fun(motivating) to program and much less frustrating.

Not only will you have finished products to show (which will feel great and motivtional). With each game your base framework will improve more and more until its the 2D generic tile engine you wish to make.

I really hope this actually explains it finally.

Edited by ZeroBeat, 26 July 2013 - 06:49 AM.

### #19vipar  Members

Posted 26 July 2013 - 07:07 AM

Hehe, you have a very interesting idea for simple.

With that analogy, I was trying to say that, imagination(theory) can only take you soo far. Practice is more important as it shows how stuff really is...Too much time spend on theory is not good (like in this case) as people generally learn by doing. Sorry, I am really bad at explaining things .

[...]

I really hope this actually explains it finally.

Much appreciated.

When I said "How to do it", I meant the coding part. Should have clarified that.

The rest, I understand. I understand the importance of small programs advancing into bigger things.

Edited by jbadams, 26 July 2013 - 07:22 AM.
Trimmed unnecessary quote text.

CEO of Dynamic Realities

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.