#Personal Project Log
Over the course of this 2-week project, I'm going to try and keep a log of stuff I encounter every day. At the very least, this will let me keep track of problems that I get caught up on. I should be able to learn a lot about the way I work when comparing my final product to my scope of work using this log as a reference.
##Thursday, 27th of August
Today I am trying to sort connecting players into teams. After each player connects, I want to alert the game's admin and visually display each player as they connect. Angular is not updating so I looked up resources on using Socket.io with Angular. I found information about $scope.$apply which is supposedly made for situations like this, but my implementation doesn't seem to be working. I did find an article that said I should place Socket.io into an angular service which totally makes sense. I've been working on this for a while so I've signed up to receive help. +I fixed this issue. My task manager wasn't building properly, I spent about an hour and a half trying to fix an issue that I had already fixed. Great.
Yesterday I discovered an issue where my clients were receiving mutliple instances of the same message each time I sent something through a socket connection. Today I learned that if I use incognito mode that doesn't happen. It must be some kind of hold-over socket.io has when I restart my server and refresh a browser.
I've been reading on Socket.io namespaces and rooms. It seems like my game instances are really just namespaces, and then I can divide up all the minigames into their own rooms. I wouldn't have to pass around the incoming socket request anymore, it would just go directly to the desired namespace/room. I'm going to begin re-writing my structure to incorporate these elements, hopefully nothing explodes.
When I was replacing some of my server-socket code, I ran into an issue with my exports. I was importing socket.io into my game controller from app.js prior to setting my exports in app.js. I moved the export code higher in app.js and that has temporarily fixed the issue, although I'm concerned that will cause problems later.
##Saturday, 29th of August
I've been thinking about my architecture a lot today. I have a tendancy to overengineer and create problems for myself, so I'm going to simplify my project. There is no need for instancing, I'm going to be the only one presenting the project. I think that alone will get rid of a lot of the issues I anticipate for myself. I'll be pushing this last copy of my project, and the next commit will probably be significantly different.
##Sunday, 30th of August
I'm forcing myself to delete everything that I don't absolutely need to create an MVP and it's rediculous how much extra work I was making for myself. I've gone from 5 or so client routes to 3, vastly minimized my game-controller's code, and am continuing to see places where I can improve. I'm excited to work in this new, slimmed down project as I think I'll be able to progress much quicker. It's also mildly depressing to see how little progress I've actually made but I guess it's just a learning process.
I've been wondering how to pass values between controllers without using rootscope. I found an article today that suggested I just create a service that I can inject properties into. This seems pretty nifty to me so I'll be implementing that today as well.
##Monday, 31st of August
Today I've been working on creating my actual minigames. I've been wondering how I'll pass socket data from the clients to each individual minigame, and I've found documentation on Node's child processes. I'll be able to send sockets to each minigame based on some simple logic I can set up in the game controller and the child process (each minigame) treats it just like an event with a message parameter. I'm hoping this doesn't mess up socket.io at all and that it will just work, but maybe that is wishful thinking.
I've been playing with child processes for a few hours now. They are pretty tricky, at least when comparing against the kind of material we have been taught so far. It led to me looking into EventEmitters in node which are pretty neat. Upon further inspection, Child Processes are probably not the most elegant solution to my problem but I think I'm still going to try and implement them because they seem very powerful and interesting. I'm modifying my minigame-pool structure to accomodate these processes now, I'd like to get that done by the end of the day.
I think I have figured out how to use child processes with my minigames. I spent a few hours writing some code, saying "wait....that wont work...", deleting it, then re-writing it again some time later. After a few iterations of this I have a frankenstein-esque implementation of my original idea. Super pumped.
##Tuesday, 1st of September
I can create an instance of a Minigame with players attached to it now. Today I'm going to try and get my test minigame working (button-push.js). All it does is places players in a room for 30 seconds and counts how many times they push a button. The pushes are tallied up and whichever team had more button presses wins. My challenges will be figuring out how to 'check-out' players (make them unavailable to the rest of the application while they are in a minigame), how to route socket messages from the players to the minigame correctly and how to smoothly hand back the player objects to the game controller when the minigame is finished.
While I've been working on implementing my test minigame, I've been thinking about how I'll want to implement error handling. That doesn't really matter right now though because I've hit a bit of a roadblock. How do I alert all of the players joining a specific minigame that they are now a part of that game? Additionally, I'm beginning to wonder what happens when multiple instances of the same game run. I suspect that ChildProcesses won't play very nice with that scenario.
##Wednesday, 2nd of September
I didn't do a lot of work on the project today. I have an idea for how I'm going to handle specific minigame messages, though. Any minigame messages will be inside the CHANNEL.MINIGAME channel, and I'll pass along a simple object that has the values of 'game' and 'event'. That way I can store events only inside of the relevant controllers. I'm currently having an issue where my client isn't able to receive messages from the server in the minigame channel, but I'm just going to have to deal with that tomorrow.
##Thursday, 3rd of September
I figured out the problem I was having last night. Turns out Gulp wasn't running and I kept testing an old build. Wonderful. I got the message to send but now I am having problems with my child process. It seems like the process terminates itself immediately instead of staying open. This is fairly depressing and I'm going to try and see if I can use a socket.io namespace to save myself some trouble. Child processes are cool but there is no reason I should force them into my project, especially if namespacing works just as well with less trouble.
So, as a lesson to myself (again) in not overcomplicating things, I've worked out how to send a socket packet to a minigame correctly without using namespacing or child processes. I think I get excited about new or interesting technologies and then try to incorporate them into my project. Now I can work on actually making a real minigame.
##Friday, 4th of September
Today was all about fleshing out the minigame skeleton. The test minigame I've been using has been aptly named "ButtonPush." It involves pushing a button more times than the other team pushes a button. I ran into a scope issue today. How do I send event messages from the minigame controller to the admin client? It bugged me for a while, I tried requiring the admin connection from the main game controller among some other things. I then realized that I could just pass in the admin ID to every minigame as I create them. That didn't seem like the most elegant solution to me but I couldn't come up with a good reason not to do it. I tried it out and it worked! Now my minigames can talk to all their clients and the admin. This weekend I'm going to begin work on an actual minigame although I'm anticipating I probably won't have one fully finished by Tuesday.
##Monday, 7th of September
I mentioned on Friday that I was going to try and complete an actual minigame this weekend, however I looked at my code and saw that I was probably getting a little ahead of myself. The test minigame isn't entirely finished yet, so that comes first. That means a player has to join the game, play, score points and be sent back to the waiting screen. The points should be accurately scored and displayed on the admin's control panel. If I can finish that, I'll do a tiny bit of styling since I present tomorrow. Even though the 2+ weeks is up I think it would be a good exercise for me to continue working on this game, at least until I've brought it up to my original vision.
A problem just occured to me. How will I effectively aggregate all of the points across the (in theory) multiple minigames and present them to the admin? I'm gonna let that stew in the back of my mind while I finish the test minigame.
Also I'm sick of not having my CHANNEL object available everywhere. It is sloppy and inconsistent to just it some places and not others. I'm going to figure out how to correctly place a global javascript object in node. I'm thinking I could use the actual global object but that feels dirty.
I accomplished almost everything I wanted to do today minus the styling. I realize that is a very important part of web applications, but I don't want to do it and no one is here to convince me otherwise.
This is my last commit before I present tomorrow. Overall I am glad I picked socket io as I got to learn a lot about how powerful a simple tool can be. Looking at my 'final' project now and comparing against what I imagined it would be is interesting. I breezed through things I anticipated would give me a lot of trouble, and got severely hung up on things I thought would be easy. I think I've solidified my opinion that I really enjoy working on the server side of the stack, so I will try and pursue that in the future. I'm looking forward to continually working on this project, although serious work probably won't resume for a while.