We Keep Coding

Best way to implement this? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Hi I'm a unity developer working on a bar manger game and I'm just wondering on the best way to implement a drinks system where it sets the value of the drink, number of servings in the barrel, name of the drink price of the whole barrel.
Here is some code I was working on before:
This is the interface method
public interface IDrinkSystem
{
string SetDrinkName(string nameToSet);
float SetDrinkValue(float drinkValue);
int AmmountOfServingsInBarrel(int Servings);
float PriceOfBarrel(float price);
}
This is the class method of doing it
public class DrinkSystem
{
public void NewDrink(string drinkName, float drinkValue, int barrelServings, float barrelPrice)
{
// Have getters and setters for all values in separate methods
}
}
What is the best way for making it easy to expand and at a push can I make an array of the NewDrink to store all the drinks i have or is there abetter way of doing this.

Use ScriptableObjects, as if they were files.
For every type of drink, have a ScriptableObject which you can fill in from Unity easily (even your artist can do this), and then at runtime, you load them into objects of a single DrinkEntity class which loads these values.
This way you don't end up with dozens or hundreds of "DrinkSystemBeer"/"DrinkSystemWhiskey"/etc classes, but you can still keep all your code clean and pattern-friendly.
IMPORTANT: NEVER operate with the ScriptableObjects directly. Simply load them into a DrinkEntity on its constructor. Treat ScriptableObject as if they were xml or json files from which you read your data.

