Git and Game Development

     A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have. 

  It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.

https://www.unrealengine.com/en-US/ue-on-github

https://www.gamedeveloper.com/production/agile-game-development-with-scrum-teams

https://starloopstudios.com/best-agile-practices-in-game-development/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Git and Game Development

     A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have. 

  It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.

https://www.unrealengine.com/en-US/ue-on-github

https://www.gamedeveloper.com/production/agile-game-development-with-scrum-teams

https://starloopstudios.com/best-agile-practices-in-game-development/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Git and Game Development

     A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have. 

  It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.

https://www.unrealengine.com/en-US/ue-on-github

https://www.gamedeveloper.com/production/agile-game-development-with-scrum-teams

https://starloopstudios.com/best-agile-practices-in-game-development/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Git and Game Development

     A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have. 

  It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.

https://www.unrealengine.com/en-US/ue-on-github

https://www.gamedeveloper.com/production/agile-game-development-with-scrum-teams

https://starloopstudios.com/best-agile-practices-in-game-development/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Week 10 choosing an Open Source license

Over the past few weeks, we have been learning about licensing and the different kinds and uses they all have. We have now even started to choose/implement our own inside our own group projects. In addition, the homework we did had to do with licenses.  With so much already learned about licensing why would I gain from learning more about this topic? Sometimes when doing work in a time-constrained environment you don’t absorb all the information and with this being at my own pace I can review and learn new things I may have missed or not seen. 

With all the information we have been learning about licenses you may think it’s hard to retain all this information but one key thing you should remember is that licenses can be split up into two categories copyleft licenses or permissive licenses. A copyleft license basically makes the modified open-source work be released under the same license. The original copyleft license is GPL (general public license) which means that any project using GPL must be open source as well. Another example of a copyleft license is LGPL (Lesser General Public License) is considered much more commercial-friendly than GPL because it has no requirements for software that only uses the license project. On the other side of the spectrum, there are permissive licenses that don’t put restrictions on people using a project. An example of a permissive license would be MIT which allows users to do whatever they want except they must contain the copyright statement and the original license. Even with all the possible choices for a license, you must ask yourself what your project needs and look at examples if ever stuck. Also, don’t forget to choose a license because this will cause much more harm you will restrict your code from being used by anyone except yourself.  

Reading this article allowed me to see licenses in a more simple and enclosed way instead of being bombarded with multiple different licenses. Being able to split up licenses into categories in a concise way allowed me to see how licenses weren’t as complicated as I thought. Now when I am shown a license I can automatically put it in a category and understand the major functions of what restrictions may it have. Also, it is easier to know the purpose of my project and be able to pinpoint the exact license I may need. I know I make it sound simple but the process in itself can be overwhelming having a foundation can make the process not as nerve-racking. 

https://www.codecademy.com/article/choosing-an-open-source-license

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Kubernetes Clusters: What they are, and why it may become the most in-demand skill in the 2020’s

To say that the use of containers has revolutionized how applications are designed and deployed would be an understatement. Gone are the days of applications being run on physical servers, as due to the issues with resource management, the alternative of using virtual machines to run multiple applications on a single CPU provides vastly more flexibility to developers. One downside of virtualization, however, is that these virtual machines are considered rather “heavy.” Each VM is a fully-functional machine, running a full OS in addition to whatever virtualized hardware is added on. In environments where each server’s CPU may have multiple virtual machines running, the same issue occurs; high resource usage.

To solve this problem, the use of containerized software has become common. Containers share the same OS instance as the host machine, as opposed to a VM, which has an entirely separate OS. This leads to a multitude of benefits, such as reducing image storage size. While a VM uses images multiple gigabytes large, container images are much smaller; often measured in megabytes. Additionally, containers are entirely independent, meaning they are much more easily portable, which leads to faster and easier deployment.

One major drawback to containers is the upkeep. Containers must have a specific amount of resources added to them, such as memory usage, while also, like anything else, can fail and need repair.

Enter Kubernetes; an open source platform designed to automatically conduct these maintenance tasks. Kubernetes uses clusters as the basis for their infrastructure, each containing nodes which run and manage the application. Control plane nodes manage scheduling, the API server, and other services. Worker nodes are where applications are actually run, with larger applications using more worker nodes than smaller ones.

If such a platform is so valuable, why are so many positions left unfilled? Because jobs working with Kubernetes are hard.

On the one hand, developing and maintaining applications with Kubernetes requires experienced engineers, and time. The nature of the environment simply demands developers have the knowledge and experience to implement it.

On the other hand, because Kubernetes is such a new technology, the field is rapidly evolving, requiring developers to evolve along with it. Each change requires testing and optimization, as well as programmers needing to continue to broaden their expertise.

Why is this problematic? In addition to creating a work environment prone to causing burnout among employees, engineers working in this field can outgrow their positions quickly. As they gain more experience and widen their skillset, many move on to positions that offer higher pay. According to Forbes, Kubernetes engineers spend an average of just 18 months in their positions before moving on.

