Hey guys, its me...
So, for my vlog, I decided to do a "behind the scenes" video to document the programs and software I use to write my code, in case any of you are also interested in programming. Along with that, I included a demonstration of adding a new weapon in my game to show how my coding process works. It goes a little over 4 minutes, so apologies for that... (hopefully it's worth it though)
If you want to skip around, here's a little timecode of the video (they aren't links, sorry!)
0:00 - Behind the Scenes Software Explanation
2:55 - Coding Example
Enjoy!
Thursday, March 23, 2017
Interview - A Progress Analysis
I took the expert interview assignment as an opportunity to look back and reflect on my learning process over the past couple weeks, as we are already well into the project.
For the interview, I asked the following six questions:
I received three responses in total. I have their responses below linked. I will just be referencing excerpts in my analysis below, so I would highly recommend reading through their responses.
Eric Grimson - Professor of Computer Science and Engineering at the Massachusetts Institute of Technology and former Chancellor for MIT. He also taught an Introduction to Computer Science course on edX.org that I took (highly recommended).
David Kosbie - Associate Teaching Professor at Carnegie Mellon University
James Bloxham and Gina Yuan - MIT undergraduate/graduate students and MIT Battlecode competition developer (again, a highly recommended competition. Lots of fun)
With that, here are some of my takeaways and reflections about my programming adventure so far.
I had actually spent a great deal of time during my first week of this project focusing on learning these good practices. Documentation refers to the act of commenting in your code to make it easy to understand (using human language to describe what you are doing in code). Abstraction boundaries is what I talked about in an earlier blog post about using abstract classes to create an outline for your code. Modular design refers to separating your code into different classes, or chunks, and making them totally independent so you don't have to worry about implementation.
Professor Grimson's response reinforced that I have been focusing on the right things when building my game. When I started out coding, I did not know about these coding standards. Yet, I looked at other people's code and noticed how they were all set up in separate classes and packages to make their code modular. I decided to imitate this, even though it wasted a lot of time trying to figure out how classes interact. Yet, it seems that these are extremely important skills to learn for future programming projects, so I'm glad I "wasted" the time learning how to encapsulate code
Those are my biggest takeaways from the interview. I still think it is great to read through the full transcripts, as there was a lot I couldn't touch on in this blog. Sorry for the big text block and lack of illustrations in this post! Until next time.
For the interview, I asked the following six questions:
- What initially drew you into the field of computer programming?
- How did you get started learning computer programming?
- What are the most important traits and skills for a programmer to have?
- What, in your opinion, is the best way to learn computer programming?
- What software or programs do you use to writing code? What is your typical development process when you have to write a new program?
- Would you recommend computer science as a profession for future college students? What do you think high schools can do to prepare future computer programmers?
I received three responses in total. I have their responses below linked. I will just be referencing excerpts in my analysis below, so I would highly recommend reading through their responses.
Eric Grimson - Professor of Computer Science and Engineering at the Massachusetts Institute of Technology and former Chancellor for MIT. He also taught an Introduction to Computer Science course on edX.org that I took (highly recommended).
David Kosbie - Associate Teaching Professor at Carnegie Mellon University
James Bloxham and Gina Yuan - MIT undergraduate/graduate students and MIT Battlecode competition developer (again, a highly recommended competition. Lots of fun)
With that, here are some of my takeaways and reflections about my programming adventure so far.
Encapsulation and Abstraction
"to be disciplined in following good practices of coding (documentation, respecting abstraction boundaries, modular design)." - Eric Grimson
I had actually spent a great deal of time during my first week of this project focusing on learning these good practices. Documentation refers to the act of commenting in your code to make it easy to understand (using human language to describe what you are doing in code). Abstraction boundaries is what I talked about in an earlier blog post about using abstract classes to create an outline for your code. Modular design refers to separating your code into different classes, or chunks, and making them totally independent so you don't have to worry about implementation.
Professor Grimson's response reinforced that I have been focusing on the right things when building my game. When I started out coding, I did not know about these coding standards. Yet, I looked at other people's code and noticed how they were all set up in separate classes and packages to make their code modular. I decided to imitate this, even though it wasted a lot of time trying to figure out how classes interact. Yet, it seems that these are extremely important skills to learn for future programming projects, so I'm glad I "wasted" the time learning how to encapsulate code
Intrinsic Motivation
One thing that everyone who responded to me agreed on is the importance of self-motivation and hands-on practice."It is important, even in a formal classroom setting, to have lots of hands-on practice in creating, debugging and maintaining code. Being required to write and execute code ensures that you have a detailed understanding of the principles underlying code generation." - Eric Grimson
"I’d say creativity and passion. It seems like the best programmers out there got there by always having a pet project to devote their time to. If you can think up an interesting project that you want to see reach the light of day, it shouldn’t be too difficult to find the determination to make it happen, regardless of however many times you need to embark upon a Google quest to work out why your code still isn’t working." - James Bloxham
This really justifies the thought process behind the Genius Project. If we find a project that we're interested in, we are more willing to devote time to learning. The responses also justify my thought process behind choosing gaming as my window into programming. Rather than just read code out of a textbook, it is much better to find a project to work on and learn new skills during the process of trying to implement the game.
Importance of Analytical Thinking over Coding Expertise
One of my interview questions was "What are the most important traits and skills for a programmer to have?" The unanimous answer was problem solving.
"A love of problem solving, that would be first and foremost. Programming is all about solving problems, large and small. Creativity is essential as well. We don't just need solutions, but creative, clever, strikingly original solutions. Teamwork is also essential. Modern programming is nearly always done in teams, and the best programmers not only work well with others, but work best with others, and make everyone around them better as well." - David Kosbie
"To think analytically and logically; to use abstraction and modularity to suppress details and focus on big picture design principles" - Eric Grimson
This is actually my favorite part of programming. More than the physical writing of code, I enjoy the process of getting a problem and trying to figure out a mathematical solution. In writing my game so far, the parts I most enjoyed where the parts where I had to create my own algorithms. I think this is something that many people don't realize about programming. When people push for programming education, I think they skip over the importance of teaching the computational thinking. Computer science is more than writing physical code. It is a way of thinking.
Coding Software
Interestingly enough, every person that I interviewed used different software to write code.
"I strongly prefer lightweight tools. So I do not use Eclipse, or NetBeans, or any such heavyweight IDE's. Sure, they are super-powerful, but also very complex, and they do magic that separates you from the underlying processes, making them harder to understand. So I prefer a lightweight editor like Sublime. For CS1 students, I prefer lightweight integrated environments, like IDLE or pyzo for Python, or DrJava for Java. I also discourage CS1 students from using tools like github, though of course that is required after CS1." - David Kosbie
"To write the code, I use IntelliJ for Java and Sublime Text for most other things (like Python and JavaScript). When I first started coding, I didn’t use the Terminal very much (cmd on Windows), but once you learn how to navigate it coding gets a lot faster. Everyone has something different that works for them!" - Gina Yuan
"There’s so many different programs out there that you can use for writing programs, and every programmer uses a different subset of them. Generally, I just use Emacs, which is a relatively low-level text editor, for writing code, and I run it from the command line. This is pretty versatile, but I wouldn’t recommend this for beginners, as there are many IDEs (like IntelliJ and Eclipse) that can help you find errors in your code quickly." - James Bloxham
It appears that there is not one specific software that people use. Software choice seems more up to preference than one being better than the other. I used Eclipse to write my code (more on this to come in my vlog!), but I will definitely look into trying the other software!
It seems, however, that the design phase that comes before programming is equally important, if not more.
"When I have to write a new program, I definitely plan out the design on paper first. I think the design is usually the more difficult but fun part for me. Implementation comes more easily after that." - Gina Yuan
I guess the tedious and time-consuming process that I undertook drawing out my program structure in Blog 2 was good! At the time, I felt annoyed that I had to do that step, as I just wanted to jump into the code. Looking back, however, the early planning really made my programming a lot easier, as the modular design made changing implementations much easier!
High School
After reading all of the interview responses, I can't help but be thankful for the programming classes that Wissahickon offers for its students. Here are what my experts said about high school programming education.
"As for what high schools can do, there are many options, in some sense too many, since they are not well organized, and there is definitely no standard as yet. So the first thing is simply for high schools to become more informed of their options ... Schools can also work with their local colleges, many of whom have a rich and growing variety of resources for them, such as summer programs, dual enrollment / college-in-high-school courses, teacher training workshops, and outreach programs of all kinds." - David Kosbie
I think our school does a great job of meeting these beliefs expressed by Professor Kosbie. Despite the lack of national standards, we have an extensive curriculum that covers multiple programming languages, goes beyond code and touches on graphics, and fulfills CollegeBoard's AP standards. In addition, we also have dual enrollment programs just like Professor Kosbie suggested. Thanks Wiss!
"It’s also important to get people to try programming regardless of their experience level (everyone starts from somewhere). After that, there’s so many online resources for high school students to learn from. Also encourage students to do outside programming activities like hackathons and CTFs (there are many high school versions or events that allow high school students out there *cough* Battlecode). Since they’re actually building/doing something with code, programming feels so much more useful." - Gina Yuan
Our computer club also does push us to do competitions and personal projects like the experts suggest. I would never have done Battlecode if it weren't for people at computer club. So, I must say, Wissahickon does a pretty good job of teaching computer programming.
Those are my biggest takeaways from the interview. I still think it is great to read through the full transcripts, as there was a lot I couldn't touch on in this blog. Sorry for the big text block and lack of illustrations in this post! Until next time.
Wednesday, March 15, 2017
Blog 4 - Lecture Time!
Yep, I know. Game first. Press [WSAD] to move, [Left Click] shoots bullets, and pressing [X] spawns a zombie where your cursor is. Number keys switch between weapons. So far, [1] is the Revolver, [2] is the Shotgun. Browser mode is a bit fiddly, so you may need to click around a bit before the player registers movement. (This one seems to work on Chrome, but not on Edge... try a different browser if it doesn't work)
As always, click here to download the desktop version if you want the full experience. My code can be found at my GitHub (star, fork, subscribe, whatever people call it these days)
Alright, now for the progress report. Not as much was added this week as compared to the previous weeks. Basically, I added a framework for easily creating multiple different gun types. So far, I only had the time to make a six-shot revolver and a simple shotgun.
(NOTE: HELP WANTED IN MAKING NEW GUNS! JUST FILL OUT THIS FORM AND I'LL MAKE IT HAPPEN!)
name = "______";
description = "________";
damage = ___;
fireRate = ___; //in seconds
reloadTime = ___; //in seconds
bulletsPerFire = ___;
bulletSpeed = ___; //in pixels per second
bulletSpread = ___; //in degrees
maxAmmo = ___;
So, since the actual progress this week is pretty short, I thought I would take the time to do a little "Programming Lecture Time with Yours Truly" about the important programming tricks I have learned so far (emphasis on topics I used this week)
For example, one could have a Dog class. This class would specify fields such as "Hair Color" or "Species." An Dog object could be Buddy, a specific instance of the class with personal data such as Hair Color = brown and Species = Poodle. This was used in my game because I can have a Bullet class, and every instance of that bullet is its own object.
Now, my dilemma this week was how to make my Weapons for the game. Every Gun has shared methods like getDamage() and getName(), but they also have individual methods like fire() that vary among each Gun. In Java, there are two ways of making generalized classes: Abstract Classes and Interfaces.
I was confused about the two for a long time, but I sort of worked it out in my head with the help of Stack Exchange (think answers.com, but with a good community and actually useful answers).
An abstract class is a template parent class for other "children" classes. It can define some functions that will be passed down to all other children classes, but can leave some to be open for implementation by the children. In an analogy, an abstract class is like being trained as a pilot. All pilots have certain shared characteristics. However, a specific class would be like a F-16 fighter pilot. It contains all the traits of the parent "Pilot" abstract class, yet has individual traits that evolved from the base "pilot traits"
An interface is a broader template. An interface specifies certain methods that a class must have, yet doesn't specify how they accomplish those methods. It is for very general things that can be applied to a large range of classes. For example, "AbilityToEat". A pilot has the AbilityToEat, but so does an infantry soldier, or a spy, or a civilian.
Generally speaking, the order from most abstract to most concrete is as follows:
As always, click here to download the desktop version if you want the full experience. My code can be found at my GitHub (star, fork, subscribe, whatever people call it these days)
Alright, now for the progress report. Not as much was added this week as compared to the previous weeks. Basically, I added a framework for easily creating multiple different gun types. So far, I only had the time to make a six-shot revolver and a simple shotgun.
(NOTE: HELP WANTED IN MAKING NEW GUNS! JUST FILL OUT THIS FORM AND I'LL MAKE IT HAPPEN!)
name = "______";
description = "________";
damage = ___;
fireRate = ___; //in seconds
reloadTime = ___; //in seconds
bulletsPerFire = ___;
bulletSpeed = ___; //in pixels per second
bulletSpread = ___; //in degrees
maxAmmo = ___;
So, since the actual progress this week is pretty short, I thought I would take the time to do a little "Programming Lecture Time with Yours Truly" about the important programming tricks I have learned so far (emphasis on topics I used this week)
Abstract Classes vs. Interfaces
A major paradigm in programming is Object Oriented Programming. In this paradigm, everything is a class or object. A class is a general category that contains various variables (known as fields) and functions (known as methods). An object is a specific instance of a class.
Now, my dilemma this week was how to make my Weapons for the game. Every Gun has shared methods like getDamage() and getName(), but they also have individual methods like fire() that vary among each Gun. In Java, there are two ways of making generalized classes: Abstract Classes and Interfaces.
I was confused about the two for a long time, but I sort of worked it out in my head with the help of Stack Exchange (think answers.com, but with a good community and actually useful answers).
An abstract class is a template parent class for other "children" classes. It can define some functions that will be passed down to all other children classes, but can leave some to be open for implementation by the children. In an analogy, an abstract class is like being trained as a pilot. All pilots have certain shared characteristics. However, a specific class would be like a F-16 fighter pilot. It contains all the traits of the parent "Pilot" abstract class, yet has individual traits that evolved from the base "pilot traits"
An interface is a broader template. An interface specifies certain methods that a class must have, yet doesn't specify how they accomplish those methods. It is for very general things that can be applied to a large range of classes. For example, "AbilityToEat". A pilot has the AbilityToEat, but so does an infantry soldier, or a spy, or a civilian.
Generally speaking, the order from most abstract to most concrete is as follows:
Interface >> Abstract Class >> Class >> Object
Arrays vs. ArrayLists
These are two common topics that come up in programming.
- An array is a structure that stores a FIXED amount of data. Once you create an array, you cannot change its length.
- An ArrayList is a structure that stores a VARIABLE amount of data. You can append things to the end, change things in the middle, remove things as you go. It's basically your jack of all trades. The only downside is that it is slow (slow in computer terms being "oh no, it's 10 nanoseconds longer!!! We're going to die!!)
When making my weapons, I used both arrays and ArrayLists. ArrayLists were really useful when storing bullets. I could add as many bullets as I wanted to the list, whenever I wanted to, and I could remove them at will. When storing user weapons, however, I wanted to use arrays. After all, it wouldn't be right if your character could hold infinite guns...
I thought it would be better to limit players to 10 weapons (yep, totally realistic...)
Gradle
Everyone's favorite elephant!!!
No, but seriously, Gradle rocks.
In case you missed my first blog post, Gradle is known as a "dependency management system." Basically, it downloads all the libraries you need for you and structures your project automatically
When I was trying to make this blog post, an hour of my life got wasted trying to export the game to work on a browser. I kept getting an error that the font wouldn't work on the HTML application, even though it worked on the desktop version. After intense Googling, I found out that this was a bug in the libGDX library I was using. Luckily, it was fixed in the new version that was published. Normally, updating the library would require manually downloading tens of files and replacing folders meticulously. With Gradle, however, I just needed to change ONE LINE OF PROPERTIES and the program automatically downloaded all the dependencies I needed! Woooooooo!
 |
| All I had to do was change 1.9.5 to 1.9.6!!! |
Thank you Gradle!!
Well, that's all I have for today. Please, give me weapon suggestions and anything you want to see in the game. Also, I was thinking of vlog ideas, and I had an idea to do a "My Setup" type video to show all the programs and tools I use to do programming. What do you guys think?
Sunday, March 5, 2017
Blog 3 - Pew Pew
Alright, as always, the game comes before the speech. Press [WSAD] to move, [Left Click] shoots bullets, and pressing [X] spawns a zombie where your cursor is. Browser mode is a bit fiddly, so you may need to click around a bit before the player registers movement.
As always, click here to download the desktop version if you want the full experience. My code can be found at my GitHub (star, fork, subscribe, whatever people call it these days)
If you couldn't tell, the main focus of this week was bullets. I coded in bullets to appear whenever the user clicks a mouse (with a little spread, to make weapons realistic). There were 3 main features bullets had to have: they had to move in a straight line, they had to deal damage to zombies, and they had to disappear when they collided with something. Surprisingly, programming this was a lot easier this week than last week was. This is mainly because I could apply all the basics that I learned last week programming zombies.
As always, click here to download the desktop version if you want the full experience. My code can be found at my GitHub (star, fork, subscribe, whatever people call it these days)
If you couldn't tell, the main focus of this week was bullets. I coded in bullets to appear whenever the user clicks a mouse (with a little spread, to make weapons realistic). There were 3 main features bullets had to have: they had to move in a straight line, they had to deal damage to zombies, and they had to disappear when they collided with something. Surprisingly, programming this was a lot easier this week than last week was. This is mainly because I could apply all the basics that I learned last week programming zombies.
Applying Knowledge! Who knew learning comes in handy!?
Bullet Paths
So last week I talked about how I used vectors to make the zombies follow the player. Well, turns out that is the same method for making bullets move towards the cursor! Zombies had a position, and a destination to walk towards. I could use the same code, but replace the zombie's position with the bullet's position, and the destination with coordinates for where the mouse pressed!
The code to do this is flightPath = new Vector2().set(clickLocation).sub(startPosition).nor();
This makes the cursor vector and subtracts the start position (bullets stem from the player). the command nor() normalizes the vector, which means it sets its length to 1. This allows me to scale the speed of the bullet.
New Stuff!
Drawing Bullets
Drawing the bullets on the screen was mostly the same as drawing zombies, but slightly different. I needed to rotate the bullets in the direction they were being shot, or else it would look like a horizontal line moving on a diagonal. This presented one of the issues that became a recurring theme when working with external libraries like libGDX. I wanted a command that would do: draw(image, xCoordinate, yCoordinate, rotation). Instead, the only draw command in libGDX with rotation as a parameter is
draw(Texture texture, float x, float y, float originX, float originY, float width, float height, float scaleX, float scaleY, float rotation, int srcX, int srcY, int srcWidth, int srcHeight, boolean flipX, boolean flipY).
Ew.
But I had to use it because that was all I've got to work with *sad face*
Hitboxes
Now, the next issue was hitboxes. I had used libGDX's circle class for zombie hitboxes, but that wouldn't work for bullets. Instead, I had to use libGDX's polygon class. That wasn't too bad. I just inputted coordinates for a rectangular polygon and applied the same rotation as I did to the bullet drawing. Collisions, however, were more annoying. You see, libGDX has an Intersector class that deals with polygon collisions. Hurray, I thought. It would take care of everything for me.
Well... nope. You see, I needed a collision for Polygon on Circle. The Intersector class had
test(Polygon, Polygon)
test(Circle, Circle)
test(Circle, Rectangle)
test(Circle, line)
test(Polygon, line)
...
LITERALLY EVERYTHING EXCEPT test(Polygon, Circle)!!!
So, I was forced to search the internet for a custom intersection function. I ended up writing a function that would test every line of my polygon against a circle for intersections. That was fun...
Next week on... Programming for Gamers...
So, next week, I plan on spicing the game up a bit. Now that I have a framework for shooting bullets, I plan on making a variety of guns that do different amounts of damage. If I have time, I also want to make different zombie types so there is variation in the enemies you fight. Finally, and this will probably be in a couple of weeks, but I want to make the game look better than just blue and green circles. I was lucky enough to have someone at computer club (shoutout to CS club, it is a lot of fun and you should join) make some pixel art for me, so hopefully I can add that to the game soon.
Well, that's all for this week folks. See ya later!
Sunday, February 26, 2017
Blog 2 - It's ALIIIIIVE!!!
Alright, first things first. I know you all want to see progress, so here it is!
To move the character (the blue dot), use the WASD keys. To create a zombie (a green dot), click on any part of the black screen. The embedded web version is a little fiddle. Sometimes you need to click on it a few times before it will register your key presses. If it doesn't work for you, or you would rather experience the full desktop experience (because blogger cuts off the screen a bit), click on this link and download the file to play!
You can also check out my code at this link!
Now,onto the progress report...
Starting out, I thought, "wow moving a blue dot and a green dot towards it won't be that hard!" Well, I was mistaken...
Surprisingly, my biggest challenges were BEFORE programming actually began. You see, our IT department doesn't appreciate this thing called "freedom." I wanted to be able to work on my project at school and at home, but our tech department blocks everything, so I could not run my code on our school laptops. I learned that libGDX, the game library I am using, runs off something called Gradle.
Lessons learned by Ryan: GRADLE
Gradle is known as a "dependency-management system." It basically provides an organized way to download libraries that you need in your code off the internet. libGDX is packaged using Gradle, meaning that there is a Gradle file that tells the computer where to download libGDX and how to install it
Since Gradle needs internet access to download libGDX for coding, it is blocked by the school's firewall. I worked around this in two ways. First, I got a big flashdrive to store all my programming files on. I discovered that if I install everything on my flashdrive at my home computer, I could run it and program on my school computer. Second, I used GitHub to sync code between my school computer and my home PC. To do so, I needed to learn command line Git, a version control programming language. Luckily, I found a really helpful website to walk me through the process.
Now that that's out of the way, I could actually start programming, right? Wrong.
Lessons learned by Ryan: ENCAPSULATION
Encapsulation is the idea of separating independent aspects of you code into different files. You only let different files, or classes, interact through a specific set of public functions. This way, you can edit one part of your code (the private data) without ruining the functionality of another separate code because the external code only interacts through the public method
As shown in my brainstorming diagram, I encapsulated my WorldController (which dealt with logic), my WorldRenderer (which drew the pretty pictures), and my Zombies into different classes. This really came in handy when I had to modify my Zombie code. I changed the zombie from storing its coordinates as two integers (x and y) to a point object. Yet, because it was encapsulated, my WorldRenderer still functioned perfectly due to the changes being hidden within the Zombie class.
Finally, programming that simple game above required me to learn new math! Hurray! Everything in a video game lies on a coordinate plan. I had to figure out some way to move a coordinate point in a certain direction by a certain amount. Turns out, the best way to do that is with Vectors! (Anyone in Pre-Calc, this is apparently part of our second semester curriculum. Hopefully this is helpful!)
Lessons learned by Ryan: VECTORS
Vectors are a mathematical device used to describe something moving a certain amount in a certain direction. In mathematical terms, these are a vector's magnitude (length) and direction. This is really useful because you can add and subtract vectors just like normal numbers. The link below helps explain vectors pretty easily.
This was really useful for me because libGDX has a Vector2 class to help do vector math! To make zombies move towards the player, I could just create two vectors representing the player and a zombie, then subtract them to get the path a zombie needs to follow to get to the player!
Well, that's the progress report for this week! Next week, I'm hoping to implement bullets and shooting to finish off my "basic mechanics" goal. To that end, I'm going to need your help! If you have any ideas for weapons I should add into the game (i.e. a slow firing sniper, a fast but inaccurate SMG, etc.), please let me know in the comments below! After making these weapons, I'm also going to need people to playtest for balancing. Hopefully I haven't bored you to death, so check in next time for Blog #3.
To move the character (the blue dot), use the WASD keys. To create a zombie (a green dot), click on any part of the black screen. The embedded web version is a little fiddle. Sometimes you need to click on it a few times before it will register your key presses. If it doesn't work for you, or you would rather experience the full desktop experience (because blogger cuts off the screen a bit), click on this link and download the file to play!
You can also check out my code at this link!
Now,onto the progress report...
Starting out, I thought, "wow moving a blue dot and a green dot towards it won't be that hard!" Well, I was mistaken...
Surprisingly, my biggest challenges were BEFORE programming actually began. You see, our IT department doesn't appreciate this thing called "freedom." I wanted to be able to work on my project at school and at home, but our tech department blocks everything, so I could not run my code on our school laptops. I learned that libGDX, the game library I am using, runs off something called Gradle.
Lessons learned by Ryan: GRADLE
Gradle is known as a "dependency-management system." It basically provides an organized way to download libraries that you need in your code off the internet. libGDX is packaged using Gradle, meaning that there is a Gradle file that tells the computer where to download libGDX and how to install it
Since Gradle needs internet access to download libGDX for coding, it is blocked by the school's firewall. I worked around this in two ways. First, I got a big flashdrive to store all my programming files on. I discovered that if I install everything on my flashdrive at my home computer, I could run it and program on my school computer. Second, I used GitHub to sync code between my school computer and my home PC. To do so, I needed to learn command line Git, a version control programming language. Luckily, I found a really helpful website to walk me through the process.
Now that that's out of the way, I could actually start programming, right? Wrong.
You see, I got this book called Learning libGDX Game Development to help teach me the basics of game development. Turns out, the first step to game development is planning! Whoopdee doo. It is important to make a framework from the beginning so you don't have to waste time fixing things unnecessarily in the future. So, the first day I spent trying to code ended up as a planning day for organizing my project.
The result was the following diagram of classes and functions to organize the code of the game.
Now, finally, coding began. Learning libGDX itself wasn't very bad this week. Most of the commands are pretty simple. For example, to draw in image on a screen, you just write "SpriteBatch.draw(Texture, xCoord, yCoord)." The difficulties were in structuring the code, and thinking of the math behind it. When making the basic game above, I discovered how necessary encapsulation is. 
Lessons learned by Ryan: ENCAPSULATION
Encapsulation is the idea of separating independent aspects of you code into different files. You only let different files, or classes, interact through a specific set of public functions. This way, you can edit one part of your code (the private data) without ruining the functionality of another separate code because the external code only interacts through the public method
As shown in my brainstorming diagram, I encapsulated my WorldController (which dealt with logic), my WorldRenderer (which drew the pretty pictures), and my Zombies into different classes. This really came in handy when I had to modify my Zombie code. I changed the zombie from storing its coordinates as two integers (x and y) to a point object. Yet, because it was encapsulated, my WorldRenderer still functioned perfectly due to the changes being hidden within the Zombie class.
Finally, programming that simple game above required me to learn new math! Hurray! Everything in a video game lies on a coordinate plan. I had to figure out some way to move a coordinate point in a certain direction by a certain amount. Turns out, the best way to do that is with Vectors! (Anyone in Pre-Calc, this is apparently part of our second semester curriculum. Hopefully this is helpful!)
Lessons learned by Ryan: VECTORS
Vectors are a mathematical device used to describe something moving a certain amount in a certain direction. In mathematical terms, these are a vector's magnitude (length) and direction. This is really useful because you can add and subtract vectors just like normal numbers. The link below helps explain vectors pretty easily.
This was really useful for me because libGDX has a Vector2 class to help do vector math! To make zombies move towards the player, I could just create two vectors representing the player and a zombie, then subtract them to get the path a zombie needs to follow to get to the player!
Well, that's the progress report for this week! Next week, I'm hoping to implement bullets and shooting to finish off my "basic mechanics" goal. To that end, I'm going to need your help! If you have any ideas for weapons I should add into the game (i.e. a slow firing sniper, a fast but inaccurate SMG, etc.), please let me know in the comments below! After making these weapons, I'm also going to need people to playtest for balancing. Hopefully I haven't bored you to death, so check in next time for Blog #3.
Tuesday, February 14, 2017
The Beginnings of a Great Adventure
For the six-week long Genius
Project, I have decided to pursuit my passion in programming, specifically
video game programming. There has always been something about programming that
draws me in and intrigues me. If I had to define it, I would say that I have
fallen in love with the analytical nature of coding. Everything you program has
an algorithm. Tasks we normally think are simple, like walking from point A to
point B, can only be implemented through well thought-out, logical commands. I
love the challenge of approaching the problem logically and breaking it down
into simple repeatable steps for a computer to execute.
At this point, you may be
wondering why I chose video game programming as opposed to, let’s say,
artificial intelligence or “useful” programs. Well, it’s partially because I
just enjoy video games. I’ve spent way too much time gaming on my computer, and
I need to put that time to use somehow. But besides, I like the idea of making
a tangible, physical product. It is a great feeling to play a video game and
know that you built that game from the ground up using your own code. I have
never been good at building things with my own hands, but programming video
games is an opportunity to create something on my own that doesn’t suck.
So, to the specifics of the
Genius Project. Over the course of the next six weeks, I want to learn a
Java-based game development library called libGDX. By the end of the six weeks,
I want to create a fully functional video game. Specifically, I want to create
a 2D zombie survival game where the player controls an armed character that has
to fight off waves of zombies. The game must have all the components of a full
game, including a playable character that can shoot and kill zombies, a
shop/progression system to unlock new weapons, and “good” graphics like pixel
art and animation. To track my progress, I will use the following timeline.
By the end of week 2, I wish to have the basic engine completed. This includes
player and zombie movement, bullet movement, and being able to shoot and kill
zombies.
By
the end of week 4, I will have the shop/progression system created. This
includes creating various weapons for the player to use and being able to
switch between windows such as the shop window and the game window.
By
the end of week 6, I want to learn how to implement animation so the movement
of characters and the firing of weapons is dynamic.
These basic guidelines are my
goals for the project. However, part of the game development process is making
an experience fun for the user. To that end, I believe playtesting will reveal
areas of my game that I want to implement or fix that I did not think of to
begin with. So, be prepared for awesome features that weren’t even included in
goals!
To make it easy for everyone to
track my progress, I hope to embed weekly updates of my game to this blog. That
way, you guys can play every iteration of my game and actually see how it
improves. The code itself will also be controlled through my GitHub, so my
entire process will be tracked online. Feel free to check it out, and I’ll post
again next week!
Subscribe to:
Posts (Atom)