Chicken vs. Egg! v0.1: Now with MORE movement!

It’s been several days since my last post, and I’ve been up to quite a bit – I don’t think I can cover it all in this post, but I’ll hit on the main points.

I took a little break from Chicken vs. Egg! to return to a website I first discovered probably a decade back when I was first learning Python – it’s called Python Challenge, and it ate up a lot of my coding time since I last posted. It’s a very basic-looking website with levels you can only clear by implementing a programming solution – for example, one level has a picture which links to another page when you click it. That page contains a picture which links to yet another page, and so on a couple hundred pages deep until you finally reach the solution. Sure, you could spend a decent chunk of time clicking through manually – but the idea here is to learn how to load up the pages via a script and click through automatically so the program does all the work for you. It truly is challenging, and I enjoy it quite a bit. That’s only one example; it gets steadily more challenging as you progress. I highly recommend it if you’re looking to increase your working knowledge of Python when applied to semi-real problems.


I ended up falling asleep early a few nights ago and broke my 100 Days of Code streak, but I got right back to it (here’s a link to day 15). Well, I’ll clarify – I’ve still been working on code every day, but I forgot to log and upload yesterday and didn’t feel like backtracking, so I just decided to write it off as a free day. Today I made some good progress on CvE! – I started refactoring the code into much-needed OOP format, starting with creating a class for the Chicken. I still need to handle the Egg, but now that I’ve got the Chicken class working, I think it’ll be a piece of cake.

Once I merged the branch I’d made for writing the chicken OOP code, I moved on to adding vertical movement for the chicken, which I was able to implement in no time (I’ve added a new GIF for your viewing pleasure). The program is still a baby, but it’s really starting to take shape. I decided to go ahead and call it v0.1 – the first program I’ve ever tagged with a version number! It’s something I want to get in the habit of doing.

In addition to learning how to tag the version on git, I also learned how to reset to a previous commit, how to compare code at various points (rather than the currently staged version vs. the previous commit), I’ve been getting better at branching regularly, I learned how to push a branch to Github (which I didn’t realize hadn’t been happening automatically), and I learned how to correct a prior commit message. I’m pretty amazed at the depth of this tool, and equally amazed that it’s available for free. It’s becoming less scary to me as it becomes less and less of an unknown quantity.

Tonight I finished refactoring my code to make the Egg class and an eggs array, where I should be able to store all of my eggs (once I have multiple flying across the screen at any given point). Next, I plan to work on collision detection, random generation of the eggs, and getting them to fly across the screen (perhaps with rotation). I also want something more than just a black background, but I’ll save that for the polish phase. I’ll check back within a few days to let you guys know how it’s going. In the meantime, you can check out the repo on Github here, if you’d like.

Chicken vs. Egg!: Now with movement!

The latest evolution of Chicken vs Egg! (yes, the exclamation point is part of the title!) sees the game’s protagonist – the humble chicken – gaining the ability to move about in two directions. (You can find CvE on Github here)[].

I’m pretty excited about this development, because it works pretty well. I’ve detailed the latest changes in my 100 Days of Code log for today, which you can read here. Since I’ve got a separate branch aimed at setting it up in OOP mode, I went ahead and removed the unused classes from this branch, which I’d set up with the intent of getting the chicken to change direction according to corresponding arrow key presses). In my last blog post, I talked about a very simple text-based demo I wrote to practice some basic OOP concepts using dogs as my gimmick. My main goal at present is to just get this thing working, but I may find in the near future that I need to go ahead and refactor my code to provide for OOP functionality. For now, I think I’ll proceed procedurally.chicken-movement-demo

If I’m being honest, the main purpose of this post was to show you a GIF of my chicken in action (which I created using a nifty Linux tool I discovered tonight called Peek; couldn’t have been simpler to use). And so here you are: here’s my chicken in action, neatly constrained by the bounds of the window within which it lives.

Upcoming features I hope to implement soon include (but are not limited to):

  • Up/down movement
  • Sprite animation
  • Basic egg movement in a straight horizontal or vertical line from one offscreen side to the other
    • Make those eggs rotate, eventually
  • Collision detection
  • Background
  • Onscreen counter
  • High score functionality
  • Power-ups

