Git branching, naming conventions, global variables, and Mr. Carboon...

First, I’m very aware that the topic of this blog has kind of shifted a bit over the last few posts. It went from posts about games, the messages within games, and game-related issues to posts about JavaScript and the more technical aspects of learning how to make games. I’m not sure if this is going to alienate some of you guys, but as this is a personal blog…well…I’ll write what I want to write. However, I have now separated game related posts into different categories (as I’ve noticed from the traffic stats that quite a few people filter by the ‘gaming’ category specifically when reading this blog):

  1. games - All game related posts of all kinds will sit in this category

  2. gaming - Posts about existing games/game reviews/critiques of games/etc. Also more general game design-y musings and theories

  3. game dev - Posts like this one, that go more into the technical aspect of learning how to make games and specific projects

On to what I actually wanted to talk about:

Git branching

I’ve been thinking about Git branching strategies. As Gwen is a small one-person project I probably don’t really need to worry about things like this too much, but I’m treating it as a small-scale test that I can learn from for future scenarios as well, so in that sense considering things like this can be important. I found this article very interesting, but so far I just have two branches - master and development.

Naming conventions

I’ve also been looking into JavaScript naming conventions and decided to use Douglas Crockford’s guidelines. Tonight I’ll be going through what I have so far and renaming where required.

Avoiding global variables

One thing that I’ve been hearing and reading a lot is how bad global variables are due to potential clashes in the code, since they can be accessed by anything at any time. This is a problem for me because so far I don’t yet know of another way (much less a way that’s as simple as just declaring a global variable) to refer to my arrays.

Data flow diagrams

I remember learning about entity relationship diagrams and data flow diagrams in my high school Information Systems class (thanks, Mr. Carboon!) in years 11 an 12. At the time I didn’t really consider that I may actually have to ever use this knowledge, but the more I try to get the structure of this thing straight in my head the more I realize that I need to find a clear way of documenting what various entities actually do and how they respond when the player interacts with them.

This made me really appreciate my Info Sys teacher for forcing us to learn this stuff and drilling it into our heads. It was a long time ago and I have to do some major brushing up, but at least I still vaguely remember some of this stuff. I wonder if Mr. Carboon will ever get to see something I made and think “Yup, I contributed to that.”


Even though the complexity of building this thing has been ramping up as I get a handle on what I have to do, the idea for this game has stayed the same in terms of gameplay. I’m very wary of not letting this turn into some big complicated overambitious “thing” and don’t think that this will be a problem. I have an idea, I’m in the process of documenting it, and I know where it has to end up. As a player, the gameplay will be fairly simple - really centering around just one kind of interaction with different objects. As the person making this, the actual development process is what’s getting tough. I do feel like I’m heading in the right direction, though, and progress is being made on a daily basis (and most importantly I’m learning new things on a daily basis).

© - 2021 · Liza Shulyayeva ·