My Evaluation

The evaluation I received turned out to be much better than I expected. It would seem that I am probably somewhere around a B.

It seems the things I need to work on fall into one of two categories. The first being level of involvement. The second being communication.

In terms of level of involvement, I especially need to work on being more outspoken in class. However, I think I should also work on being more involved in the group meetings as well.

Communication is where I think I lost the most points. I lost points on my project pitch and my self evaluation because of the way that I presented myself. It sounds like the content of the self evaluation was good, but it was an issue with the writing style. And I think I had a decent project idea, but when I got up in front of everyone to speak I definitely lacked confidence.

I think the biggest thing I need to do is learn to be less reserved and not be afraid to speak.

Planning Phase Graphics

I met with Cameron earlier to discuss him helping me with the user interface graphics for the planning phase. The biggest feature we discussed is having some sort of indication of where a piece will be placed after it is moved or copied. I want to either show the piece dragging, or have some transparent squares hover around the mouse to show what the placement will be when the user releases the button.

It looks like merging the latest version back into the trunk has caused some problems. My files seem to have rolled back a few commits. I think we may need to straighten out the trunk before any new changes start getting made.

I think I can still get my newest files from git, and since Cameron will be adding to, or changing my graphics, we may want to start from an older version anyways.

Git Branching

When I began to refactor planning level, I made some big changes that broke a lot of things. I knew this would happen, and I tried to leave everyone else a way to continue working by using copies of the original files I made. This was a really bad strategy.

I've since learned that it is very easy to make a branch in git, and also very easy to merge the branch back to the trunk when it is time. There is even a graphical tool that displays the repository tree. Now that I understand how branching works in git, my workflow with the repository will probably change.

The trunk is back on track now, and I have a good chunk of the new planning level completed. I have also added a lot of interface features to planning level. Users can now insert different tiles using the keyboard, as well as lock and unlock different colors. Selection is now capable of correctly selecting partial cells, and move and copy are done using the mouse.

Time to Refactor

I am rewriting my code for the planning level. Now that I have a better understanding of what exactly it needs to do, and how it integrates with the other parts of the project, a number of flaws with my first version have become apparent.

The undo / redo system was becoming overly complicated due to the way that I abstracted the operations that go into the stack. Rather than having a different object to represent each type of operation, I now have one object that can be initialized to represent any operation. I am also getting rid of the idea that single and group operations need to be handled separately. To accomodate group and single operations being performed by the same function, the operation object can now contain a list of instructions. This means that instead of pushing move, move, move, group(3) onto the undo stack to represent moving three selected objects only one operation object needs to be pushed.

User input will be mapped to the keyboard and mouse differently, and I will be trying to avoid some graphical bugs that came up the first time around.

Input For Grid Operations

Today I mapped mouse and keyboard input to each of my grid operations. The user can now manipulate instructions during the planning phase. They can insert instructions, as well as move, copy, and delete instructions or groups of instructions.

In the process of doing this, I found and fixed several bugs in my original movement functions. They were all pretty easy to fix, however, I am realizing that undo and redo are going to continue becoming more and more complex with every feature added.

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.

The project begins

I am working on a project called Automaton. It is an educational game that will teach programming concepts. I really wanted to work on a game of some sort, so I am happy I got this group. I think I got good teammates, and I like Luke's project idea.

We are just getting started, and I have not done a whole lot yet. I have submitted several user stories to the form Ezra created, and I am beginning to learn javascript again. I will also be getting familiar with git, as it is the repository system our group has chosen to use.

Revised Project Proposal

Here is the link to my revised proposal: https://www.dropbox.com/s/yuz00t5p46mjnc1/zombieproposal.pdf

I trimmed the project down a little bit to make it more reasonable to do in 12 weeks. This meant getting rid of multiplayer entirely, and addressing the possibility of trimming other features. I also completely changed my timeline. It now has dates for specific feature completion.

Ideal Design Team

Dedicated, Intelligent, Gamers

I chose "dedicated" because I want to work with people who are committed to the project and want to put in the effort and time required to complete it.