Rule of thumb about when to use a temp object to hold reference to an object, rather than referering the whole path at every use? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I guess this question is for a large part a matter of what you prefer aswell as being very situational, but I just came across a path to a gameobject today with a pretty long reference, and I thought if a temp reference wouldn't be better for this situation.
The code:
if (enlargeableButtons[i][j].gameObject.activeSelf && enlargeableButtons[i][j].IsHighlighted())
{
enlargeableButtons[i][j].gameObject.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
In a case where the path is this long with multiple array indexes to check, it would definitely be faster, but because of the extra object also be more expensive to do it like this:
GameObject temp = enlargeableButtons[i][j].gameObject;
if (temp.activeSelf && temp.IsHighlighted())
{
temp.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
But how much and would it be worth it?

I seriously doubt you will see any performance gain using a direct reference instead of going through the jagged array.
Maybe if this code is running in a very tight loop with lots and lots of iterations, you might get a few milliseconds of difference.
However, from the readability point of view, the second option is much more readable - so I would definitely go with it.
As a rule - You should design your code for clarity, not for performance.
Write code that conveys the algorithm it is implementing in the clearest way possible.
Set performance goals and measure your code's performance against them.
If your code doesn't measure to your performance goals, Find the bottle necks and treat them.
Don't go wasting your time on nano-optimizations when you design the code.
and a personal story to illustrate what I mean:
I once wrote a project where I had a lot of obj.child.grandchild calls. after starting to write the project I've realized it's going to be so many calls I just created a property on the class I was working on referring to that grandchild and my code suddenly became much nicer.

Declaring GameObject temp just creates a reference to enlargeableButtons[i][j].gameObject. It is extra overhead, but not much. You won't notice a difference unless you're repeating that thousands of times or more.
As a personal rule, if I just need to reference it once, I don't bother with declaring a variable for it. But if I need to use something like enlargeableButtons[i][j].gameObject multiple times, then I declare a variable.

Implementing a Quest System in Unity3D [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Good day all.
I'm working on a story-driven game in Unity3D and I want to have quests the player must complete to progress through the story.
What would be the best and most efficient way to implement a quest system?
Currently I have the following data structure in mind:
Quest (Class)
Quest name
Quest description
Quest Reward
Quest Location
Is it a side quest?
What's the name of the main quest?
Is it necessary to continue main quest?
QuestManager (Class)
List of all quests
What quest is the play currently pursuing?
List of objectives and side quests of the current quest
What objective is the play suppose to complete in the current quest?
Checks whether the player has completed a quest/objective/side quest and handles events accordingly
The data structure looks pretty reasonable but I don't know how to implement in such a generic way that I can easily and quickly create quests in my game. Any ideas?

The general idea you have seems fine. I would modify things a bit. I would probably make the Quest reward also a class. That way it's easier to customize the rewards.. I would also make "What's the name of the main quest?" an method which grabs a Quest object(if it exists). This way you can easily just reference the parent quest from within the sub-quest.
I am assuming your using a database to store all this information? If not I'd suggest using sqlite.
This way, all that's required to add more quests, etc. is to send an updated database file out to your users. It's pretty easy/fast to just add data to a db also. No hard coding quests etc.
So you create these Quest classes as Models, fill out the data, and then convert that object into JSON. It can then be stored in the database. Once it's pulled out you can convert the Json back into a Quest Object.
Use Newton-soft Json to do this, along with Sqlite
Or you can also do it this way: Walkthrough: Simple Object Model and Query

Class Name: Append DTO or Entity [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is there any preference on either appending DTO or Entity to a class name?
Is there any standard around this?
1 Class is used by ORM (EntityFramework) and the other class is used for serialization.
The reason for this is so that there is no duplication of all fields as the EntityFramework is a wrapper around the DTO class(most but not all properties).
The DTO class is in a shared library, and decoupled from EF.
E.g. Which of these is the most common/standard approach?
// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models .MyClassDto
// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClass
// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClassDto

In my personal experience your third example is the only implementation I have worked with and it is the one I would argue for because the intent of the object you are working with will always be clear whereas with the other two it only becomes clear when looking at both objects together.
That being said as long as your team comes to an agreement on which to use any would work.

In my opinion, you typically don't want to put implementation details into class names for similar reasons to why you don't want to use Hungarian Notation.
If there's a bit of code that needs to work with both types and differentiate between them, another option is including aliased using statements like this:
using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;
//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();
//work with both
My assumption is that the code that needs to work with both types is limited to an isolated library, and that client code typically works with one, not both types.

What is the best way to represent a large field of objects while using minimal resources? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
all I am looking to develop a project in unity, it is for android! I was wondering if I could get some clarity on a few things. My problem involves me trying to creating a universe of stars, 150,000 individual stars to be exact, granted there would only be a certain percentage in view at any one time. What is the most efficient structure for being able to convince the user of a realistic environment while keeping the overhead to a minimum since it will be on a phone?
What type of objects do I want to use to represent the masses of stars vs. the likes of stars in close proximity that require finer details?
What sort of threading structures should I consider while planning this project?
How easily does a project port from unity to android, in such scenarios?
Any help is much appreciated as I am looking to better develop with unity, cheers

I would suggest not tracking all 150,000 stars, but only the ones that are in view. When the field of view changes, use a random number generator to define the stars that have just entered it, and drop from memory the ones that have left. To preserve consistency, you might want to retain the stars for a short period around the current field of view, if the user can do rapid switches in direction.
As for threading, that's less a function of the number of stars you are tracking, and more a function of what it is that you are doing with them - something you didn't mention.

1) This question is mainly a game development question and not unity regarding. I just point you in the direction, as a complete answer would be to much. Normally if you need to know where you are in a 3D scene with infinite objects or close (150k is close), you would use a octree for orientation. Constructed like a map, each node of the tree points a direction (West, South, Nord, East, NNW, ...) Then you each of your stars gets 1 node, and you can calculate what is where and how much do you want to see. More information can be found on google. (Quite complicated topic jfyi)
2) Dedicated to 1) with a mix of entity/component design. You will know what I mean after 1) is clear to you.
3) Absolutly Multithreaded Asynchron. 1 Thread Update, 1 Thread Draw, Few Worker Threads (position, ...)
4) The port of Unity Engine is actually working really good. Of course you should have an android peripherial to test and debug on, but most of the time, it will work for you.