Object factory design?

Started by
5 comments, last by swiftcoder 10 years, 9 months ago

Every thing in my game world is an Entity, Entity is not derived from anything and has no derived classes. What makes a projectile different from a player, different from an enemy, different from an inanimate object, is what that entity has. Each Entity has a list of components that it owns. Some components are graphical, some are physical, some are AI components, some are control components(takes player input), ect.

I'm trying to use inheritance as little as possible and use a data driven approach. Component is the only class currently that has any derived classes, the 4 I mentioned above. Entity types are defined in a txt file, which is as simple as listing a type name, which components that type has, and any raw values those components may need.

I have a EntityBuilder class that I want to work like this. It first reads that txt file and stores 1 of each type. Then when the worldManager needs a new anything, (projectile, enemy, box, ect.) it asks the Entitybuilder for a new Entity of "type x" Then the builder looks through it's list of types and and if it finds one that matches that type name it copies it and passes it to the worldManager. Entity and and each Component implement a copy function, so the EntityBuilder simply calls that copy function on the matching entity(which in turn calls it on each of its components). In this way I hope to be able to design new stuff for my game world without changing any code and just editing a txt file.

I'm not sure if there and actual question in there, maybe just looking for feedback. Also I'm a bit rusty with my design patterns, is this the a factory or prototype pattern?

Advertisement


I'm not sure if there and actual question in there, maybe just looking for feedback.

It sounds good, in general.

Also I'm a bit rusty with my design patterns, is this the a factory or prototype pattern?

Does it really matter?

Design patterns are guidelines, at best. They aren't meant to be followed rigidly.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]


I have a EntityBuilder class that I want to work like this. It first reads that txt file and stores 1 of each type.

this is essentially loading the "target types database" from text file(s). this will let you define new target types without recompiling, at the cost of a text file load at program start. but you'll only be able to create new target types from existing components (such as AI). if a new target type has a new type of component, that functionality will still have to be added in code.

once your design matures, you'll have all your target types defined and your components implemented, and your text files wont really change any more. so in that respect, there's really no advantage. it lets you tweak values while your dialing in the game without recompile, that's all. and the definition of a target type doesn't really get tweaked. more or less you'll define it once and that's it. maybe you'll go back and add a new component you just implemented. probably easier to just init the target types database in code than the extra overhead and complexity of a configurable text file for what is essentially hard coded data.

OTOH, if you're building a game engine to be as as generic and configurable as possible (to the point of overkill), you'll want to load everything and hard code nothing. even stuff like "a character object has a hit_points variable".

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

Little projects it might be overkill, but if your project grow bigger. The value of data driven architecture get higher. As recompile time gets longer.

Tweaking a text value is faster then a recompile of a changed hardcode value. the value in it is of matter the trade off performance for it.

Also it reduces a lot of communication between. Programmer vs artist script programmers. It helps productivity in larger teams.

It is even faster if settings could be changed under runtime.


Little projects it might be overkill, but if your project grow bigger. The value of data driven architecture get higher. As recompile time gets longer.

quite true.

i believe the term you want is "soft coding of data", not "data driven architecture".

i'm currently re-doing the first person attack animations in CAVEMAN for the third time. for each one, i need to position the arms and weapon relative to the camera (the player's eyes). the values are essentially constants. a compile is just 5 seconds, but each link of the game takes 55 seconds (70,000+ lines of code).


It is even faster if settings could be changed under runtime.

i've made a mesh/model manipulator routine that i can hook up to the arm mesh(es) and weapon mesh/model in a given animation with one or two lines of code, and manipulate them in real time in the game then i write down the constant values and go back and hard code them into the game. these constants are only changing because i switched to a higher quality arm mesh, which i do not plan on changing again before release. i have contemplated going to soft coded values but i only have about 30 weapons left to go, and making the game run slower to load soft coded values because i'm too lazy to wait around for rebuilds of hard coded values is not acceptable. arm animations are shared between appropriate weapons, so i only have to tweak a dozen or so of them, almost all of which have been done by now. so really all i have to do is adjust 30 weapons. and with the manipulator i can do 10 at once per recompile. so theoretically i can do it all with just 4 builds.

the alternative would be to "softcode" it. load the constants from disk. requiring a data structure to hold the constants, code to load and save, and code to apply the rotation and translation constants to the animations. i already have the manipulator to edit the values.


Also it reduces a lot of communication between. Programmer vs artist script programmers. It helps productivity in larger teams.

as is often the case, the size and talents (or lack thereof) of the team can dictate certain necessities. such as soft coding things so you don't need a programmer, a compiler, and source code to make changes.

for a single developer who its not building a extensible engine, but merely a single game, there will be places where soft coding is more efficient (stuff that changes), and places where hard coding is more efficient (stuff that doesn't change).

over-softcoding is actually considered an anti-pattern of sorts, due to unnecessary complexity.

an example of overkill might be a separate soft code system just for things like the rate of acceleration due to gravity, or the distance from the sun. "oh yes! we must soft code those! just in case the earth's mass or orbit changes!". <g>. yeah, right. not bloody likely during the life cycle of your project.

note that if i had soft coded the size of the mesh/model manipulator, instead of hard coding it to 10 transform matrices, i could change a text config file and the manipulator would automatically handle all 30 remaining weapons at once. this is an example of the power of soft-coding data. of course i'd still have to recompile once to make the animations use the manipulator, and once again to enter the hard coded values once i wrote them all down.

i once did a space fighter game where much of its was soft coded. it had lots of editors. a campaign editor, a mission editor, a ship editor, even a weapons system editor (design your own weapons for the ships).

sometimes when starting a game, i consider soft coding everything vs hard coding. but in most cases, for me, its not the most efficient way to get things done. i tend to build games with custom one-off engines, not generic multi-title engines, so soft coded reconfigurability of the game's "engine" is usually a low priority. OTOH, there are some places where softcoding is definitely the way to go. any loadable content is an example of softcoded data. mesh vertices, wave bytes values, texture bitmaps, script logic, level maps, all could be hard coded in the final release version, unless you care about MOD-ability.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

I think, this approach is only interesting for development. After some time this values won't change anymore.


I think, this approach is only interesting for development. After some time this values won't change anymore.

Depends on the game. For a game that receives updates after launch, they may keep changing indefinitely.

Pretty much every MMO and competitive multiplayer game gets balance patches post-launch. At times Blizzard re-balances their games weekly...

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement