Layer Locking and Multiple Selection

I have modified my planning level to allow the player to lock different colors from being modified. This means that they will be unable to insert, delete, or do anything else to instructions of the locked color(s). This is an important feature that will allow the user to perform group selections on a desired set of colors.

I still need to think about what should happen if the layer that an undo or redo operation wants to modify is locked.

I am also starting to work on keeping track of which instructions the user has selected. This will enable the user to move, copy, or delete multiple tiles at once.

Moving Forward

I'm having trouble coming up with content this week, because I have not done much with the project lately. I had travel plans over spring break that took several days longer than expected, and have been playing catch up ever since.

So here is the plan moving ahead:
   - I will make three posts this week, which will start getting my blog back on track.
   - I am planning on splitting my planning level file into multiple smaller files, and refactoring.
   - There was a bug found with my redo function. It will get fixed during the refactor.
   - I will work with Cameron on adding svg support.

Visitor from VanDyke

We had a guest speaker come to class today and talk to us about software development in a real workplace. This was interesting because I don't really have a clear idea what life will be like working in CS. He described specifically what the environment his developers work in is like, as well as the practices they use. I am not so sure I like the idea of a "bullpen" type environment. I can see why it would be useful for everyone to be in the same room, and able to talk to each other, but since I normally work alone, it seems like it would be very distracting. It sounded like pair programming is not something that VanDyke makes use of. This is kind of surprising, but I guess since everyone is all together it's sort of like pair programming anyways. The main thing I took away from the talk is that "high-bandwidth" communication is important for a development team to work well. This is something that I already knew, and is being reinforced by my experience in this class. Good communication is essential for any kind of team to function well.

Self Evaluation Evaluation

I had a bit of a hard time writing my self evaluation. The biggest problem was that I hadn't planned on what kind of metrics I wanted to present. This is definitely something I will need to change for next time. When I actually sat down to look at the metrics I could present, I realized that they were kind of meaningless. As we discussed in class, number of commits, or number of lines of code are not very good measures. In order to have better metrics for the next evaluation, I will keep track of the number of work sessions I attend. Also, I will be thinking about other ways that I might be able to measure my coding progress.

After I had written and submitted my own evaluation, I looked at a draft of Ezra's evaluation. At that point he had close to five pages, and besides being overly long, I thought it looked really good. That was when I realized that the self evaluation exercise is all about spin. Ezra has been vital in our project, and he probably had more to work with in his evaluation than I did, but I don't think that that accounts fully for the differences in our evaluations. I see that I have a way of minimizing my own achievements when I stop to look at them. I also see that given the right spin, Ezra's already good performance on the project looks absolutely phenomenal. So in the end, it's not just what you did, but your ability to present what you did to others that matters.

Overwrite Options and Group Operations

I have added two new features to my PlanningLevel object. The first is the ability for the user to choose overwrite behavior. If a player were to try to move an instruction from one grid cell to another that was already occupied, there are two ways that the operation could be finished. Either the old instruction is deleted, and the moved instruction put in its place, or the move operation is rejected, leaving both cells unchanged. I have implemented support for both, and it is up to the player to decide which they prefer. This makes undoing an operation more complicated. In order to undo properly, not only does the moved instruction need to be returned to its starting cell, but the overwritten instruction needs to be replaced.

The second feature I added was support for group operations. There is now a group version of each of the original five operations. These functions take a list of instructions or coordinates, and apply their operation to all of the instructions in the list. This will allow the user to drag select and delete or move a whole bunch of instructions at once.

Undo / Redo

Over the last week or so I have been working on the data structure that represents the grid in our game. It is a three dimensional array. The first two dimensions represent x and y on the grid, and the last dimension is there because there could be up to four instructions in each square of the grid. I wrote functions that allow instructions to be inserted, deleted, copied, and moved. This may sound trivial, but because of the way Javascript handles arrays it required a little more thought than it would in a language with a conventional array system. I also created two stacks that keep track of the changes the user makes, and allow for undo and redo operations.

We are starting to tie different pieces of our program together, and I think we are close to having some visual and perhaps interactive results. This is really exciting, because much of what we have done so far has been rather abstract. It will be cool to be able to actually see our code do something.

Thoughts on Javascript

Over the last few weeks, I have been learning Javascript. I am still somewhat inexperienced with it, but I have already found a number of features of the language that I really like, as well as some that are not so good.

I think my favorite thing about Javascript is the ability to alter objects on the fly. I like knowing that I have the ability to modify objects whenever I need to. However, this could make some really confusing code so I try to avoid the need to use this feature.

I also really like working in a language that isn't picky about types. Being able to put multiple types into the same array is really convenient. It is also makes testing code that depends on other code that hasn't been created yet easier, because I can substitute my own values for whatever input might be missing.

The last in my list of features that I like is the console. It allows the user to track all sorts of details about the state as the program is running. It also allows the user to inject code. This feature makes it possible to test code that isn't complete yet.

I have mixed feelings about the implementation of arrays. Javascript provides a number of convenient built in methods for accessing and modifying arrays, which is good. The problem is that these features come at the cost of speed. I could write my own functions to treat an array like a stack. I can't change the fact that Javascript chose to implement arrays in a less efficient way than other languages typically do.

I really don't like the way that Javascript likes to make variables global. In a large project like this, the last thing we need is to have every variable be a global variable. Javascript provides ways of dealing with this, but I find them counter-intuitive.

The last feature of Javascript that I will complain about is the way that objects are defined. An object can be the only one of its type, or it can be something that needs to be instantiated, depending on whether or not you define an object as a function. I find this to be kind of confusing.