Posts by Tomate_Salat

    Please: next time just copy the code here in code-tags. Then I could copy&paste which allows me to play around with it. Then I also could check if my hint is correct ;-).

    But ok - I think I located your problems. Let me go through it one by one:

    1. You check for the Space-Bar and you starte the coroutine fireRapidly() + store the IEnumerator in a variable.
    2. You have an else-if-block doing the same check as in the if before. So this block becomes ignored
    3. Follow up comes another if which does not stop fireCoroutine. You have a bug here: you should pass as parameter the variable poweredFiringCoroutiner. What you do here is to create another IEnumerator (which has not been started as coroutine) and stop it (makes no sense ;)).

    So what you probabbly want to do are the following steps:

    1. Merge the first and the second if. Depending on the canTripleShot-flag you either create the one other fire-mode. Cause only one can be active at the same time you also need only one variable for that.
    2. Pass the variable to the StopCoroutine-Call when releasing the button

    Additional Stuff:

    Checkinig a boolean if it is true is btw a redundant check. So instead of: if (variable == true) you just could write if (variable). And you also can shorten if (variable == false) by using an ! in front of the variable:

    1. if (someVar == true) {} // Long version
    2. if (someVar) {} // Short version
    3. if (someVar == false) {} // Long version
    4. if (!someVar) {} // Short version

    The ! is btw very usefull in case when you want to toggle a boolean (so that true becomes false or false becomes true). Which can turn such code:

    1. if (someVar) {
    2. someVar = false;
    3. } else {
    4. someVar = true;
    5. }

    into a simple one-liner:

    1. someVar = !someVar;

    I guess together we nearly got it. Blame on me: I completly have overseen the example down below. So as I understand the fixedDeltaTime it defines how often physics is called ( = calls to FixedUpdate). I've updated my example above. Because fixedDeltaTime != timeScale .

    Also setting timeScale to ero will stop calls to FixedUpdate too thus "pausing"

    As I got it you've to set fixedDeltaTime to zero in order to also "pause" FixedUpdates.

    One last thing I got from the docu is that you also should prefer deltaTime over fixedDelta time:


    For reading the delta time it is recommended to use Time.deltaTime instead because it automatically returns the right delta time if you are inside a FixedUpdate function or Update function.

    I can not tell you a good reason why. The most valuable benefits I can see are:

    • More stable code: think of refactoring. Once you move the code from FixedUpdate -> Update you don't want to have fixedDeltaTime in there, cause that would be a bug.
    • More reliable code: May due to some lags FixedUpdate is called later than expected. deltaTime would contain the correct value - fixedDeltaTime not (cause it is only a setting).

    would be viable solution?

    Based on reading the documentation I would say that this could be a solution. But the docu also recommends to update Time.fixedDeltaTime by the same amount. I may would write me an helper for that to avoid code duplicates:

    I was "clicking" me through the video and from the base both ways are the same. Using delegates and events. Well - not a suprise cause both are implementing the observer pattern ;-).

    The difference is that the example from my link is more aligned to data classes. So instead of having something like this:

    1. public event UserChangeHandler OnUserNameChanged;
    2. public event GenericChangeHandler OnCoinsChanged;
    3. public event GenericChangeHandler OnPlayerLifeChanged;

    you just have:

    1. public event PropertyChangedEventHandler OnChange;

    And the event is fireded by this function:

    As you can see you don't have to provide the parameter of the NotifyPropertyChanged-Method. It will automatically take (in that case) "CustomerName". So the listener gets the information about which model (this) and which property (CustomerName) has changed.

    I don't write this to convience you for that approach - I just want to make sure that you understand this approach. Because imho this is very usefull for data classes. But if you think this is not needed then use Jons approach (there is absolutly nothing wrong about it).

    About the eventBus-system ill look into it, right now I just keep a dictionary in memory of "string, float" for the variables I want to monitor, and using a coroutine I inspect the values every x seconds.

    That sounds weird to me. Do I get you right that you iterate all the time through all variables and check their value? If yes: why don't you just use PreferenceListeners?

    See:…etframework-4.8#beispiele and check out the DemoCustomer-Class.

    Correct me if I'm wrong.

    That imho depends on your use-case. If it ends on your data. If you end up with one table and one row - then a db is not the right choice.

    Do I get you right - you've over 1k events? Not sure if we mean the same. Because you are also talking about saving the data - which you wouldn't do with an event. An event could trigger persisting some data.

    In case when you only have to deal with such amount of data then I'd recommend to use a database ( Database ). And don't worry. 1K entities in a database are absolutly no problem ;-).


    Just to have it mentionend: another way of deliviering events could be an EventBus-System. It delivers just any event and the subscriber have to filter out which events they're interessted in and in which are not.

    But I so far I guess you are looking for a database ;-)

    Did you install the Post Process Stack as mentioned through the asset store or the package manager? I assume you did it via asset store. But this is deprecated:


    The Legacy Post Processing Stack has been deprecated for new projects. If using Unity SDK 5.6 through 2017.2, please find version 2.0 of the post-processing stack on Github. If using Unity SDK 2017.3+, version 2.0 of the post-processing stack is available via Package Manager.

    Give it a retry via Package Manager.

    They make life so much easier for things like an adventure game.

    Not only for a given genre. They can decouple your whole code. E.g.: in my current game I'd to rewrite the Spawner-System from scratch. Because it has no direct dependencies to other components in the scene replacing it was not a big deal. I only had to ensure that the same events were fired - finish.

    Also I actually restructure my whole gameplay. A lot of things will be removed, some stuff will be reused, some stuff will be completly new. Keeping existing stuff was really easy. I just drag them in the scene and they work.

    You are looking for ScriptableObjects. I'm using them exactly for such a separation. My GameObjects (rarely) know about each other - they're communicating by events fired by a ScriptableObject and also register themself to a ScriptableObject in order to consume them.

    I've written an article about that topic :

    Scriptable Objects

    And I really can recommend the video I linked inside. That guy is the reason why I'm making so much use of ScriptableObjects.

    Performance penalty since used in update?

    Therefor I can recommend you in reading the documentation:…dbody2D.MovePosition.html ;-)

    It says:

    "It is important to understand that the actual position change will only occur during the next physics update therefore calling this method repeatedly without waiting for the next physics update will result in the last call being used. For this reason, it is recommended that it is called during the FixedUpdate callback."

    So there should be no performance issue - but for keeping it clean I'd call it within FixedUpdate.

    As an hint: You should always use the rigidbody to move the object. In my first game I made the mistake and used transform to move an object having a rigidbody. That leads to to performance issues the player will notice!


    Some words to your extension method: I think this is a valid use-case for extension methods. But I just would call it Translate. Because the method is working on a RigidBody2D that information would be redundant. But if you want to stay with your naming it is of course also fine ;-).

    It really doesn't matter if you're working alone or on larges project in team (I do both). They always reduce your code quality heavily. You can easily check your code quality by trying to write tests for it. Writting a proper unit test for a class using a Singleton is nearly impossible cause of the mocking problem.

    But there is also another problem: Every singleton is reducing your reusability because your classes just know too much:

    So the RelayOnGameManager-Class knows who is manipulating the data. But that information is completly uselss and expensive. That you could easily solve with a ScriptableObject in between of both:

    When you know pass the same GameData-Asset to all classes you have the benefit of Singleton without having the disadvantages.

    And never forget: Every big project has started as a small one. And the bigger your project becomes the more painfull are architectual mistakes.

    So I really would recommend you to follow best practices and usefull patterns and principles. I wouldn't accept anti patterns otherwise they one day might become a habbit.


    I know - programming discussions easily can turn into really toxic discussions. So to say it clearly: I don't want to offend anybody. I just want to give advices based on my knowledge due to my daily work as a software dev. In the end you (= everyone who reads this thread) have to decide about how you'd like to write your code.

    Last but not least: Cause nobody of us has to work with each others code we can give a fuck on the others code quality - so no need for emotions or toxic talks :-P

    But the pro-subscription offers more than only the filebase. In my opinion the size of the filebase right now is too small for being the only reason paying 15$/month. Therefor there are too many pages out there offering great 3d-assets for free. I would say the most people subscribe cause of the courses.

    So I'd advice to see it from a different perspective. A bigger filebase could attract more users to the community and also keep them here. May they register due to the free filebase and later will subscribe to get the courses + that they can give requests for professional models. From this point of view the free asset filebase would support the pro-membership.

    At least from my side this is win-win-situation. I can totally understand that the creators of this community like to also gain money with it (there is nothing bad about it). Me as a part of the community is more interessted in building up this community and attract more members to it. And having a big community should something which both sides want to have ;-).

    As far as I can see this community has some people with experience in asset creations. Maybe hobbiest (like me) or maybe also some real professional ones. So I'd like to ask what you guys would think of the filebase but community-driven. And the definition of community driven is quite simple:

    - it comes from us

    - it is for us

    - it is free and usable for everyone

    So what do you think about it?

    My motivation is that I can release my work. Feature Runner was really early-early-access when I published it to the play store and found some beta-testers. To keep them I'd to provide updates for it.

    The game I'm now working on requires some more time at the beginning in order to reach early-access. But I know, that I can release it! And this is what motivates me the most.

    Before I started with game developing I just continued similar projects at home like I did at work or investigated new technologies. E.g. I wrote some ToDo-App which was using React as frontend, Spring boot for the backend and a little powershell-script which took care about the build. But: who will use it? Probabbly no one. Because I didn't want to release it and I didn't want to host a dead useless project. Motivation = 0.

    But with game developing you can reach people and you can challange yourself. I loved it to check every day the statistics send from my game. And my overall challange is: Gaining money with my games in order to buy assets from it or renting a small server to host an homepage. And I'm really excited if I can make it.

    Well. Feature Runner at least provided me some small earnings ^^:

    And again: it made me happy to see that Feature Runner is being played :-). I've created a game and people out there are really playing it. Now I want to provide more ;-).