• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
BUnzaga

Data Driven Game Architecture - examples?

10 posts in this topic

I have been programming for a few years now, self taught for the most part, and have been able to understand quite a bit on my own, but I am having a hard time wrapping my brain around a 'proper' data driven architecture for game development.

For a while now, I have been sort of moving in a data driven direction, subconsciously, but have only now recognized it for what it is, and would like to learn more about it, and take full advantage of using a data driven approach.

For example, say I am doing a tower defense game... From what I understand about the data driven approach, I would essentially have an array of entity ID's, which other tables would reference for the individual 'data' pertaining to each entity. I would then have methods which I would use to manipulate this data (separate from any 'Object')...

What I don't understand... is what about the finer details? Like say I have a Poison Tower, which does AoE damage per tic. Then I have a basic Pea Shooter, which shoots a strait bullet at the 'oldest' creep x times per second. Finally lets say there is a Snare Tower, which will slow down creeps within a set radius around the tower.

So obviously there is common 'data' between these towers, such as x/y position, active/inactive, radius of influence, price to purchase, price for upgrades, etc. This 'common' data could all be managed using the same methods, but what about the more uncommon information? Do I create a separate method for each individual tower type, or do I use a switch to determine the type, and handle the 'special conditions' within the main method?

From an OOP approach, I would create a base Tower Object, and derive each new tower type from the parent, using overloaded functions, or adding additional functions if needed.

To be more specific... When every tower is created, the user needs to decide on the X, Y position, probably with a mouse or finger. Every tower needs this, so it would go in the generic 'tower creation system'. When the user buys an upgrade, the data can be taken from the table, and it is the same for every tower. On the other hand, when it comes time to scan the oldest enemies in the towers radius of influence, and then deciding on if it should shoot a bullet, apply a poison, or reduce speed... is this handled by the same system, or should I create a separate system for each TYPE?

What about in games where there are SEVERAL different types of enemies... Does each enemy type need its own 'system', or do I just make one big system, and use a switch to manipulate the data appropriately?

I really like the data driven approach, and like I said, every time I would write individual onHoverBegin, onHoverEnd, onClick, etc for each button in my UI, I would always tell myself... "There has to be a better way for this". Now I realize a data driven system is exactly what I was looking for, now I just need a bit of help understanding it on a 'personal' level.

Thank you in advance. Yes, I have used google, as well as the search field on this website, but if you can find something I missed, I am more than happy to check it out!
0

Share this post


Link to post
Share on other sites
I struggled with this at first but found the data driven architecture to be quite nice. I have the basic Object class which you can attach any number of different types of attributes too. These include mesh/materials, variables, lights, particle systems, rigid bodies, etc. Attributes are user create-able too so you can attach any number of your own attribute types to the object. These can be used and manipulated in the specific game code, outside of the engine. One other thing you can do is attach a lua script to an object which has the ability to manipulate the object directly. Obviously some things need coded specific to the game itself, but most things can be accomplished with a flexible attribute system. I know this still sounds like a tangle web, but I invite you to just try coding a simple prototype... I think you'll find it easy to get through once you start. My code is on github, feel free to take a look. Here's a starting point: https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Game/ObjectAttribute.h
1

Share this post


Link to post
Share on other sites
[quote name='BUnzaga' timestamp='1349074597' post='4985657']From an OOP approach, I would create a base Tower Object, and derive each new tower type from the parent, using overloaded functions, or adding additional functions if needed.[/quote]OOP != inheritance. Composition is a much bigger part of OOP than inheritance is, and use of inheritance should actually be quite rare in OOP.

For something as small as Tower Defense, you could keep it pretty simple, with structures that can be loaded from data files fairly easilly:[code]struct ProjectileType
{
int speed;
int splashArea;
enum SplashType
{
Damage,
Slow,
Poison,
} type;
int amount;
};
struct WeaponType
{
ProjectileType projectile;
int shotsPerSecond;
};
struct TowerType
{
vector<WeaponType> weapons;
};


struct WeaponInstance
{
int timeOfNextShot;
void Update(WeaponType&, int time, int x, int y);
}
struct TowerInstance
{
TowerType* type;
vector<WeaponInfo> weapons;
int x, y;
void Update( int time )
{
for(int i=0, end=weapons.size(); i!=end; ++i)
weapons[i].Update( type->weapons[i], time, x, y );
}
}[/code]If you're working on a larger game, or a Tower Defense type game where you're adding new weapons and projectiles with new behaviours every second day, then the enum+switch will become a bit bloated, so you could turn [font=courier new,courier,monospace]ProjectileType[/font]into an interface, with an [font=courier new,courier,monospace]OnHit[/font] function/etc... You'd then likely use the factory pattern, so that in your data files you can write "PoisonProjectile" as a string, and the factory will turn that string into [font=courier new,courier,monospace]new PoisonProjectile();[/font] when loading the data.
0

Share this post


