Messages

1

Game Development / Re: Unity in general

« on: May 02, 2013, 08:15:21 PM »

This may be an out of left field sort of question but I am really curious how you guys handle the scene/level limitations of Unity. What little I have learned to do makes pretty significant use of gameobject scripting and the level editor, but I get the impression you barely utilize either.

How do you manage that?

And what happens when you complete your work? Do you build it from the unity tool set as though it where a normal project?

I hope I am not asking you something that has already been answered.

2

Game Development / Re: How are you handling Serialization with Unity3D?

« on: October 05, 2011, 02:09:46 PM »

I hope this is not an unusual question...

I have decided I will use C# standard DataContractSerializer for my needs until my needs change. Now I am thinking how I will pick and save the data.

I am thinking an easy way to contextualize serialized files is by game level (map, region, what have you). Thus when entering a map, the collection of serialized objects for that map gets checked and instantiated as necessary. But this also means that each object will either need to be individually serialized, or added to a collection for group serialization.

How do you handle this?

3

Game Development / Re: How are you handling Serialization with Unity3D?

« on: October 03, 2011, 09:44:14 AM »

You're not particularly annoying me.  But, the questions lately have boiled down to two categories: 1) things that really are a matter of opinion and that everybody does differently and that I don't have any reason to try to convince you to do my way -- it would be a disservice to you and a waste of my time; and 2) things that are fairly basic programming questions that most professional programmers should be able to answer.

I'm happy to answer questions when I can, but I don't have any desire to convert you or anyone else to my exact methodology of doing things, or to teach C# 201, or to get into lengthy debates of any kind.  I spend most of my time trying to avoid getting into such discussions at this point, as they rarely serve any purpose as nobody comes away convinced of anything most of the time.

Point(s) taken.

It did not occur to me that someone who has been programming for a living wouldn't exactly be as excited as I am about the possibilities of code use... 

Makes me want to laugh at myself for my naivete.

I shall endeavor to be less obtuse with my future inquiries! 

4

Game Development / Re: How are you handling Serialization with Unity3D?

« on: October 03, 2011, 08:57:32 AM »

Fair enough.

I am getting the impression that I am beginning to annoy you.

I understand that you are busy and I really do appreciate the attention you are giving me. I hope I an not squandering it with pointless questions, only to lose it when I have good ones.

5

Game Development / Re: How are you handling Serialization with Unity3D?

« on: October 02, 2011, 11:10:15 PM »

There is no game that saves all the data as-played in the sense you seem to mean.  Data isn't just streamed to disk or anything.  Regardless of whether a button is pushed or a timer is tripped inside the game program, and regardless of whether or not the entire game state is saved or only art of it... a function moves some data to disk, that can later be read back.  That's it.

I seem to have said something wrong.

I did not mean to imply that any game state is ever fully saved, or fully streamed. Only that the data to be saved (for whatever reason) is traditionally done in a single step (such as pushing 'Save Game') or in an 'as played' step where it occurs almost immediately after savable data is available.

In terms of starting a new game or loading a savegame, the difference there should be minimal.  The amount of code for starting a new game or loading a savegame are both trivial compared to the amount of code for actually running the game, which is the same in either case.  It's like walking in your front door or your back door; yes, both are different -- this is obvious, but you get into your same house either way.  And those doors are just a very tiny part of the complexity of your whole house.

Again, I seem to have said something wrong as that is essentially what I was trying to say.

Just to reiterate for the sake of clarity…

When the game starts the relevant data is either retrieved (from a serialized location), or created (from new processes), based on whether or not it’s a saved game that’s starting, or a new game. Even if that data is nothing more than the player name and location, a saved game places them where they last exited the game and a new game places them where all new game players start… In the end, it is the same game that is running.

In more complex scenarios the developer must consider if any serializable data is relevant upon any player action.

Such that, entering a room will always check for the serializable variable that says if it’s been entered or not already. A new games flag is unset, where the saved games flag is. The question becomes when that flag is to be serialized.

Did I explain that clearer?

Note: I sometimes tend to get a bit esoteric when talking about things I am new too and I apologize if I complicate these conversations as a result. I am sure that once I get more familiar with the normal programming parlance it wont be as much of a head ache to deal with my questions... 

6

Game Development / Re: How are you handling Serialization with Unity3D?

« on: October 02, 2011, 10:32:32 PM »

Pardon me if this is a bit too academic but I want to make sure that I am not confusing anything in regards to the big picture of serialization as it relates to developing saved games.

Essentially when a game has the option of saved game starts, it has two movements that end in a running game.

Movement #1: Starts a game from scratch. The game program begins to run and fills the spaces with new data.

Movement #2: Starts a game from saved data. Some, usually not all, of the program is filled with retrieved data, the rest with new data.

