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 3 years ago.
Improve this question
I have a house floorplan in scene A. Players can click a room on the plan and go into that specific room. What they find there will be an image of that specific room and some character stats about that rooms current occupant (not the player).
At the moment, I handle this with a set of public variables in a gameobject instance "target room 1" "current occupant Henry" and use those to build a single scene.
I was wondering how you would go about this. Is there a better way? Is it better to have one scene for each room? How would you get players to a situation that they see the room and the specific occupant?
Well, that depends a lot on the game you have and how would it be easier for you (and/or your team) to manage it.
You can make each room a different scene and just reference it and load it on click. That would work best if each room is complex. Programming wise - If it has whole set of information and states to take care of it would be harder to manage those systems for every room in a single scene. Design-wise - if it's a complex room with lots of object making it a different scene would be easier and cleaner for you to work with. Drawback is, well the frequent scene loading. That also means that if you need some state to persist across different rooms you'd have to figure out how to do it across scenes.
You can make each room a game object and just enable it and move it in the field of view of the camera. That would work best for simple scenarios where there isn't too much complexity about the functionality and design of every room. Also you get the benefit that you can easily just have something like Room Manager that can make interaction between rooms easier.
You can make a single room object in the scene and populate it with data at runtime when you select a room from the plan. That is a very good option if all the rooms are sort of homogeneous and just have some variables that need to be changed - perhaps an image, a name or certain prefab that has to be instantiated. A nice structure for that would be to have perhaps a RoomData scriptable object with all the data in it and a RoomObject prefab that you put in the scene. The RoomObject will take in the RoomData and display it. That way you can quickly make different rooms by just creating new data files. You can also make different types of prefabs that handle the data a little diffrenetly - perhaps if you want a BedroomObject that has a different layout or something like that
Related
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 1 year ago.
Improve this question
I'm trying to create a replica of the card game "Monopoly Deal" in C# Console, for educational purposes. I have a problem with my class design that I'm not sure how to resolve. I have two classes, Game and Player. Game controls the state of the game, and contains a list of Player objects.
Currently the way it works is that the Game class controls everything. The Player is basically a container class: it has all of the cards in the player's collections. The decision-making is done by the Game class because it can see all the players, and therefore knows which moves are possible.
For example, if Player 1 wanted to steal a card from Player 2, my program would have to first verify that Player 2 has any cards to steal. Player 1 doesn't know that, because it's just a single object in a list of Player objects. So the Game class has a method which checks all possible actions that a player could make, asks the player to choose which action they want to make, and then performs that action for them.
My problem: I don't think that this is good OOP class-design. I think that I should be delegating the decision-making to the Player class, not the Game class - otherwise my Game class will become bloated with lots of methods that relate to player actions and decisions, and not the game state itself. I don't know how to achieve this, however.
Possible solutions:
Create a GameState object containing just a limited view of other players' cards, and pass that to the Player object (Seems the easiest way but I guess it's creating redundant data which is a waste of memory.)
Pass a reference to the whole Game object to the Player class (I could do - it's not like I'm going to program by ComputerPlayers to cheat - but doesn't feel like good OOP design either)
Give up, and put all of the game logic (including the computer AI) in the Game class, and accept that Player will just be a data container, not a decision maker.
Redesign my classes a different way.
Something else I've missed?
Is there any obvious solution here? Thank you.
EDIT: I've attempted to trim down excessive detail in the question as it was closed for "Not enough focus". If further revisions are needed, please let me know.
How about creating an action-class that represents an action that you can take in the game. The Game then just has two methods Game.verifyAction(action) and Game.executeAction(action). The Game contains all the data necessary to verify and execute actions.
Next, treat players just as data containers, meaning a player does not think it's just contained in the state. A player might contain data like it's score, it's id, etc. To actually think you have an agent class that is responsible for choosing actions. So Agent.think(Game) returns an action that the agent wants to take in this state.
Now it's easy to move the main-loop outside the Game-class, you can also replace an Agent easily with an GUI that returns a valid action once the human chooses an action.
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
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 4 years ago.
Improve this question
I'm trying to create a simple simulator in C#, which should simulate a very simple car engine. The simulator can either be on or off, and it will, for instance, have the following inputs (there will possibly come more in the future).
Use case:
In this example, the car engine will have the follow input parameter:
Thrust produced (0-100%)
Temperature (-50C to 300C)
NOS (enabled/disabled)
Driving mode (economy / normal / speed)
On/Off
These input parameter will alter the following two output parameter:
Thrust produced (0-150%)
Temperature (-50C to 300C)
If for instance the driving mode is set to economy, the maximum thrust which it can output will be e.g. 70%. NOS will also alternate the output somehow. The simulator will have an event handler, were the computed values for thrust and temperature will be announced.
Question:
I'm asking for some input on how this simulator easiest can be designed, so it can be extended with new input parameter later on. Any good design pattern you would recommend or articles? Feel free to ask questions or show your best solution :)
Thanks in advance
You should implement several patterns which will make your life easier. If you are familiar with Unity game engine use its concepts. I suggest you to use this game engine if you aiming to build games.
First of all, use Game Loop and Update patterns.
In simulation your need several FixedUpdate events for calculation in one Update event for rendering frame. FixedUpdate should not depend on current FPS.
Then you can implement some kind of Bus like in real cars CAN-BUS is used. It can be done with Observer/Observable or Subscriber/Publisher. You can learn about difference here Difference between Observer, Pub/Sub, and Data Binding but I suggest you to use Subscriber/Publisher as it is like message queue.
To implement different modes (economy, racing) you probably need Strategy pattern.
Also Component pattern will help to make things by analogy of devices and sensors in real car. Each component object reads messages from bus queue and sends events to bus. Some components like ECU or EMS can use current strategy to send commands for injectors.
State pattern will help you to maintain different states of components. For example, engine cycle state.
Your question is very broad, but I suggest you to choose some real-life concept and make code design by its analogy.
Please refer to this great book to read more about mentioned patterns: http://gameprogrammingpatterns.com/contents.html
Given the car engine simulator is bunch of input and output parameters which depends on change to other parameters I'd recommend to use Observer pattern,
For example ThrustProduced parameter would be an observer of DrivingMode, and when the DrivingMode parameter changed, it has to notify it's observers including ThrustProduced, which then recalculates the thrust and limit it to 70% and then fire the event to notify that the thrust has changed.
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 8 years ago.
Improve this question
i've been figuring a little about abilities... like in DOTA, LoL and other MOBA / MMORPG games. If i would make a game with character selection in the beginning, and in-game it would have spells / abilities and such..
What would a correct way of doing this be? Should i make one Champion class, with all values and textures, or initialize it in Game1.cs like Champion champ = new Champion(texture, name, Q-ability name, Q-cooldown, Q-damage, Q-manacost) - but that would take TONS of diffrent declarations...
Should i make a Champion folder and make a seperate class of them all? And also the abilities - i'm thinking about maaking an enum to keep them, or would a List or another variable work better? Thanks!
For such a game, I'd recommend the use of an entity system (http://entity-systems.wikidot.com/). These allow you to create separate spell, ability, player, character etc classes and to compose them into highly configurable entities. I ported the popular Ash entity framework to C#, which is available at https://github.com/DavidArno/Ash.NET, which may be of use to you.
Beside of an entity system which David Arno suggested, if I wanted to do this, I'd go with a single Hero class and then with a list of abilities inside it. Abilities are all the same, different thing is their factors. For instance, how much damage an ability can deliver and etc. This way you have to instantiate all of your champions and their abilities.
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.