I’ve taken programming classes for over five years, however, just programming is not my end goal. My goal has been to get into the field of game development. 

Classes that tackle game development are rather rare and aren’t offered at most schools, so I haven’t had the opportunity to learn in a classroom environment. This means that my goal depends on my drive to learn game development in my own time. After looking into what makes a game, specifically the technical aspects of it, I found that I have much to learn. 

Development of a game can be divided into five general sections: the engine, programming, visuals, audio, and testing.

Engines are software platforms that provide “the core functionalities and features for developing and running games.” The most popular game engines today, such as Unreal Engine and Unity, are extremely versatile and allow the whole or most of the game development process to be done in that platform alone. 

Any game, at its core, is a bunch of code. And while you can develop games without programming knowledge, it becomes very difficult at the higher, more professional levels. Programming language is usually up to user preference, although some tools may require specific languages.

Visuals and audio are rather similar in the fact that both require great creativity and are crucial to games today. Any model, texture, sound effect, and music are created from scratch or borrowed from some library. Software for both categories are typically used by artists of all kinds; music producers, artists, graphic designers, and such.

Finally, testing is the “last” process of developing the game. This could be seen as the verification and maintenance steps of software development. Making sure that there are no bugs and that every other section is working properly is crucial to a better user experience.

That’s a lot of things to do in order to create a game. So many processes, so many programs and tools to learn, and so many skills I need to learn. Learning a tool is one thing, mastering one takes so much time and effort. It makes me think about how I want to tackle my goal, do I focus on one section of game development? Do I learn a decent bit of every section? I have no clue.

It feels like the path to achieve what I want becomes longer and longer. Procrastination, poor time management, and lack of dedication only worsen that. 

If you want to achieve things, you have to take the first steps towards them. I want to land a career in game development and in order to do so, I need to learn. In my free time, I will spend some of it learning online and tinker around with free game development tools until I feel confident in my ability. I could then develop my own game and take those next steps toward my goal.

https://www.linkedin.com/advice/0/which-technologies-tools-do-you-use-game-development#:~:text=Some%20of%20the%20testing%20tools,analytics%20to%20improve%20your%20game.

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

A Scrum Sprint is an event that allows a scrum team to work towards a goal in a time-boxed event that is known as a Sprint. In my class we have been talking a lot about Sprints as well as all of the different roles that each of the team members may be. On top of that, we discussed what each role does and even had a mock Sprint in order to see what they are like. I think that Sprints are really helpful in order to help get work done, and that it works a lot better with less people as long as you trust that they will get their work done successfully. As a computer science major, I feel like I will take place in a Sprint at least one time throughout my career, so I enjoyed having a mock in order to feel what it is like. However, since the mock was only one day, we didn’t get to experience the different roles in a team. But while researching, I came across a website called Atlassian which I think does a really good job at explaining all of the different steps in a Sprint, as well as what each of the roles in a Sprint team does and how they help achieve the Sprint goal.

There are three major roles in a Scrum Team. These roles are developers, the product owner, and the scrum master. In my opinion, developers are the most crucial role in a Scrum Team. Developers are the ones that do the actual work in the Sprint allowing the team to get closer to the Sprint Goal. They do things such as organize, design, test, and deliver the software. Basically, they are the workers that make the develop the software and make sure it does what it is supposed to. One of the other major roles is known as the product owner. The product owner is the member of the Scrum Team that interacts and communicates with the customer. They find out what the customer is looking for in the product and then relays it to the rest of the team, which results is finding out the product goal. According to Atlassian, “Since agile teams are, by design, flexible and responsive, it is the responsibility of the product owner to ensure that they are delivering the most value. The business is represented by the product owner who tells the development what is important to deliver.” This further shows that the product owner needs to be a trustworthy person and good at communicating with others, otherwise the Sprint could fail before it even begins. The final major role in a Scrum Team is known as the scrum master. The scrum master is the glue of the group. This role helps out the other two by helping the product owner define value, while also helping the developers deliver the value that was promised to the customer. The scrum master is like the leader of the group, helping where they can while also making sure that the work gets done on time without error.

Synopsis: https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

The blog post I selected this week is an article by Sanura Hettiarachchi called “10 Clean Coding Practices”. I chose this article with the homework and the expected lectures coming up this week on coding practices. Prior to reading the article I understand effectively using white space, making comments, and declaring meaningful variable names are practices often recommended. When reading the blog, the article goes through each of practices mentioned in detail as well as other tips. When writing variable names, I often have a hard time making meaningful variable names for long declarations. In the article it provides good examples of condensing these variable names for example, changing

“Person [] peopleFromIndiaWhoCanSpeakFrench;” can be condensed to “indiansSpeakingFrench”. The article also provides bad coding practices with variable names that many without understanding of clean coding may not follow.

In addition the article talks about following correct name conventions corresponding to different coding languages. The example brought up was someone in C# would Pascal Case while someone in Java would use CamelCase and it is important to research practices for a specific language to keep documentation clean.

When writings methods, the article suggests method names that effectively describe its uses but something that stuck out to me when describing practices for methods were keeping parameters to a minimum of three. Often in my practices in Java, I use alot of parameters in my methods which I will not keep into account.

Also described that I found very helpful is where to declare variables, Sanura recommends declaring variables at their point of use instead of at the top of a method so that you don’t have to scroll back and forth to understand the code.

Another really good practice I saw in the article is reducing numbers which can be simplified to a constant variable.

Other practices mentioned include not to leave dead code/commented code, minimizing extensive nested conditions, try not to implement long functions, avoid code duplication.

When reflecting on this blog on it’s use of the course as well as in my career, I can see these coding practices being very useful and something I can always use. In addition, I am expecting to see some of these practices in the upcoming lecture this Tuesday and Thursday coming up. With the project on Markdown to HTML I can see the importance of following clean coding practices especially while working in a group with others to ensure everyone is on the same page.

https://medium.com/swlh/10-clean-coding-practices-e37ac283184d

From the blog CS@Worcester – Anthony Duong CS Blog by anthony duong and used with permission of the author. All other rights reserved by the author.

Since I am reading the way that I am while reading, I find myself not knowing what chapter I’m on unless I actively decide to take a look. After finally looking there was an entire chapter dedicated to an accurate self-assessment, the chapter with the pattern entitled “Be the Worst”. The pattern describes surrounding yourself with people who are much better than you are in efforts to improve one’s own abilities. Eventually you end up progressing to a point where you end up as equals with your team. I was then led to consider the team in which I would “take” on this adventure and my role in a team setting. I feel like this chapter allows for a good moment to reflect on your own career in relationship to others. You can’t accurately assess yourself without assessing how you are around other people. Each person on a team provides their own level of experience that can be brought to the table to progress not only the work but the team as well. 

The problem that this pattern resolves is the problem that your “rate of learning has leveled off”.  Knowing this I wish that I had recognized that this might be a problem that I was facing sooner. I think I had come to a point where I could have only taught myself so much that I needed to look to others in a way that would allow me to improve myself in the same way that I described previously. As much as I am often aggravated by cultural norms, I should see that I too am influenced by them. The cultural norm at play is the encouragement of attaining a position of superiority as fast as you can. It has influenced in a way that may have stunted my growth a bit and could have potentially led me towards something a bit more selfish instead of a more noble pursuit such as mastery.

After learning of this pattern, I think I will work in a more self-aware way. Perhaps in a way that is not so clouded by ego but more so driven by the pursuit of mastery that many others alike are also on.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.