You are correct that it's not the View's job in an MVC architecture to implement any game mechanics like friendly fire.
But whether it's the controller's job or the model's job to implement game mechanics is a matter of debate.
There are basically two philosphies here:
In a thin model MVC architecture, the model is just a dumb data-structure ...
Your question is a good one. I've had exactly the same question regarding SpriteKit and have been very confused about the lack of information on the web about this. SpriteKit seems to encourage you to put all of your Model-View-Controller code into the same class (your SKScene subclass), which is really confusing to me. How would you ever build a game of ...
I'd warn against MVC for games in the first place, but putting said logic in the controller is fine. You can also put a small bit in the model if you want to be really pure. The Model contains a selection state and the Controller modifies this. Then the View uses this state to do its rendering.
bool selected = false
The correct way is to skip that frame and wait until the model is ready.
If you find that the model update is taking too long, causing frames to be skipped too often, it's a better solution to optimize that instead of overcomplicating the code trying to be smart on the view side.
A popular alternative is to use frame interpolation in the view, but it's not ...
You can solve this by implementing the controller as a state machine with four states:
wait for animation to finish
In each of these state different GUI elements are shown/hidden and the inputs of the user are interpreted differently.
Instead of implementing it as a state machine, you could also implement it ...
The suggestion of using arbitrary distance units is a very good one, and once it really clicks, you'll see that floating point vs fixed point is only a matter of how you represent your numbers. Using only fixed point is of course the most accurate solution, but floating point inaccuracies start to show mainly when you, for instance, exchange floats between ...
I'm not sure that it is possible to keep a good communication speed over time with a growing community.
You have limited control over this.
The problem is that I can't allow a communication to be longer than 200 ms (time of the client side animation). On the server side I have to go to the database to do the validation.
100 ms ping is short enough ...
Unless you're making a game like solitaire or minesweeper, the design pattern that games typically use is called the game loop.
Go to 1.
You can see that it has similarities to MVC, but there are some differences. MVC typically does all 3 steps per action. The game loop takes all actions then does all updates then draws ...
In a classic MVC world, the networking is split into a controller and a view component.
Network input is a controller, because it processes commands which then result in changes to the model.
The network output is a view, because it translates the model changes which are happening in your game into a network protocol. This is not much different from ...
The MVC pattern is indeed a good solution here. You would need three different controllers:
The LocalPlayerController which is sending commands to a paddle by listening to the local input devices. When you have multiple input devices (keyboard, mouse, gamepad...) it might be a good idea to further subclass it into the one it listens to. In any case, these ...
I generally prefer ScriptableObjects for storing data that:
You want to be editable with a GUI in the Unity Editor (as they can be edited in the Inspector much like the components on a GameObject)
Is determined at design time and will not change at runtime
You want to be able to assign to fields in the Unity Inspector
Here's the typical strategy I'll use ...
Design Pattern can show you a solution, how this pattern helped many others. If it is suitable for your problem is only known by you. Design Patterns are rather independent of applied technologies (LIBGDX).
MVC is a Design Patter that evolved from the UI-Design-Problems in the late 70s. What you are trying to explain looks to me like you're ...
You need to IEnumerator to yield return and wait for request to complete. Call this method inside coroutine.
public IEnumerator GetLeaderBoard()
UnityWebRequest myWr = UnityWebRequest.Get("http://your-url"));
yield return myWr.SendWebRequest();
if (myWr.isNetworkError || myWr.isHttpError)
I thought I would share my resolution with you here.
I tried a variety of things, including lengthy web.config changes per recommendations on Unity's site, and others found in other forums, but the only thing I ended up needing to add was the following code to my Startup.cs file in the Configure() method:
StaticFileOptions option = new StaticFileOptions();
Your lecturer is teaching you best practices through software design patterns - in this case, The Strategy Pattern (known in simpler languages like C as function pointers). You can follow your lecturer's guidelines AND be elegant / efficient at the same time:
public interface Effect //strategy ...
The two are not mutually exclusive. It's a reasonable approach as long as your comfortable working that way. I assume when you say pure C# you're still using MeshRenderer components, gameObjects, etc.
I've worked this way before in Unity, especially early on as I came from Objective C and had written a bespoke 2D Sprite system, and instinctively wanted to ...
Separating model from view and controller is invaluable in one very specific aspect of game development often overlooked when not developing at scale: testing. Develop your game simulation as a model, and you can swap out a user input device controller for an automated, repeatable testing harness. This allows for incredible leaps forward in testability, ...
First, a quick review of MVC as it pertains to OOP:
Model - objects that store and maintain data consistency with respect to the problem at hand, in our case simulation.
View - objects that translate output to the user.
Controller - objects that translate input into commands that alter the model.
In its purest form, we should be able to save a game's state ...
Sounds like semantic noodling to me. I guess I tend more towards your option 2 in that I have lots of different model objects for different aspects of the game instead of just one monolithic model object that handles everything, but I don't keep "menu" and "game" areas strictly separate. After all, what if you want to be able to access the main menu every ...
In simple terms a common design in SpriteKit games is scenes, layers, nodes and child nodes.
You might make each part into a discrete class that encapsulates all of the parts, properties and methods.
For example a Background class that has layered images, particles, various properties like the speed each layer should move and public methods to start and ...
A Singleplayer game is a Multiplayer game with one human player.
None-human players (often referred to as bots or AI), are a class or a group of classes that extends the base Player class. These classes compute the game state and output the moves the computer algorithm "considers" to be reasonable.
You could implement Multiplayer by itself and allow a ...
It's a bad idea if you are talking about 3D / GPU rendering.
It's fine if you're rendering 2D / non-GPU, as it may make more sense to you organisationally.
The reason is that GPU rendering, for optimal (or even reasonable) performance, requires individual render passes that render groups of game objects with similar properties i.e. materials, since each ...
I suggest you use just one thread for now.
In my opinion, using multiple threads for rendering and game interactions will only complicate your code and introduce synchronization overhead, so the only time I would do that is if I MUST improve performance by using multiple threads for multiple CPUs (in which case you should profile first before ...