This creates a cycle; engineers are hired to work on Kubernetes platforms, hold their positions for a short while, and either due to the intense workload, higher paying positions, or a mix of both, move on. This leaves an opening in their previous position, which must be filled by a new hire. Rinse and repeat.

Works Cited:

Budhani, Haseeb. “Council Post: Addressing the Kubernetes Skills Gap.” Forbes, http://www.forbes.com/sites/forbestechcouncil/2023/05/10/addressing-the-kubernetes-skills-gap/?sh=2a1430223f42. Accessed 20 Nov. 2023.

“Overview.” Kubernetes, kubernetes.io/docs/concepts/overview/. Accessed 19 Nov. 2023.

Poulton, Nigel. “What Is Kubernetes, and Why Should I Learn It?” Www.pluralsight.com, 2 Jan. 2023, http://www.pluralsight.com/blog/cloud/what-is-kubernetes#:~:text=Kubernetes%20is%20notorious%20for%20having. Accessed 20 Nov. 2023.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Reflection on Best Practices in Software Engineering (Week-10)

Overview

In the dynamic field of software engineering, the SOLID principles stand as critical guidelines for designing maintainable, scalable, and robust systems. Introduced by Robert C. Martin, these principles encompass Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP). This post explores the essence and practical application of each principle in modern software development.

Single Responsibility Principle (SRP)

SRP champions the concept that a class should have a single responsibility, thereby promoting modularity. This approach simplifies software, making it easier to comprehend, debug, and update. Personally, adhering to SRP has streamlined my coding, enhancing readability and maintainability.

Open-Closed Principle (OCP)

OCP dictates that software components should be open for extension but closed for modification. This principle underlines the importance of designing flexible systems that can adapt over time without needing modifications to the existing code. In my practice, OCP has been crucial for developing systems that are both flexible and robust.

Liskov Substitution Principle (LSP)

LSP asserts that objects of a superclass should be seamlessly replaceable with objects of its subclasses without affecting program correctness. This principle emphasizes the significance of robust class hierarchies. Adhering to LSP has helped me maintain consistent and reliable class structures in my software.

Interface Segregation Principle (ISP)

ISP advocates for the creation of specific interfaces over general-purpose ones, ensuring that clients are not forced to depend on unused methods. This principle aids in organizing code more efficiently and mitigating the impact of changes. Implementing ISP has allowed me to develop more focused and efficient interfaces in my projects.

Dependency Inversion Principle (DIP)

DIP emphasizes that high-level modules should not depend on low-level modules, but rather on abstractions. This principle fosters a loosely coupled architecture that is easier to test and maintain. Applying DIP has been instrumental in my development work, enhancing system flexibility and testability.

Personal Reflection and Application

My experience with the SOLID principles has been transformative, sharpening my coding skills and altering my approach to software design. These principles have enabled me to develop software that is not only theoretically sound but also practically effective, impacting the quality of my work significantly.

Conclusion

The SOLID principles are not merely best practices; they represent a mindset shift towards better software development. Understanding and implementing these principles can dramatically improve the quality, maintainability, and scalability of software. As I progress in my career, these principles will continue to shape my approach to software engineering.

Resources

  • “Principles Of OOD” at butunclebob.com
  • “SOLID: The First Five Principles of Object Oriented Design” at butunclebob.com

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

Software Licensing

