Jump to content

  • Log In with Google      Sign In   
  • Create Account

DemonDar

Member Since 08 Dec 2011
Offline Last Active Today, 07:41 AM

Posts I've Made

In Topic: Trying to make a complex, albeit fun cooking videogame

Today, 05:20 AM

I would not go that way myself, if you want real cooking (wich is fun), you have to create a really complex application, or to script one by one each recipt as a interactive minigame (you could problably find many common code among each minigame but those are all separed). You for sure don't want to keep into account real chemistry, because you'll need massive computing power (however you can get inspiration for most commond results, like over heating brea in oven make it become burned).

Those games you mentioned are fun and most important are viable to program as games. They took significative elements from real cooking, but nothing more, though if you are determined you could make a game in your way and that would be fun, but I warn you that will be really hard and frustrating.

what kind of gameplay you are searching for?

- realistic simulation? basically a interactive video
- hard-core hand-eye coordination? cook what required in a certain time

- causal gaming? do recipes without any real challenge but the pleasure to see something created

- perfection? (swipe in a certain direction at a certain speed)
- economic? (buy upgrades and make income from selling food)

Personally I'm ultra bored by those cooking games, there are some different but mostly they are clones of each other. I hope you could really innovate the gender!:)

 


In Topic: C++ Librarys - When to use .lib vs including .h/.cpp

22 August 2016 - 10:44 AM

Most source bases need to be configured for each build target, so a library has that already done. When build process is somewhat complex you always prefer a pre-build binary. Of course if you do not have the pre-build binary for your compiler/operative system you go nowhere, while with source code you can always compile and eventually fix compilation problems "on the fly".


In Topic: Preventing overengeneering

21 August 2016 - 05:59 PM

I stmbled on opposite problem, I always overengineered mine stuff, when started to working due to impossible deadlines I started writing spaghetti code,

This bitten me later but not so much, in exchange I started too see the few places where a non-spaghetti code was better, few MVC there, a state machine over there and a decorator in one place and voilà, ship awesome features in  no time. Now I'm gradually strarting writing non spaghetti code at almost same spped (if not faster).

The problem is that as your own manager you know where you maybe want a change and you start overthinking, at work the requisites are not your decision so you stop overthinking, the solution is to not longer decide the requisites for your stuff, instead let a friend (or girlfriend) to decide features (you should give a visible result or cut it.)

In the current game I'm developing requisites come from another society and are changing several times a week, so even well coded scripts had to be dropped sometimes, if the game designer/ project manager started ith definitive requisites the game probably had to be already complete, instead the time I did'nt loss in overengineering was better used to apply on the fly the changes wanted by the designers/managers.

The most important stuff was to decouple visual from logic, since usually only 1 changed and rarely both.


In Topic: Rpg Stats - Temporary Changes, Harder Than I Realised!?

26 July 2016 - 06:19 AM

@noizex.. Very good point separating lifetime handling. :)

If an effect added or removed => just recompute the str value, no dirty flag required.


Ideas for handling lifetime? (already saw different blog posts of people having bugs with this kind of things.


In Topic: Rpg Stats - Temporary Changes, Harder Than I Realised!?

26 July 2016 - 02:47 AM

Use memoization/DRY, so do not store the final value of the stat. Instead recompute it each time it is asked.

So each effect to a stat is:
 

enum class StatAffectionType{ 
    BaseStat, Buff, DeBuff
};

struct StrEffect{
    unsigned int amount;
    unsigned int millisecondsLeft;
    unsigned int priority; //order in wich changes are applied 
    StatAffectionType type;
};

class Character{

    std::vector<StrEffect> strArray;

public:

    int GetStr(){
        SortStrArrayByPriority();
        int str = 0;
        bool someEffectFinished = false;
        for( auto effect: strArray){
            switch(effect.type)
            {
                case StatAffectionType::BaseStat:  
                       str+= effect.amount; 
                       break;

                case StatAffectionType::Buff:
                       if(effect.millisecondsLeft>0)
                           str+= effect.amount;
                       else
                           someEffectFinished = true;
                       break;

                case StatAffectionType::DeBuff:
                       if(effect.millisecondsLeft>0)
                           str-= effect.amount;
                       else
                           someEffectFinished = true;
                       break;
                       
            }
        }

        if(someEffectFinished)
           PurgeFinishedStrEffects();

        return str<0? 0: str;    
    }
};

You can cache the result once per frame but it should be cheap by just ask it each time. In this way you avoid all kinds of bugs, note that even Morrowind and Oblivion had tons of bugs related to temporary stats, so I would go the "slow" but safe way, and later optimize only if needed.

If you use  a sorted list you do not need to sort, (each buff will be inserted at right position), I think this is one of the few cases where sorted lists are usefull.

While I agree this can be considered a monolitic class and some purist would refactor so that each effect has its own virtual class, consider also that as long as kinds of effects are limited in number you have just one place to check regarding your Str stat, so I would consider that a dirty code, but dirty on purpose.


PARTNERS