Thus, when you write the program you are writing two start-up processes that end in the same playable state, the difference is where the data originates.

Most games serialize the savable game data  when the ‘Save Game’ button is pushed. While others serialize the data as the game is played. Either way accomplishes the same goal (saving data for later) but only the ‘as played’ version allows for more complex game play scenarios where the world can be effectively endless, as its saved and restored as needed.

I can only guess that the push button & save game version is less prone to corruption? But also more prone to lost game time as if you forget to push ‘save’ you lose the time since the last one.

Keeping this in mind, the developer must decide which is more reasonable to implement. Or even necessary.

Am I mistaking something?

7

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 30, 2011, 05:33:30 PM »

Fair enough, there's more than one way to do stuff.  My experience is that the less code you can write to do something, the better, though -- especially in the long term.  "What is the briefest, most concise, least-operations-using way I can write this?" is always my question to myself.  But Keith and I are performance tuning addicts.

I am sure I will be too once I get a better idea how to make things work the way I want.

Though I don't want to give the impression that I will be stuffing local variable banks on every object in the game or anything. Just that I like having options available in case I find a need.

Please keep critiquing me, I need to keep myself thinking. And the best way I have found to do that is my engaging others. 

8

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 30, 2011, 04:42:42 PM »

I think you're over-generalizing.  Also, indexing by strings is incredibly slower than by enums.  String comparisons are wicked slower than enum comparisons, and the comparison time varies by the length of the string.

Thanks, I had not considered searching for speed deference in key types.

You don't need some fancy data structure to store data in so that you can later serialize it.  All you need is just regular variables.  Then when it comes time to serialize, your serialization code needs to automatically write those variables.  Look at how microsoft ISerializable classes tend to look.  You don't have to use their serialization method (in fact I recommend not), but their general structure is fine.  What you've got in the code you posted is just going to add slowdown and memory bloat -- take out the middle man.

My thinking behind this is to have the option of creating the local variable storage in case I wanted to quickly add a repository of data somewhere for some reason. Say, for custom scripting later on. My inexperience in large projects means that I am pretty clueless as to what I need to have ready for later, so having a general place I can store and retrieve data when I want might help me speed up the prototyping as well. Of course, hard data would be turned into regular class variables once ironed out.

I am still kind of getting used to using collection type functions. All my previous scripting experience was absent these data structures (even arrays). Thus I had to concoct very elaborate ways of storing and retrieving data...  Now that I have free reign to use them I am sure I will get a bit carried away until experience tempers my lusts. :p

9

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 30, 2011, 03:23:20 PM »

I am paying around with Dictionaries to create a local variable system so I can store/retrieve data on objects that have the script component available, and I was wondering about anyone's thoughts on its feasibility.

Essentially, when run, the script creates up to four Dictionaries Int, Float, String, and Object types, with string Keys. (I may change that to an enum). This is primarily to save serializable data for that whole (data, manipulator, projector) thing I talked about.