As a side note, I wanted to say how much I appreciate you guys checking in to read my posts. I’d honestly be doing this anyway even without an audience, but knowing that I’ve got people out there who are actually interested in what I’m saying is a great motivator to keep doing it. It keeps me accountable. My audience is still relatively small, but it’s been growing steadily. So thanks, my dear reader friends (if you’re reading this right now, I’m talking to YOU)!

I’ll be back soon, probably with more GIF goodness.


Further experimentation in Python and OOP

While there are no notable updates regarding my first game, Chicken vs. Egg, I did write a new Python script today in an effort to hone some of the skills I’ll need to use as I move forward.

It’s called “Dogs,” and it serves no real purpose aside from being a teaching tool for myself. It’s a command line-based demo which works like this:

  1. It prompts you to enter a dog breed and a name
  2. It creates an object instance of the Dog class using the provided parameters and adds it to a list of dogs you’ve created during the program
  3. A menu prompts you to list all created dogs, to create another dog, or quit

You can check it out on Github if you’d like. There’s no real-world application for this program that I can tell, but it was a valuable learning experience that helped me work through a problem I encountered when thinking about the CvE source: how to create an undefined number of objects without explicitly declaring a variable in which to store each one. What I mean is, using the Dogs program as an example, I wanted to find out how to avoid doing something like dog1 = Dog(“collie”, “Sparky”) for each dog I wanted to create.

It turns out that the solution is to create a list and append a new class instance to the list each time it’s created. This will be indispensable as I develop CvE – I have no idea how many different eggs I’ll need to create for any given game, so it would be impossible for me to manually instantiate the various Egg objects. However, if I can populate them into a list as they’re created, I can easily cycle through and update their positions, check for collision, check when they’ve gone offscreen, and remove them once they are no longer needed.

I’ve been missing JavaScript these past few days, but I think it’s best for me to focus on one thing at a time. I’ve made some good progress in JavaScript in the past month or so, and now my goal is to make a game. I do want to continue my journey toward JS mastery, but I think the path of least resistance for my current goal will be Python using Pygame. If I decide to create another game after that, there’s a really cool JavaScript game framework called Phaser which I’m interested in trying out; it would allow me to make a browser-based game using HTML5’s canvas, but I think it would also require a lot more overhead to learn.

Before I wrap up the post, I’d like to add that I’m 10% of the way through my 100 Days of Code challenge (I just posted the log for day 10 here). I’ve still got a long way to go, but I’m encouraged that I’ve made it as far as I have already.

A new theme, and introducing Chicken vs. Egg!

If you’re a returning reader (welcome back!), you may have noticed that I changed the theme on the blog (if you’re interested in specifics, I switched from Libretto to Tonal). If you’re a new reader, that bit of news is totally irrelevant – but welcome, all the same! As I mentioned previously, I was considering migrating to Jekyll, but I do think I’ll stick with until further notice. The interface works well enough for me, and I like the built-in community (it’s brought me a good number of readers thus far, and it’s a good feeling to know I’m not just shouting into the void).

Today, I decided to quit procrastinating, and I got started on my “dodge” game (put simply, you move a chicken around the screen to avoid getting hit by flying eggs). Since I knew there was a popular library in Python called Pygame, I decided to switch my focus from JavaScript to Python and take a break from Codewars problems.

I’m embracing my Shitty First Code philosophy once again with this project, embracing that what I crank out initially is going to inevitably suck. But it’s an iterative process; after I complete my objectives with each version, I’ll add more objectives and continue improving it until it’s something playable (if unoriginal). So far, I’ve accomplished the following:

  • Create a window onscreen with a solid background color
  • Create custom graphics for the chicken and the egg (using Gimp)
  • Display said graphics within the window
Screenshot of a window with a black background featuring a computer-drawn chicken and two eggs

Screenshot of my first game, Chicken vs. Egg!

