Launched the new site this past week after some tweaking and managing a new Hugo template. Wanted to create a splash-like launchpad page that was eye-catching and simple!

Luckily, this refreshed my memory on the whole GitHub procedure. I actually enjoy the process which keeps everything in sync and available on any machine with Internet.

As well, I’ve gotten a bit of Rust programming in while I can, to try and fill in some knowledge gaps and keep up with new environments. It looks like a nice piece of kit, and the syntax is pretty decent, especially since it follows a familiar C-style approach. The really nice thing is the auto-documentation and the Crate system for libraries and packages which will be neat to see and contribute to!

More to come!

This is me, building a Lego set in a few hours… 44MB gif!

Applying the concepts in CMPUT 174, I’ve gotten to an “alpha” version of a popular arcade game. My version, Alien Invasion, is still a work-in-progress but has basic functionality. I suppose it is the minimum-viable-product version of this sort of arcade game.

I definitely enjoyed the process. There are a few features that I’d like to add if I can find some time.

• Explosion graphics when an alien/building is destroyed
• Player-owned buildings (that must survive)
• Aliens that can shoot (they are implemented as flashing objects but the shooting / damage effects are not implemented yet)
• Turret objects that “shoot” laser pulses when a shot registers and track the position of the cursor

I think I might be able to get a few more done before the next term starts and I run out of time.

Here are some lessons learned:

• Code can be re-factored with minor hassles but variable/attributes need to be watched very closely
• Code organization is a mess. The placement does matter in python, because it does a first-to-last interpretation of the code as written, but methods etc. can be rearranged at will within a class, finding a decent organization of those methods is maddening…
• Github is an interesting and useful tool to track changes. I experimented with a main and an alpha branch to track and deal with commits, and when I am satisfied I will do a merge and see what happens there.
• Github is one solution that I’ve decided to use for coding projects; and I use SVN for this webpage, in order to keep up with different (similar) solutions.
• Classes take a bit of thinking and planning during creation. The hardest part is anticipating the needs for a class; what attributes are needed? What kind of methods will handle different aspects of the class? What needs to be in an __init__ function and what can be external?
• Time expenditure total is tough to pin down but I would say an average bug-fix takes maybe an hour or two, a method takes about 3-4 hours, and setting up git, doing a web update, doing some other changes takes another hour. This includes research, checking up on built-ins or other library documentation, creating comments, playtesting and making incremental changes, etc.

In all I would say this has taken about 5 full days of work to get to this point; which is the longest I have worked on a programming specific project so far.

Here’s the MVP version, soon to be released on github!

This is a w.i.p. for a popular game coded in pygame and using some of the things learned in CMPUT 174 at the University.

This is the resultant “mini” project for CMPUT 174 and it was definitely a challenge and fun to attempt!

Today I will finish a few projects for my CMPUT174 class. Many of the projects are requiring much more time in the lab to produce. However, they are still scoped small enough that a one person team can create the finished product. This week is the beginning of a multi-week project called “Pong”, where we replicate the original home Atari version of Pong.

Back to school! Using some of the knowledge gained from the Udemy coursework, I have been working on a number of projects for the CMPUT174 course: Introduction to the Foundations of Computation I.

The challenges have been:

• Learning Python3 (again)
• Trying to maintain C# knowledge and language syntax (luckily, some factors like methods and function calls are identical)
• Staying focused on completing project work on-time
• Keeping up with the Udemy coursework as well
• Dealing with the other classes and coursework

So far so good. Here are some recordings of the output of two mini-projects that I have completed for the class so far.

Creating a grid of cubes in 3D space to display a representation of a parametric plane between three different 3D points.

Learnings:

• For loops that use an incrementing operator (+=, eg.) that also include another incrementing operator (+=) on the same variable will double-dip.

for (int i = 0; i < ValueVar; i += someIncrement){
moveObjectXPos = i;
i += someIncrement; //this guy isn't required because it's already happening in the for loop,
//your move object will double the value of the someIncrement
}

• In my code for this project I’m entering an int value of how many cubes square I would like the planar representation to be; I have to do a division of 1 to normalize the spacing regardless of the positions of the 3 points that are defining the plane. So this can introduce some unwanted behaviour if there are rounding issues with the int value that’s entered. (For example, a 12x12 plane is instantiating 13 cubes because 1/12 is 0.0833 repeating and I think it’s .0011111 shy of fulfilling the For-loop < 1 requirement so it puts one more cube which throws it over the for-loop limit. In other words, I’m not using the limitation of 12; I’m using a translation of .0833 repeating until the for-loop limit is reached.
• Getting more familiar with class generation: in fact, I did learn how to override an operator +/- so that the Coords class that I made can perform addition and subtraction with other Coords objects instead of always breaking down the x,y,z class members and hand-coding that part.

Off to finish the rest of this module!

Just a quick update today; this application was built a few weeks ago, but the summer beckoned and I was outside enjoying nature to the fullest.

The gist of this software:

• Recreate the mathematics for Euclidean coordinate systems from the Holistic3D lectures, from memory
• Create a minimalist UI with the Panel Grid (from the course as well, helpful for setting up quick status windows)
• Re-draw the axis lines from a previous lesson
• Create the vector representation lines for each game object (using a singleton method that can be accessed by any additional gameobjects if needed)
• Make sure all the math works out

Things I learned:

• Have to really revisit the design patterns to ensure that I’m doing the proper structuring of my code;
• Need to familiarize with creating custom classes with overrides, and constructors.
• I did learn how to use the /// summary feature within Visual Studio to annotate functions! Very helpful.
• There was a caveat using the Math library vs. the Mathf library. My assumption is that Math is more accurate, because most of the variables coming out were typed as doubles. So Mathf would be the float values that I am more used to. If I used the Math lib for the inverse cosine for the theta calculation of the angle between two vectors, a result that I expected to be 180 degrees was coming out as NaN and breaking the math.
• Did some practice with finding pre-existing game objects using Unity’s GameObject.Find("") feature, which helped with redrawing the lines that connect the cubes to the origin.
• More practice with creating GameObjects parametrically, and assigning Unity shaders and materials to get them to render properly.

This week I will be completing the course and moving on to preparation for creating my first project!

Wow! Today was the first actual, honest-to-goodness application that had tangible results, and tangible goals, and resulted in a positive outcome!

Goal:

Import a Google calendar into the Thunderbird email/productivity app.

Issues:

-publicly supplied calendars in read-only-mode do not provide an iCal subscription link;

-public iCal calendars cannot be duplicated;

-a large amount of events;

Process:

-determine what possibilities exist (manual entry, picking and choosing information, etc.);

-discovery of Google Apps and the scripting language;

-learning a bit of syntax regarding the GS code and javascript (C# knowledge of the . and other operators was extremely similar);

-doing a quick search on Google to see if any solutions already existed;

-filtering the stackexchange results and other search results;

-reading others’ code entries and deciphering the variables, functions, loop statements and syntax, and formatting;

Decisions:

-proceed with r&d on Google Apps and built-in functionality;

-create preliminary test script with Logging and error reporting;

-test with small test batches;

-ensure no actual data is deleted or removed by accident;

-write and iterate on code until a positive outcome is achieved;

Run:

-Run the code and see what happens;

Revise:

-Touch ups and revisions with some tagging features (i.e., adding the date of script execution to the event description, to enable quick error discovery);

Future:

-look at running the script weekly or bi-weekly via a job or cron-like schedule and entering in a non-static future date based on the current date instead.

The results were effective and most importantly, performed the goal with minimal time expended on implementing the functionality!

Today’s learning is all about vectors.

A new idea is left-handed vs. right-handed rotations: that is, how is the 3d axis oriented in the system. Unity uses a left-handed orientation; so that means: Z axis (“into the screen”) is +; Z axis (“out of the screen”) is -; Y “up” aka. forward is toward the top of the screen+; Y “down” aka reverse is toward the bottom of the screen-; and the X is standard Right +, Left -.

That means that any vector cross products that return a positive Z value (in 2D land right now) are going to be pointing into the screen space, and negatives are the reverse.

So far I haven’t run into many issues, because all the objects on the field are currently at the same Z axis position, so I’m eager to see if that changes if I stagger them in the editor.