• 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
RLS0812

Am I Over Thinking This ?

14 posts in this topic

I have been working on a parent class that will handle every interactive item that will be generated on the map, however I think I may be "over thinking" this a bit too much - or maybe I am not abstracting it enough.

 This class will handle trees, rocks, plants, and mining nodes - what do you think ?


public abstract class InteractiveObject {
	static String defaul1 = "Error";
	static String defaul2 = "E";
	static int defaul3 = -1;
	
	String name;
	String type;
	String inspect;
	String skill;
	String tool_required;
	int tool_quality;
	int tool_damage;
	int skill_level;
	int health;
	int regen;
	int experance;
	int rarity; // Chance to spawn on map ( x in 10000 )
	String[] state = new String[2];
	//LootNode loot;
	
	public InteractiveObject(){
		name = defaul1;
		type = defaul1;
		inspect = defaul1;
		skill = defaul1;
		tool_required = defaul1;
		tool_quality = defaul3;
		tool_damage = defaul3;
		skill_level = defaul3;
		health = defaul3;
		regen = defaul3;
		experance = defaul3;
		rarity = defaul3;
		state[0] = defaul2;
		state[1] = defaul2;
		//loot = new LootNode(defaul1);
	}
	
	public String getName(){return name;}
	public String getType(){return type;}
	public String getInspect(){return inspect;}
	public String getSkill(){return skill;}
	public String getToolRequired(){return tool_required;}
	public int getToolQuality(){return tool_quality;}
	public int getToolDamage(){return tool_damage;}
	public int getSkillLevel(){return skill_level;}
	public int getHealth(){return health;}
	public int getRegenerationRate(){return regen;}
	public int getExperance(){return experance;}
	public int getRarity(){return rarity;} 
	public String[] getStates(){return state;}
	
}

1

Share this post


Link to post
Share on other sites

you'll get 2 advantages from loading that initialization data from a file:

 

1. people other than the coders can change the data.

 

2. no re-compile required when you change the data.

 

the slick way to do it is to alt-tab out of the game, edit the data file, then use a menu pick in the game to re-load the data file without quitting the game. or better yet, build the data  file editor into the game itself - but this might be overkill, depending on the game and the complexity of the data.  constant values for object type definitions like you're dealing with can easily be handled with a simple text file.  for something more complex like a heightmap, an internal or external editor would probably be called for.

 

as for the "all-in-one"  objecttype struct, i often debate this issue myself when starting a new title.  all in one is appealing in its perceived simplicity, but can be inefficient in terms of memory usage, cache friendliness, etc. due to unused variables.

 

some unused variables are ok. but its usually better to divvy things up into groups with similar sets of variables.

 

composition and components can reduce / eliminate unused variables, by giving you multiple simple struct types to work with.

1

Share this post


Link to post
Share on other sites

and definitely use #defined constants or enums instead of strings where possible. much faster. note that enums may have some type checking overhead that #defined constants don't have.

0

Share this post


Link to post
Share on other sites

Your class will end up being much bigger than that. The class would end up being a  World Class in that case. 

 

You have the world, and then you have things in the world. Those things can be sectioned off into different classes. You have the class of Humans and the class of Fish, and the class of trees. Each class is, in its own respect, is very detailed. You have so many different kinds of trees, with various unique properties. 

 

Now, you have one class handling rocks and trees and plants and... get the point? 

 

If you break down your classes and use inheritance for certain things, then it will make adding to the class easier in the long run. Also, your classes would be more re-usable for future things. 

 

Perhaps you want trees in your next game, but not rocks?

Edited by Tutorial Doctor
0

Share this post


Link to post
Share on other sites

Your class will end up being much bigger than that. The class would end up being a  World Class in that case. 
 
You have the world, and then you have things in the world. Those things can be sectioned off into different classes. You have the class of Humans and the class of Fish, and the class of trees. Each class is, in its own respect, is very detailed. You have so many different kinds of trees, with various unique properties.


I think this is bad advice.

I don't really enjoy extreme programming, but it has one principle I stick to: "You aren't gonna need it." http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

Basically, don't add features for the future. Add features and refactor for the present. This rock/tree thing is a great example. If I made a game, at the beginning, there's probably not really any difference between a rock and a tree. They're both just parts of the scenery - two immobile objects with different 3D representations but the same code. So why should I make a Rock class and a Tree class right at the beginning? Maybe I'll be able to mine rocks and chop down trees, but that could also just start out as different values in a couple of variables - which tool type works, what material comes out, etc. - exactly like the OP describes. We could argue about data types and minor details but the general idea is there. Why make two classes? It doesn't gain me anything for the present.

If it gets to the point where there are differences between rocks and trees, they can be refactored into two separate classes. There's not much point in doing it earlier.
 

Perhaps you want trees in your next game, but not rocks?


Maybe I want traffic cones and mailboxes in my next game, and the generic InteractiveObject would work for those just fine by itself.

Edited by jbadams
Fixed broken link.
0

Share this post


Link to post
Share on other sites

They're both just parts of the scenery - two immobile objects with different 3D representations but the same code. So why should I make a Rock class and a Tree class right at the beginning?

 

Good point, if that is the case, certainly they can go to one class. But then why are mining nodes apart of that same class? In the class you see all sorts of properties and stuff. If rocks and trees are not using any of those properties, then perhaps they should be separated out. 

 

There would be one class for "Scenery Objects" and another for objects that can be interacted with. If they can be interacted with in the same manner (as in something like minecraft) then again, they could be in the same class. And I guess the mining node would fit if it is interacting with the rocks and trees. I guess it depends on the game. 

Edited by Tutorial Doctor
0

Share this post


Link to post
Share on other sites

 


I don't really enjoy extreme programming, but it has one principle I stick to: "You aren't gonna need it." http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

 

I've fixed the link for you:

Not quite...

The apostrophe breaks the link, even when using the forum's Link button. Using an alternative link works:

Fixed.

 

Otherwise, typing it in manually you can make it work, though:

[ url = http//etc ] Clicky[ / url]

Clicky

0

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