Since I envision the game starting out slow and easy and ramping up in difficulty as the player’s score increases, I knew I’d need to be able to produce the egg image in multiple different sizes. Rather than producing individual art files for each size of egg, I simply cranked out one abnormally large egg which I scale via pygame’s transform module. I also incorporated this feature into the code via a separate branch in git, which is a habit I haven’t used many times to date (since the complexity of my previous scripts didn’t seem to warrant it). I also figured out how to diff (view the differences between) my previous commit and staged files in Terminal.

In its current state, my game (which I’ve aptly titled Chicken vs. Egg!) is merely a static image displayed onscreen. There’s no animation and no real logic in the game loop. Ultimately, I want the eggs to fly in from all sides of the screen at random angles with a size, velocity, and frequency that increase over time. I also want to add in a background image, I’ll need a score counter, and I’m thinking of a power-up or two to give it some added playability. Eventually, I might add in a start menu and a way to save a list of high scores and adjustable difficulty – so many ideas floating around in my head. It would be great if I could just make a working game, but it would be even better if the game was actually fun. I think I can do it…but one thing at a time.

If you aren’t already, please click the “Subscribe” button in the blog menu! There is also an option to subscribe and receive email notifications when I post (which is no more than a few times a week at most). Thanks for tuning in!

100 Days of Code Progress: Day 5

It’s been a while since I’ve posted here, but I’ve been actively working on code every day all the same. I’ve been pouring most of my thoughts into my 100 Days of Code log in lieu of  posting here (but I’m now seeing that I’ve got a handful of readers, so I wanted to check in and let you know what I’ve been up to).

When I first heard of 100 Days of Code, I thought it was a series of code problems you had to solve 100 days in a row. It’s actually much simpler: you code whatever you want, but you do it for at least an hour each day for 100 days straight. I am in the process of securing a full-time day gig, so I’ll no longer have as much free time as I have had up until now to work on my coding skills, and this sounded like a great way to keep my momentum going.

I forked the official repo on Github and got started about five days ago. Lately, I’ve been going through the coding challenges on using JavaScript to solve them. Each problem is called a “kata,” and I was making pretty steady progress until the kata I started on around the time I started the 100 Days challenge. (As a side note, you can click here to join my team on that site!)

I worked out all the syntax errors and got the program to run, but the output was totally wrong. I struggled to modify the logic to get it working, but kept hitting a brick wall. So I just decided to erase the meat of the function, work through it in plain English via pseudo code, and start again. And it worked! It’s such a great feeling to finally break through after being stuck on a persistent problem. Part of me wishes I picked everything up without getting stuck in the first place, but another part realizes that perhaps getting stuck is a valuable educational experience in its own right.

I am gearing up to create my very first game in Python using the popular Pygame library. The idea of creating video games is what piqued my interest in computer science/programming in the first place, and even though I know what I crank out will inevitably be rudimentary, I’m still excited to get my first little demo up and running. I’ll be sure to keep you posted as it develops. It won’t be anything innovative or revolutionary, but it’ll be mine, and I’ll be proud of it all the same.

I don’t know if I’ve mentioned this previously, but about a month ago I installed Ubuntu on my laptop alongside Windows 10, and I haven’t logged back into Windows since. The overall environment is so much more amenable to programming. I love it. I have to Google how to use certain features a lot more regularly than I did with Windows, but I’m excited to be learning new skills. I actually wrote my latest log for 100 Days using a very stripped-down editor called Vim; it’s anything but intuitive, but from what I’ve read, it’s very powerful. I’m looking forward to getting further acquainted with it, though I’ll probably still be heavily using Atom for the foreseeable future.

As for now, I should probably try to get some sleep. I’ve got to return to my week-long temporary day job tomorrow. Believe me, I’d much rather be coding, but I’m still not to the point of getting paid to do it.

Not yet, at least.


My first script: an update (now with jQuery)

I haven’t posted in a few days, but I’ve still been steadily reading and researching to up my web development knowledge. I took a brief detour from JavaScript to work through some of the Python exercises on Learn Python The Hard Way (which, so far, I highly recommend), I’ve read through most of the jQuery Core documentation, and wrote another basic script to use with Greasemonkey in Firefox (I may write about that separately in a future post).