I tried using the dictionaries via a generic methods but must be doing something wrong, so I created specific methods for each. (Clipped the extra get/set's to shorten it)

Code: [Select]

public class LocalVariables : MonoBehaviour
{
private Dictionary<string, int> localIntDictionary;
private Dictionary<string, float> localFloatDictionary;
private Dictionary<string, string> localStringDictionary;
private Dictionary<string, object> localObjectDictionary;

[HideInInspector]
public bool disableLocalIntegers, disableLocalFloats, disableLocalStrings, disableLocalObjects;




// Use this for initialization
void Start ()
{
if(!disableLocalIntegers)
{
localIntDictionary = new Dictionary<string, int>();
}
if(!disableLocalFloats)
{
localFloatDictionary = new Dictionary<string, float>();
}
if(!disableLocalStrings)
{
localStringDictionary = new Dictionary<string, string>();
}
if(!disableLocalObjects)
{
localObjectDictionary = new Dictionary<string, object>();
}
}

void Update()
{

}


#region Base Getters/Setters
private void NoDictionary(string dictionary, string varName)
{
Debug.LogError(gameObject.name + " - Has no " + dictionary
+ " dictionary!! To save/get: " + varName);
Debug.Break(); //Stop the game.
}

public int GetLocalInt(string varName)
{
if(disableLocalIntegers || localIntDictionary == null)
NoDictionary("Local Integer", varName);

return localIntDictionary[varName];
}

public void SetLocalInt(string varName, int value)
{
if(disableLocalIntegers || localIntDictionary == null)
NoDictionary("Local Integer", varName);

localIntDictionary.Add(varName, value);
}

public float GetLocalFloat(string varName)
{
if(disableLocalFloats || localFloatDictionary == null)
NoDictionary("Local Float", varName);

return localFloatDictionary[varName];
}

public void SetLocalFloat(string varName, float value)
{
if(disableLocalFloats || localFloatDictionary == null)
NoDictionary("Local Float", varName);

localFloatDictionary.Add(varName, value);
}

public string GetLocalString(string varName)
{
if(disableLocalStrings || localStringDictionary == null)
NoDictionary("Local String", varName);

return localStringDictionary[varName];
}

public void SetLocalString(string varName, string value)
{
if(disableLocalStrings || localStringDictionary == null)
NoDictionary("Local String", varName);

localStringDictionary.Add(varName, value);
}

public object GetLocalObject(string varName)
{
if(disableLocalObjects || localObjectDictionary == null)
NoDictionary("Local Object", varName);

return localObjectDictionary[varName];
}

public void SetLocalObject(string varName, object obj)
{
if(disableLocalObjects || localObjectDictionary == null)
NoDictionary("Local Object", varName);

localObjectDictionary.Add(varName, obj);
}
#endregion

}

I think I will remove the MonoBehaviour and use it as a lib class and not a script component.

10

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 29, 2011, 01:35:19 PM »

I'd like to point out is that the comment you quoted RogueDeus is almost 3 years old.  It may not be reflective of C#'s current performance.

For what it is worth, my general rule is to get clean, maintainable code working and come back with a better solution later if that turns out to be your bottleneck.  Chances are you'll have a better understanding of how to do good optimizations later anyway.

Good point. I often forget to check that... It is so easy to get overloaded with info on that site that I only grab the gist of something before moving to the next most relevant tidbit.

11

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 29, 2011, 01:30:13 PM »

You've have to check the specs, and which version of .NET is in question, and so on.  But unless there's a lot of boxing/unboxing going on, there should be no reason.

And actually: with a foreach loop, which is horribly inefficient to begin with, there would be boxing.  So I'm not surprised at that.  But that's a problem with foreach, not with using an enum.  Use for, while, and do while -- never use foreach.

Thanks I will remember that!

12

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 29, 2011, 01:18:06 PM »

I apologize if I am being argumentative. Just trying to make sure I understand which is correct.

If there is no performance hit with liberal use of Enums then I will use them as often as I can. But if there is, I will use them only when a more complex solution is less agreeable.

13

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 29, 2011, 12:33:41 PM »

You know, the more I look at these short cuts (like Enums and Delegates) the more I realize why code is getting bigger and slower... Its faster (easier) to write, but takes longer to process. I suppose that is the trade off really. Otherwise we would still be writing in machine code! :p

Enums add no extra processing whatsoever if you use them right.  They are just like CONSTs.

Maybe I am misunderstanding this then?

http://stackoverflow.com/questions/105372/c-how-to-enumerate-an-enum

In the comments on the answer there is this:

52    
   
Enumerating an enum with 52 values 100000 times: 3884ms Enumerating an int[] with 52 values 100000 times: 99ms yes, far slower than an array - but still fast unless you have 51 million enum values – TheSoftwareJedi Oct 15 '08 at 1:41

If I understand this correctly, he is saying that a foreach loop using a list of Enums is slower then using an array. Not exactly game breakingly slow, just slower.

14

Game Development / Re: How are you handling Serialization with Unity3D?

« on: September 29, 2011, 12:15:12 PM »

I just tackled Enums, Delegates, and Generic Class/Method/Delegates this week and I find myself unsure why I thought them so difficult before hand. They are actually quite intuitive once you understand them.

Earlier in this thread I was a bit confused by how you where talking about Generics an assumed you where using some custom Generic Classing to handle custom lists, but I suppose you merely meant that you like using the Generic Collections introduced in C# 2.0? I had actually been using them in my practicing and never thought about it that way...

Delegates are an interesting way to add method calls to collections, or even clean up some extremely long method calls with simple place holders, but otherwise I can see why you find them overrated. And Enums strike me as a convenient way to simplify the creation of constants. Only, from what I have read, C# creates a lot of temporary code when using Enums and slows things down when iterating through them. So calling them in long loops may end up seriously effecting performance.

You know, the more I look at these short cuts (like Enums and Delegates) the more I realize why code is getting bigger and slower... Its faster (easier) to write, but takes longer to process. I suppose that is the trade off really. Otherwise we would still be writing in machine code! :p

I also played a lot with Unity GUI. It is remarkably simple to use, and will make prototyping mechanics a lot less time consuming.

15

Game Development / Re: Seperating Data, Logic, and Graphics.

« on: September 26, 2011, 09:24:38 PM »

Yep, you can do it that way.  Whatever way makes the most sense to you and is comfortable.

I will try to show examples and ask for feedback sooner or later.