Link to post
Share on other sites
If I were doing this, I would have a Towers XML file which defines the towers with image/animations, cost, upgrade costs, and weapon type(s). I would then have a separate weapons xml file which defines all the weapons a tower can use, what it's upgrades do, the image/animation, etc.. In code, I would have Tower be an component of a Tower entity,and also contain a Weapon Component, which defines the weapon it uses. When it's time for the tower to fire, it generates a new entity which is defined by the weapon.
1

Share this post


Link to post
Share on other sites
The core of data driven system is that objects are initialized by a data descriptor object be they data from XML, scripting, internally, etc.. This initialization chain follows all the way down to all the child objects. Objects themselves are not usually created on demand but rather by a factory due to the complexity of creation in data driven designs.

A data descriptor is just a unified data accessor class which makes it simple for data access and accounting. Imagine if u will an object definition is a tree and iteratiring down the tree to create all the components and child components, you'll need to keep track of that iteration as well as have data accessors to make sure data conforms to both read / write access.

Data driven design can be as simple or complex as you like but the drawbacks with such a system is that u have to have runtime checks for validity and data and class integrity which can increase the burden of testing and maintenance. So people usually write tools to manage this for them, when the data set becomes too large. Another common design pattern for data driven system is to use object composition vs inheritance to create complex objects but that's really just user preference and both can co-exist.

Good Luck!

-ddn Edited by ddn3
1

Share this post


Link to post
Share on other sites
[quote name='BUnzaga' timestamp='1349074597' post='4985657']
So obviously there is common 'data' between these towers, such as x/y position, active/inactive, radius of influence, price to purchase, price for upgrades, etc. This 'common' data could all be managed using the same methods, but what about the more uncommon information? Do I create a separate method for each individual tower type, or do I use a switch to determine the type, and handle the 'special conditions' within the main method?[/quote]
You add that information via composition. Composing common data is trivial, as you have observed, but then you also need to compose the differing functionality under a common interface.

[quote name='ddn3' timestamp='1349127852' post='4985878']
drawbacks with such a system is that u have to have runtime checks for validity and data and class integrity which can increase the burden of testing and maintenance[/quote]
Otherwise known as comprehensive unit tests and functional tests, both of which you [b]should have already[/b]. I hate to harp on it, but code without tests is broken code.
1

Share this post


Link to post
Share on other sites
[quote name='BeerNutts' timestamp='1349122894' post='4985858']
If I were doing this, I would have a Towers XML file which defines the towers with image/animations, cost, upgrade costs, and weapon type(s). I would then have a separate weapons xml file which defines all the weapons a tower can use, what it's upgrades do, the image/animation, etc.. In code, I would have Tower be an component of a Tower entity,and also contain a Weapon Component, which defines the weapon it uses. When it's time for the tower to fire, it generates a new entity which is defined by the weapon.
[/quote]

Brilliant, I hadn't thought of doing it that way. :D

Thank you all for responding, by reading through these responses, I am starting to see the 'bigger picture'. ddn, I like that way of thinking: instance vs composition. I really do feel like the data driven way of doing things fits in well with my own mentality, and like PaloDeQueso said, I'll just have to stop thinking about it, and start working with it for it to truly become natural.

Any other advice or insight is welcome!
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1349129805' post='4985890']
Otherwise known as comprehensive unit tests and functional tests, both of which you [b]should have already[/b]. I hate to harp on it, but code without tests is broken code.
[/quote]

I think TDD has it's place, but for smaller development houses where it's just 2-3 programmers you have to make do with what time you have. Sure for larger teams where it's critical that components function to specification and teams are separated by timezones u don't want to mess around with email tag trying to get core critical systems working. For individual developers its up 2 u if you want to do TDD and to what extent. I find for individual developers code maintenance becomes a much larger problem, try looking at code you wrote 3 years ago for example..

-ddn
1

Share this post


Link to post
Share on other sites
[quote name='ddn3' timestamp='1349142937' post='4985925']
I find for individual developers code maintenance becomes a much larger problem, try looking at code you wrote 3 years ago for example.[/quote]
And I say again: you should have tests. Tests are the best defence against code-rot.

Tests not only validate that your code from 3 years ago works, it also validates that it does what it says on the tin. And given that your code is either documented, or self-documenting (it is one of the above, right?), it should be a breeze to pickup your 3 year-old code...
1

Share this post


Link to post
Share on other sites
Personally I think its personal choice for individual developers. It depends on why you code. For me i code for experimentation and play, when I develop code when on my own time to experiment with things, there really is no need for TDD since by the thesis of the code itself, i am pushing the bounds and i want it to break, I know it will break. For work yes I've used TDD when working with larger teams but for small teams the payoff isn't as great as the limited manhours become an overriding issue. But I'm willing to give it a go and see if TDD does have any advantages for the individual developer, maybe i'll use it on my next library.
0

Share this post


Link to post
Share on other sites
I kind of agree, it depends on what you are doing. If you simply experiment with something and maybe throw it away later, then there is no reason for unit testing.

Even if you program only for yourself, if it may happen that you have to fix bugs, if it may happen that you refactor years old code, if it may happen that people want to know how far you are with your new version, unit tests are the way to go. Tracking down a bug that was introduced in a new version can be more time consuming than writing unittests.
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0