I chose "intelligent" because I want to work with people who know what they are doing.

I chose "gamers" because I am envisioning a team for my specific project, and I think people that enjoy video games would be good at creating a game, and evaluating their work.

The top three words I didn't choose are:
Creative, Friendly, and Efficient

Creativity is a desirable trait because we are creating a game from nothing, and need to come up with ideas for content.

Friendliness is a desirable trait because we will be spending the next 12 weeks or so working on a project together, and it would suck to be stuck cooperating with unfriendly people for that long.

Efficiency is a desirable trait because we will be working on a large project that is going to take a lot of time to complete, and it will take even longer if we are inefficient while we are working on it.

Proposal Reviews

Here are my reviews for the Min 3D project, and the Mechanapp project.

https://www.dropbox.com/s/fz5dqynd2ywozdz/ezra.pdf

https://www.dropbox.com/s/x8e1heg11jkbrw9/vickers.pdf

Project Proposal

Here is my project proposal: https://www.dropbox.com/s/q7zdhqe7dzht2ps/proposal.pdf

I originally created it in open office, and the conversion to .doc, and then to .pdf has messed up my formatting a little. I've wrestled with Microsoft Word a little bit, and it is refusing to cooperate, so my pictures are slightly out of place.

AGILE and elicitation

    I do CAD drawings for my friends small business. I think that we have had problems with the elicitation phase in the projects that we have done so far. There have been several instances where we have needed to make changes late in the project, or have had some miscommunication about what was expected. With drawing, as with programming, it can be difficult to make certain changes to the project because dependencies are created as you progress. I think that parts of AGILE could be applied to the way we deal with clients to avoid some of the problems we have had in the past. More specifically, I think we could increase the frequency of client meetings, and focus on having something tangible to show them each time. Also, if we were to work more closely with the client, I may be able to give them an understanding of what types of dependencies are being created, and make it easier to avoid getting stuck with a change late in the project.

Preliminary Timeline

Here is my preliminary timeline: https://www.dropbox.com/s/641eije1vnq0c5e/timeline.pdf
 I think it may end up changing significantly once I find out more about each requirement. I am not sure what the modeling phase is, or what we will need to do in terms of marketing.

Concept Paragraph

    There are many zombie shooter games, but none whose mechanics are focused around day to day survival, and the construction of your own personal fortress. It is common now to see games with destructible terrain, and some mechanic for improving home base, but with a few notable exceptions like Minecraft or Terraria, the amount of creation a player is capable of is rather limited. Also, I am not aware of any zombie survival type games that use random world generation, and allow the player the freedom to decide what to do and where to go, as the zombie games I have played tend to be mostly linear.
    I would like to create a top down zombie shooter that employs random world generation, and the Minecraft approach of spawning the player somewhere with no items, no direction, and no clear set goal other than not dying. The world that the player explores should be a source of building materials that can be taken and arranged more strategically somewhere else. However, unlike Minecraft, I want the player to actually have to struggle to survive in a dangerous environment, and the focus of building should be defensive strategy rather than aesthetics.
    The problem with most sandbox games I have tried is that they are only difficult during the time you are learning how to play. Once you have figured out how the enemies work and what the items do, the game becomes boring because you realize that nothing in the game presents any real danger to your character. This game will provide the same freedom as some of the other options, but will hopefully manage remain challenging even after the player has learned how to play. Gamers that like the concept of sandbox games but haven't yet found one that provides enough challenge to have some staying power will like this game.
    We will sell the game for a modest fee, and make the source code available for anyone that wants it.

Software Engineering

    The Wikipedia article on software engineering opened my eyes to how broad a topic it is. It would seem my education in computer science has been focused mostly on computer programming, rather than software engineering as a whole. I have acquired the abilities to write code in a number of languages, and analyze the efficiency of a program, but I have never had a class that discussed the different types of design processes like Waterfall and scrum.
    Also, I have been curious about what employment will be like after I graduate for some time, and the wiki article shed some light on that subject. It is nice to see that workplace injuries are rare, and that many that graduate with my degree do not have to work more than 40 hours a week.