Software licensing is everywhere in the technical world, and for good reason. Without it, our current copyright laws would make it impossible to distribute software in ways that are both beneficial for the user and developer. Fernando Galano does a great job explaining what software licenses are and how they are used in his blog, “Understanding Software Licensing” (https://www.bairesdev.com/blog/understanding-software-licensing/).

What is a Software License?

In short, a software license is a legal contract between the developers of a software and its users. We, as users, have all been asked to check a box in the past agreeing that we have read and agreed to the terms and conditions.  These terms and conditions are called an end-user license agreement (EULA) and spell out the rights and liabilities of both the user and software provider.

What Does a Software License Cover?

EULAs are typically large documents that contain information on how the end-user may install, modify, copy, or distribute the software. These are the more common things to find, however, they are not limited to this.  EULAs may also specify time of use, pricing, and support. These documents are usually very large because of the extent of topics they cover. 

Different Software Licenses:

Public Domain License:

  • Software under a public domain license can be used, modified and distributed freely with little to no restrictions. Not all free software has a public domain license.

Copyleft License:

  • Software under a copyleft license may be modified and distributed providing the modified software is distributed under the same terms as the source code.

GNU Lesser General Public License:

  • Software under a GNU Lesser General Public License may have its code altered or used in other software and distributed under a different license. 

Permissive License:

  • Permissive licenses are open sources licenses with requirements on how users may modify, reproduce, or distribute. This gives developers control over what happens to their code.

Proprietary Software License:

  • Typically used for commercial software. Provides the greatest restrictions for users and typically are not allowed to modify, copy, or distribute. 

Using Software Licensing Moving Forward

Quoting the first line from the blog, “Your product could be phenomenal, but before you deploy it, you need to grapple with the legalities surrounding the distribution and usage of your software.” (Fernando Galano).  It is clear to see that without a proper grasp of how software licensing works, development of software can only get so far. The next step in being able to distribute work is to license it properly for its intended use.

From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.

CS-343 Week 10

GRASP (General Responsibility Assignment Software Patterns) assigns responsibilities for different modules of code in object-oriented software development. There are seven types of roles assigned to classes and objects to easily organize the responsibilities. These roles include Controller, Information Expert, Creator, High Cohesion, Low Coupling, Polymorphism, and Protected Classes. It is important to note that GRASP is occasionally paired with SOLID principles, making for the combination SOLID GRASP. Design patterns like this help keep code clean and more organized, making it more comprehensible and reusable.

Controller suggests that the entity responsible for handling a system operation should be its own class to act as an intermediary between the user interface and the logic of the program. This helps separate concerns as well as improve flexibility of the whole system. Information Expert focuses on assigning responsibilities to classes that include the most information required to fulfill them. By following this principle, we can design systems where responsibilities are distributed efficiently amongst classes which in turn reduces dependencies. Creator guides the allocation of responsibility for creating objects. A class should be responsible for creating objects of other classes if the first class aggregates or has a composition relationship with the second class. By following this, there will be less coupling between classes and ensures better maintainability. High cohesion advocates designing classes with a clear and focused purpose. Each class should have a single responsibility and capture related behaviors and data. This provides easier comprehension of the code and simpler test cases to write. Low Coupling relies on designing classes with minimal dependencies on other classes. The less interconnections between classes allows to create a more modular system and improves maintainability since changes to one class are less likely to affect other classes. Polymorphism enables objects of different classes to be treated the same throughout a common interface in object-oriented design. Leveraging this principle allows for the design of systems to be extensible and adaptable to new requirements and promotes loosely coupled systems.

Applying GRASP principles ensures a clear distribution of responsibilities and promotes low coupling and high cohesion among classes. These principles help create an understandable design architecture while also providing the ability to adapt to future changes. This also helps team members collaborate due to better facilitation for communication among developers and it establishes a common understanding of each component’s role and interactions.

What is GRASP (General Responsibility Assignment Software Patterns)? | Definition from TechTarget

GRASP Principles: Object-Oriented Design Patterns | by Patrick Karsh | Medium

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Should we still use SOLID Principles?

While I was perusing for an article to write about this week I found this interesting blog post posing the question, “Why SOLID principles are still the foundation for modern software architecture”. The post is written by Daniel Orner, a Software engineer from the likes of Flipp and formerly IBM.

Daniel starts by explaining what exactly is “SOLID”, he attributes the meaning of SOLID to “the writings of Robert C. Martin in the early 2000s” which provided a framework for creating quality object-oriented programs.

Daniel then covers what has changed since the 2000s but also what hasn’t. Things that have changed are the popularity of scripting or dynamic languages has risen greatly, some facets of object-oriented programming have become meshed with functional programming, open source software has become extremely popular, and microservices have seen massive growth in use since the 2000s.

However, things that haven’t changed are that programs are still written and modified by people, there is still a form of organization/separation of code regardless of the language used, and code can be used for either internal or external purposes. I believe that all of these facets of programming may never change no matter how much time passes. Even with the advancement of AI, I still believe that the human factor in programming will always be important. When faced with potential moral or ethical problems, a human element would always result in a better outcome than an AI could/would.

Daniel then goes through each of the five principles and alters them to become more general and applicable to modern programming trends. He starts by altering the single responsibility principle to “Each module should do one thing and do it well.”, the open-closed principle to “You should be able to use and add to a module without rewriting it.”, the Liskov substitution principle to “You should be able to substitute one thing for another if those things are declared to behave the same way.”, the interface segregation principle to “Don’t show your clients more than they need to see.”, and finally he left the dependency inversion principle as is!

Daniel then wraps up his post concluding that modern SOLID is ensuring that your code is not surprising or confusing to anyone who will use or work with it, keeping things reasonable, and properly organizing said code. Reiterating that SOLID is still key to creating and maintaining well-written code.

Overall, after reading Daniel’s post it allowed me to widen my view and understanding of the solid principles. After comparing his new definitions to the ones crafted by Robert Martin, it showed how well thought out SOLID principles were to be able to last 20+ years already and remain relevant for plenty more to come. The SOLID principles offer a framework not only for object-oriented programming but programming in general and Daniel showed this impeccably just by changing a couple of words in the definitions while keeping the same meanings given to the principles back in the 2000s.

Article Link: https://stackoverflow.blog/2021/11/01/why-solid-principles-are-still-the-foundation-for-modern-software-architecture/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.