As I’m learning JavaScript I notice that the challenges I’m facing have shifted through stages that look something like this:
- What the heck is the syntax for this? (“How do I make it move?”)
- How do I code this one feature/logic challenges. (“How do I make them move in unison?”)
- How do I make it run well/optimisation challenges (“What’s killing my fps?”)
- Math challenges. (“How do I make this entity follow this rotating entity as its angle changes?”)
- Overall organization and structure of the entire project and entity relationships. (“WTF IS GOING ON I DO NOT REMEMBER THIS”)
Of course I face issues in all four of those stages, but right now my biggest issue seems to be keeping track of this thing as a whole and deciding what is best put where. Because the entities in this project are so reliant on each other (and on timers!), one action is usually relevant to at least two different entities.
Don’t get me wrong, it’s not like I just put crap in willy-nilly. I think about where things go and have from the beginning. For a while it was fine, but now it does feel like it’s getting too bloated. So bloated that even I’m forgetting some of the interdependencies I have going on. If I could just make some sort of diagram for myself that I can continuously update with the different relationships between entities and other elements in the code. I remember learning about ER diagrams and data flow diagrams in year 11/12 Information Systems, but not sure if either of those is appropriate for what I need (and if so, which). Or is it a case of “If you’re getting confused by your own code it must be too messy”? Do people usually forget how things relate to each other in their own code once it grows, even if it’s not actually all over the place and effort has been put into keeping it tidy, or is it just me?
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):
- games – All game related posts of all kinds will sit in this category
- gaming – Posts about existing games/game reviews/critiques of games/etc. Also more general game design-y musings and theories
- 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.”
Scope
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).
