Jump to content

Recommended Posts

I am trying to make simple inventory for my game, but I can't decide how to do it. Now I have something like this

function Game() {
    this.player = new Player();
}

function Player() {
    this.inventory = new Inventory();

    function Inventory() {
        this.items = [];

        this.addItem(item) {
            this.items.push(item);
        }
    }
}

Is it good idea to do Inventory object inside Player object? Or is it better to do own Inventory object and create it inside Game object like this this.inventory = new Inventory();?

Link to post
Share on other sites

I like to have one class per file, so I would have put your Inventory inside a separate file and then do this.inventory = new Inventory() in your player class.

Either way it's fairly nice code, you divide responsibility in a good way. If your player is the only one ever to use an inventory I think what you are doing is perfectly fine and won't populate the global scope as bad as my "one class per file" will do.

So go on along the path you're on, it looks good.

Link to post
Share on other sites

At some point you'll probably want to use that `Inventory` constructor somewhere else, which is why it would be best if it was outside of the `Player` closure. That's the reason for code separation, reusability (plus, possibly, readability) and also testability, currently, to test your Inventory objects, you've got to also instantiate Player objects so you can't test in isolation.

Link to post
Share on other sites
25 minutes ago, WombatTurkey said:

I think you might kill me if I were to show you some of my code :P

Well it depends a lot on what you are doing. Developing websites or libraries, populating the global scope is a big no-no, but I don't think HTML5 games have aged enough to have best-practices yet. I mean if all you have on your website is just your game, and you know this for sure, then I don't see a reason not to use the global scope, and in the end you can just throw a function-scope around your entire game-code.

Best practices are widely different depending on which language you use, but also the type of project you are developing.

Link to post
Share on other sites

Thank you for your advice! I have also 'Mouse' object where I handle all clicks inside canvas elements, so is it good idea to do like this:

 

function Mouse() {
    var inventory = game.player.inventory;

    $('#inventory').click(function() {
        inventory.select();
    }
}

I mean that 'var inventory...' part. Is there any better ways to do this?

Link to post
Share on other sites

Nope thats fine, technically it is probably a micro-optimisation as large object chains require multiple property lookups which require more cycles (when I say slow, its micro-seconds, not something you'd ever worry about), plus, it saves you typing :) 

Jus to throw something at you, by including Inventory inside Mouse you are creating a tight coupling, maybe there is a better way to structure your app to reduce coupling... 

Link to post
Share on other sites

I agree with JakeCake's comment: "If your player is the only one ever to use create an inventory I think what you are doing is perfectly fine". Keeping Inventory within Player makes it clear no other code is creating inventories. However, as Matt pointed out, the day may come when you will want something other than players to create inventories and will therefore want to move Inventory outside of Player. So, try to avoid code in Inventory that would couple it to Player. That way, moving Inventory outside of Player will be clean and easy if that day comes.

Concerning mouse clicks: Based on the simple code snippet you provided, placing the click handler assignment within Inventory would better encapsulate inventory concerns within Inventory.

Link to post
Share on other sites

I forgot to mention... You can help ensure Inventory stays decoupled from Player by placing it in a separate closure. So, your code could look something like this:

var Player = (function () {
        function Inventory() {
            var items = {};

            this.addItem = function (item) {
                items[item.name] = item;
            };

            this.getItem = function (name) {
                return items[name];
            };

            $('#inventory').click(function () {
                // Click handler
            });
        }

        return function () {
            this.inventory = new Inventory();
        };
    })();

 

Link to post
Share on other sites
  • 1 month later...

 

On 4/27/2016 at 5:13 PM, JakeCake said:

Well it depends a lot on what you are doing. Developing websites or libraries, populating the global scope is a big no-no, but I don't think HTML5 games have aged enough to have best-practices yet. I mean if all you have on your website is just your game, and you know this for sure, then I don't see a reason not to use the global scope, and in the end you can just throw a function-scope around your entire game-code.

Best practices are widely different depending on which language you use, but also the type of project you are developing.

I have a kind of "status window" on the website that displays some stats. I did this so as not to overcrowd my game canvas. So a bunch of my variables need to be visible outside the scope of the game. 

Just giving an example usage for variables that seem "way too global". Of course, the website only has that one page that does basically everything. 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...