However, while viewing newbie-friendly open source projects on Up For Grabs, I came across one which mentioned issues in something called Codacy. I had never heard of this, so I signed up for an account and ran it on my Github repo for the prime number script I wrote recently. It gave me a B, mentioning several issues with my usage of console.log statements. In that original project, I created a bare bones web page, but all of my output went to the JavaScript console, which is more intended for development purposes. I did not have any visible output if the console was closed. To get rid of these errors, I decided to rework the code a bit.

I started by adding the index.html file to my repo, then added an empty unordered list which I planned to add list item elements to with the results of each prime number I checked in my script. I attempted to stick with vanilla JavaScript, but after a couple hours of futile attempts, I finally resorted to using jQuery. (If you’re interested, the repo is located here.)

When I converted my newly updated JavaScript code to jQuery, I noticed that my code became much more concise (which I appreciated). Here’s my code as it stands currently (and holy hell, was it hard to get this formatted right in WordPress’s editor):

$( document ).ready(function() {

	//find and store <li> DOM element with ID "output" to list
	var list = $( "#output" );

	function isPrime(number) {
		var remainder;

		//this will store each new <li> element as "item"
		var item;

		//this will store string to be appended to new list item
		var result;

		//prime numbers must be greater than 1
		if (number <= 1) { 			//create new <li> DOM element
			item = $( "<li/>" );
			result = number + " is not greater than 1! False.";
			item.html( result ).appendTo( list );
			return false;
		else {
			for (var i = 2; i < number; i++) { 				remainder = number % i; 				if (!remainder) { 					item = $( "<li/>" );
					result = number + " is not a prime number! False.";
					item.html( result ).appendTo( list );
					return false;
			item = $( "<li/>" );
			result = number + " is a prime number! True.";
			item.html( result ).appendTo( list );
			return true;

	isPrime(0); //should return false
	isPrime(1); //should return false
	isPrime(2); //should return true
	isPrime(17); //should return true
	isPrime(7919); //should return true
	isPrime(23456789); //should return true
	isPrime(10000000000000); //should return false

From the start, this code is different because it’s wrapped in jQuery’s built-in functionality to check that the document has loaded, so I don’t go messing with the DOM before it’s ready for me to. To target the unordered list element on my index page, I find it with jQuery (targeting its ID, “output”) and save it to a variable named list.

The next addition to this script is a variable named “item,” which I’ve designated to store the new list item elements I’ll be adding to the output list. I’ve also created a variable named “result” to which I’ll save the strings describing the results of running the function.

Inside the conditional statement that checks whether the number is less than or equal to 1, I’ve replaced the invisible console.log statement with the new code that creates and appends a visible list item to the page. I did this by creating and saving a new list item element to item with jQuery. I then save a string stating that the inputted number is not greater than 1 and is thus false. Finally, to get this list item element onto the page, I again use jQuery to add the result string within the li tags and, using handy jQuery chaining, append it to the list I targeted earlier in the script. I then return false in case I wish to use the return value for something in the future (though I can’t currently imagine how I’d use it).

I didn’t have an else statement in my original script, since the number would either be return false and exit the function or otherwise continue on to execute the lines of code which followed, but I put an else statement in the revised script. It might be overkill, but I added it for the sake of thoroughness. Inside the for loop which checks for factors (returning false if they’re found, since a factor would signify the number isn’t prime), I used the exact same method described above to create a new list item element, fill it in with a string, and append it to the targeted list before returning false.

Should the for loop finish without returning false, I know that I’ve found a prime number – so I immediately use the same method I devised to add a list element stating that the number being tested is a prime, returning true. For fun, I added a fun new number I knew to be prime (23, 456, 789) to further test my program functionality. It worked!

It took me hours to get this seemingly simple program debugged and running properly, but I feel like I’ve learned a good deal in the process. I’ve been doing my absolute best to commit my changes regularly with git after making a change to the code so that it’s easy to briefly describe what I’ve done. Using git properly is probably one of the most difficult skills I’ve had to learn, but it’s essential…and I’m only scratching the surface yet. I experimented with branching for the first time, though I still don’t quite think I’ve got the hang of it. I find that I’m becoming more and more mindful of the need to commit the more I code. And I incorporated jQuery for the first time! I’m hungry to put it to further use. While I do want to master the basics of JavaScript without relying too heavily on a library, the platform cross-compatibility of jQuery makes it hard not to use. I’m sure it’ll pop up in quite a few of my scripts going forward.

Now I need to go to bed. Thanks for reading!

Photo of a worn house with random colored numbers hand-painted on the side

My first JavaScript program!

Well, that’s not entirely accurate. I’ve written scripts before, but they’ve all been fairly specific in their scope (hiding DOM elements on a particular page for my convenience, for example), and it’s been years. So I’m basically starting over.

In today’s exploration, I came across this list of questions a front-end developer might reasonably be expected to answer in an interview, so I decided to start working through them. The first problem is to develop a function which checks whether an inputted number is prime. All things considered, it’s a pretty basic problem, but it’s been a long time since I even thought about prime numbers, so it took some minor mental gymnastics to get to the solution. Here’s my code:

function isPrime(number) {
	var remainder;
	if (number <= 1) {
		console.log("Number must be greater than 1!");
		return false;
	for (var i = 2; i < number; i++) {
		remainder = number%i;
		//console.log("Dividing " + number + " by " + i)
		if (!remainder) {
			//console.log(i + " is a factor! " + number + " is not prime. Exiting!");
			return false;
		/*else {
			console.log("The remainder of " + number + " divided by " + i + " is " + remainder);
	//console.log("Looks like " + number + " is prime! Congrats!");
	return true;

console.log(isPrime(0)); //should return false
console.log(isPrime(1)); //should return false
console.log(isPrime(17)); //should return true
console.log(isPrime(10000000000000)); //should return false

As you can see, it’s primitive and anything but optimal. I doubt a prospective employer would be impressed by my ingenuity, but it’s a starting point nonetheless.

Before beginning, I had to understand pretty well what a prime number was. I now understand that it is any number, greater than 1 (a stipulation I initially overlooked), which is not divisible by any number other 1 or itself. Before jumping into coding, I wrote out some pseudocode in an attempt to guide my thinking. It went something like this:

  • Accept number as input parameter
  • Loop iterator from 1 through (number-1)
    • If remainder of number divided by iterator is 0, return false
  • Else, return true

To put this into action, I declare function isPrime with a single parameter, number. I then declare a variable, remainder, which I’ll use shortly. The next line checks whether number is less than or equal to 1, logging a warning to the console and returning false if this condition is true. If the number passes this test, I then proceed into a for loop. It is here that I realized I’d made an error in my pseudocode; rather than starting with 1, I needed to start with 2! So I set a for loop to run with iterator, i, from i=2 until i<number, incrementing by 1 at the end of each pass.

At the beginning of each pass, I divide number (the input) by i using the modulo operator, storing the modulus as the remainder (though I learned while typing up this blog post, that modulus and remainder are not the same thing…for the purposes of this example, I’ll go ahead and use them interchangeably). If remainder is zero, that means that we’ve found ourselves a factor which divides evenly into number, so number is not prime – thus the function returns false. If remainder is not zero, the loop continues, checking the remainder with each pass until the condition is met. If, during the execution of the loop, false is not returned, then the number must be prime, thus true is returned.

I called the function against four test cases mentioned in the website – 0, 1, 17, and 10000000000000 – expecting the function to return false, false, true, and false, respectively. And my program passed the test each time! It’s a minor victory, but I’m proud to have solved the problem without cheating or asking for external help (save for some cursory research into the concept of prime numbers to make sure I had a clear understanding).

If I were to improve this program, I would probably remove the console.log statements I put in initially to debug. I would also like to figure out how to write the results to the barebones HTML document I included the script in to run it. As it stands right now, the results are posted only to the JavaScript console in my browser, but not to the page itself. I intend to figure out how to make this happen soon. As for now, it’s onto the next problem.