There have been many times where the material taught from the lectures really changed my mentality and understanding in how to analyze and interpret games. Particularly, I enjoyed learning about video game history and how to understand video games as an art. I also thought that gaining collaborative development experience in Unity was a valuable time investment.
After reading about the MDA framework, various forms of prototyping, play testing, and learning about agile development practices, I’m now more confident in understanding how to design and approach developing a game specifically on how to get a game going initially. I also enjoyed taking a dive in the past to understand our technical progression throughout history. For example, learning about processing and how extreme the RAM constrains to get to the point where we are at today still amazes me.
Lastly, the video game showcasing at the end of the course was actually one of my favorite parts; I got to see demos that showcased how great, well thought out, and creative video games can be created even given a very short period of time. Without a doubt, I was able to read, write, play, and design games throughout this course.
Testbot Trials is a Unity based indie game that I recently had joined in co-developing. In this project I’m working with the Lead Developer: Gregory Mah, the Designer/Lead Artist: Joseph Ferreira, and Artist: Leon Quach. The game is still not complete and if we continue to develop the game, we would like to add different difficulties to the game, easy, medium, hard as well as testing different movement mechanics to optimize the overall naturalness in gameplay. However, we have made significant progress from the last version of the game.
The objective of the game is traverse through many obstacles that are presented in 6 stages so far. Each stage presents players with a unique obstacles that players will have to strategically solve. The mechanics in this game are simple in nature, the movement controls consist of“AD” for left and right movement and “Shift” for a short fast boost.
This game tests the waters in demonstrating how an enjoyable game can be created without major mechanical movement complexities and mission/purpose complexities. The game is a strategy/maze based game that requires users to master the unique scenarios, platforms, and obstacles that are presented on each stage. It also requires that users assimilate to jump timings, avoid unique dangers, and utilize boosting to reach unreachable platforms otherwise. The player will need to use all of these skills to ultimately get to the finish line portals at the end of each stage.
The game uses caliginous aesthetics, intensely setting the stage for users to ‘want’ to escape the maze. The main character’s sprite is that of a futuristic robot who got himself trapped in a maze and has one objective to escape the maze and return back home. Will you be able to clear all six stages and escape the maze?
We had experimented in playing Wizards Unite. This application in its core mechanics had spacial based mechanics similar to Pokèmon Go. The game incorporates players’ geographic location to fight monsters, rescue members of your house, and go on fortress raids. There is also an option to use augmented reality or not. When playing with my peers, this was an important mechanic option because most phones didn’t support the graphics and computational power that the AR version of the game demanded.
In the game, players use their thumbs to cast spells in different patters. You have an energy gage for spell casting. If you error too frequently, you will not be able to cast spells anymore. You can goto inns to refill your energy for spells. You have levels and gain experience from fighting monsters, doing daily mission, and fighting fortresses.
There are crafting mechanics, if you have the proper material you can brew or craft things like elixirs that give you benefits like double experience points for a duration of time. There are 4 Hogwarts houses: (Gryffindor, Hufflepuff, Ravenclaw, and Slytherin). There are fortresses that allow you to have multiple players of the same ‘house’ team up go on raids.
When playing with my peers, we all traveled together but played independently up until the point in which we traveled in physical space to go on a mission to fight a fortress. Since we were all beginners to the game, we all helped each other out in figuring out the mechanics. This lead to a simpler transition into understanding how to play the game.
Playing with peers
Playing with a team was an interesting thing to watch because together, there is required synchrony and a lot of communication. When playing solo, I’d be less motivated to scavenge new territory and explore the streets by myself. The communal aspect demonstrates powerful aesthetics value. There is a sense of competition, because you want to be the highest level and have the best items in your group.
With a group you are also more inclined to utilize group specific components of the game, such as going on group raids to defeat challenging fortresses together. When my group attempted to raid the fortress, we only had 15 seconds for each player to connect to the correct mission and then simultaneously, everyone began to fight monsters independently, but in means to defeat the fortress level together.
I noticed that group members of our house naturally dispersed into groups of around 5 or so. This is probably due to the fact that the particular fortress that we attacked only had 5 people per mission. This also made me believe that the game is not designed for massive groups raiding fortresses, but rather smaller groups playing together.
In this project I took the role of being a programmer for this ‘alpha’ release for a 2D Unity game unofficially called, “Anhedral”. I worked my partner Leon, who was the designer.
This was our second iteration of play-testing, this time around there was significant improvement and development particularly with respect to the game’s moving mechanics, player, solid objects, and enemy artwork, and overall stage development where players fight two fleets of enemy airplanes.
Users use WASD controls to move and spacebar to shoot. The base objective is to take out enemies, collect coins, and clear the stage by getting to the other-side of the map.
With improved controls players were having a much easier time focusing on the intended present challenges from the game, instead of being confused from uncomfortable controls. Before players would move with ASD, J to attack and K to ‘jump’ or ‘fly’.
There is now a better sense of linear objectives in that the players are motivated to get to the end of the stage. I often saw that players would die regularly due to the challenging micro-tasking that the game demands. However, beating the level was very achievable and every player was determined to get to the finish line. Every time a player lost, I could see them getting better and better over time.
Future Plans:
I can really foresee potential with this game given the overall player feedback given one stage. I realize that the spectrum in player skill is highly variable and in order to challenge everyone, I wanted to make the next stages have enemies that shoot linear or homing shots at your plane in order to increase the micro movement intensity even more.
In this project I took the role of being a programmer for this ‘alpha’ release for a 2D Unity game unofficially called, “Anhedral”. This was my first time every developing with unity- in fact it was the first computer game that I’ve ever developed. I worked my partner Leon, who was the designer.
He had made the plane sprites, background images etc. and I had implemented them, manipulated c# code to convert a 2D platformer based ground game with the help of David Montes’ template into a into a flying game where the majority of the attributes have changed. In this process, I specifically did things like creating 2D Box Colliders, adjusting physics, and manipulating player and enemy class’ code.
Today in class we had multiple playtest sessions. This was a unique, bonding, fun, and constructive experience. The game was surprisingly well received and I had just as much fun as the playtesters while they were in the stead flow of the game.
After multiple testers, I quickly identified trends and facets that had room for improvements. In particular, one player had suggested that we may want to change the mechanical controls from ‘j’ to jump, to spacebar to spacebar to jump. However, more importantly we had internal dialogue and he had stated that, ideally he really wanted to be able to explicitly control movement with his left hand using “WASD” controls and he’d like to shoot/attack with spacebar. Similarly, another other playtester had suggested that we should change ‘k’ from jump to spacebar to jump.
I then considered both pieces of advice and decided that a potential optimal solution could be to change ‘w’ to move the plane upward and spacebar to shoot. I had noticed that ‘w’ was an unused key that was conveniently located, whereas “k‘’ is a distant key. I then changed ‘k’ to ‘w’ and spacebar to shoot.
I then tried out the game, and it immediately felt immeasurably more fluid. There was a significant improvement in the playability of the game. I was more focused on playing the game well then messing with janky controls.
Lastly I there was a common identified issue with the acceleration being too strong. This should be an easier fix, however, the more important takeaway is that I now realize that small core mechanical features can potentially make the most significant impact on player satisfaction.
The only mechanic that
players are in control of is that of jumping. You can tell that the game
designers emphasized aesthetics to make simple mechanics repayable, dramatic
and fun. In the background you face multiple real-life building obstacles and
the sound effects are powerful. Also, as you jump from building to building,
your whole screen frequently shakes to make the player nervous and
engaged.
I played a game a
student in a previous section of this course made called Manbat:
I was the therapist for
lord Dracula and his demons. Aesthetics play a big role here. The fun is
developed in the dialogue and story. You are the therapist and it’s comical
that all of the demons are depressed, and you get to choose multiple different
routes on how you want to solve the demon’s problems. There are jumping
mechanics where you stick to the nearest roof and you can move left to right.
Analysis Between Canabalt
and Manbat:
Upon analysis of two seemingly
unrelated video games, Canabalt and Manbat, from a designer’s
perspective, I’ve begun to realize that they are very similar in many respects.
Canabalt predominantly
focused on how to optimize players’ satisfaction while only allowing them to
have ‘one’ mechanical feature, which is to jump. Manbat similarly only really
allowed for left right and jumping movements. There were interesting mechanics
such as sticking to walls and inverting directions, however, mechanics where not
what made the game unique and valuable. Both of these game shine due to the
fact that they purposefully designed simple mechanics so that the players can
focus on a plethora of different aesthetic forms. For Canabalt, they wanted players to feel thrill
and engagement through graphics, sound, and intense motion. In Manbat, players
are motivated by dialogue and entering the magic box of the game. It’s unique
because players aren’t focused on the mechanics such as an FPS game, they are
focused on the aesthetics.
I played This is the only level –
Adventures in singularity:
This game has very simple
aesthetics, with dynamically varying mechanics such that the mechanics were so
perplexing that when playing in the moment of each stage the player doesn’t
really care about what the background looks like.. Each level gives you a hint
in what the mechanical change is. For example, in on stage: Altitude
determined how high you jumped. If you jumped on a block with high altitude,
then you jumped low and slow if you jumped on a block with low altitude then
you jump high and fast. The aesthetics were very minimal, yet so very
impactful. They would combine the implementation of color schemes associating
to mechanic changes in rules. For example, there is a stripped stage where
parts of the map turn blue and the other parts are green. If the character
stepped on a platform that was colored blue, then the character would restart
to the beginning position. This game is an interesting one to analyze because
it showcases that games have the ability to be successful while only really
prioritizing one design core decision (mechanic, aesthetic, etc.)- in this case
mechanics.
I observed my in-class
partner Ashley playing: This is the only level – Adventures in
singularity
As I was watching her
play, I saw the game from a different lens. While she took control of the
actual mechanics. I could see how the complexity of mechanics can directly
affect a player’s mood, emotion, interest, and excitement. In this game, during
each stage, the functional mechanics are changed. I noticed that at each stage
it takes a moment in time for the player to learn each stage’s respective
mechanics. If the mechanics were slightly too complex the player may
potentially even believe that there are breakpoints when in reality, it’s a
mechanical design. I could also see how if a stage is difficult, frustration or
focus can develop. Similarly, I could see the thrill of victory in passing a challenging
stage. This inherently reminds me of the designer’s concept of “flow”- making
sure to challenge a play but allowing them to stop and reflect on their
victories as well.
A classmate and I had created a board game, in which I will call, “Expansion”. The board game uses area of control / area influence mechanics. This is a 2 player game, in which the player who either conquers all of the land at one moment, or controls the majority of areas at the end of turn 16 wins the game.
General Rules:
Each player doesn’t know the other players move. Both grids must be separated by a physical object. At the end of each turn, each player strategically will either expand to new areas, increase their economy, defend area, and/or attack their opponents controlled area.
Income System:
Each player gains 3 tokens at the start of their turn. A player doesn’t have to make a move to take over or attack new land. If a player has over 5 points he/she will gain an extra 1 token, if a player has over 10 points he/she will gain an extra 2 tokens, if the player has 15 tokens he/she will gain an extra 3 tokens at the start of the turn… continued until a player has 25+ tokens, in which a player’s additional income will cap at a 5 token gain not including the original 3 tokens that are gained every turn.
The main purpose of this board game is to create optimal strategies that utilizes macroing (building an economy) and expanding/conquering new territory. If a player is too aggressive and doesn’t win a rush he/she will lose do being short tokens. If a player is too passive, he/she may be trapped or outright eliminated by losing all of his/her controlled areas.
Expansion System:
Each player can either spend 2 tokens to conquer a new area, 2 tokens to defend an owned area, or 4 tokens to attack and potentially take over over their opponents controlled territory.
If one player attacks their opponents controlled area, and the opponent defends that area, the attacker loses 4 tokens and the defender only loses 2 tokens.
If both players decide to attempt to take control of the same area on the same turn then both players will spend 2 tokens but no one will take the land.
A player can attempt to take over any land that is vertical or horizontal to any piece/area in which they already own.
Session Report One:
Turn 1: Both players are dealt 5 tokens to start. Each area conquered costed 2. Kevin conquered 2 areas near top right corner and Calvin did the same. Now both players have 1 currency
Turn 2: Calvin and Kevin gain 3 tokens. Kevin moved 2 squares diagonally towards Calvin’s starting point. Kevin now has 0 tokens. Calvin only made one diagonal.
Turn 3: Calvin has 5 tokens and Kevin has 3 tokens at the start of turn 3. Kevin moves downward on block to avoid attacking because attacking areas cost 4 tokens. Calvin conquered the area at the top left of the board.
Turn 4: Calvin now has 6 tokens and Kevin has 4 tokens. Kevin decided to attack the origin point which cost him 4 points. Calvin didn’t defend the origin so Kevin took his starting area over. Calvin decided to expand on a new area.
Turn 5: Calvin has 7 tokens. Kevin has 3 tokens. Kevin spent to 2 tokens to take over the bottom right area of the board. Calvin took over two undefended areas.
Turn 6: Calvin has 6 tokens and Kevin has 4 tokens at the start of the turn.
Kevin decided to attack one of the areas on the bottom of the board. Calvin took over the last area available. Calvin attack the left bottom corner and took over the starting area.
Turn 7: Calvin has 3 tokens 3 tokens. Both players don’t have enough tokens so they have to idle for a turn.
Take Away/Rule Change:
What we realized this play is that we should give 1 token for profeting every turn that a player has 5 or more tokens. The income system is insignificant because it takes 3 turns just to gain 2 extra income which is far too slow. Game play takes around 20-30 minutes.
Session report 2 (3×3 grid trial / income change):
Turn 1:
Player 1 holds position and does not take over new area
Player 2 moves diagonally from root position
Turn 2:
Player 1 and player 2 both receive 3 tokens, player 2 gains extra coin for having over 10 tokens at the start of the turn. Player 1 has 14 tokens and player 2 has 11 tokens at the start of the turn so both players have 9 tokens.
Player 1 decides to just expand to the left and right areas next to the root
Player 2 decides to attack the root position and take control of the left and right areas next to player 1’s starting position.
Because player 1 did not defend root position and both left and right areas were contested by player 2, player 1 loses the game.
Player 2 wins.
TakeAway:
Reducing the board game from 4×4 to 3×3 is far too great of a fundamental change because it’s nearly pointless to have an income system if you will lose in less than 3 turns due to the rapid expansion nature to the opponents starting location.
Session report 3 (Income Change also total area wins at the end of turn 16):
Turn 1:
Player 1 holds position and does not take over new area
Player 2 holds position and does not take over new area
Turn 2: Player 1 and player 2 both receive 3 tokens and gain 1 extra coin for having over 5 tokens at the start of the turn, so both players have 9 tokens.
Player 1 decides to hold position and not takeover new area.
Player 2 decides to expand 1 area diagonal.
Turn 3:
Player 1 has 13 tokens and Player 2 has 11 tokens at the start of the turn.
Player 1 holds position and not takeover new area.
Player 2
Turn 4:
Player 1 has 18 tokens and Player 2 has 15 tokens at the start of the turn
Player 2 takes over diagonal location towards player 1’s starting position. Player 2 is now 1 move away from player 1’s only piece.
Turn 5:
Player 1 has 24 tokens and Player 2 has 18 tokens at the start of the turn.
Player 1 moves to the left and right areas next to his starting point.
Player 2 moves to the left of player ones starting point
The left area is contested so both players spent 2 tokens
Turn 6:
Player 1 has 27 tokens and Player 2 has 21 tokens at the start of the turn.
Player 1 expanded left and right and defended 1 spot.
Player 2 took over 1 area and 1 area was contested.
Turn 7:
Player 1 has 28 tokens and Player 2 has 23 tokens at the start of the turn.
Player 1 attempts to take over 3 areas, player 2 takes over 4 areas
3 areas were contested, player 2 takes an extra area.
Turn 8:
Player 1 has 28 tokens and Player 2 has 23 tokens at the start of the turn.
Player 1 attempts to take over 3 untaken areas and attacks 1 of player 2’s areas. (spent 10)
Player 2 attempts to take over 5 areas (spent 10).
2 areas were cancelled out
Turn 9:
Player 1 has 28 tokens and Player 2 has 23 tokens at the start of the turn.
Player 1 attempts to take over 5 areas wherein 2 of the areas were attacks. (spent 14)
Player 2 attempts to take over 4 new areas (spent 8)
Turn 10:
Player 1 has 16 tokens and Player 2 has 12 tokens at the start of the turn.
Player 1 attempts to take over 3 areas all of which are uncontrolled (spent 6)
Player 2 attempts to take over 3 areas all of which are uncontrolled (spent 6)
They made the same move so all attempts were cancelled.
Turn 11:
Player 1 has 15 tokens and Player 2 has 10 tokens at the start of the turn.
Player 1 attempts to take over 3 areas all of which are uncontrolled (spent 6)
Player 2 attempts to take over 3 areas all of which are uncontrolled (spent 6)
They made the same move so all attempts were cancelled.
Turn 11:
Player 1 has 13 tokens and Player 2 has 15 tokens at the start of the turn.
Both players did not attempt to take over new areas.
Turn 12:
Player 1 has 18 tokens and Player 2 has 21 tokens at the start of the turn.
Player 1 holds
Player 2 attacks one area (spent 4)
Turn 13:
Player 1 has 24 tokens and Player 2 has 23 tokens at the start of the turn.
Both players hold
Turn 14:
Player 1 has 31 tokens and Player 2 has 30 tokens at the start of the turn.
Player 1 attacks 1 area and defends 1 area (spent 6)
Player 2 attacks 1 area (spent 4)
Turn 15:
Player 1 has 31 tokens and Player 2 has 30 tokens at the start of the turn.
Player 1 attacks 2 of player 2’s areas (spent 8)
Player 2 attacks one of player 1’s areas and defended 1 area
Turn 16:
Player 1 has 31 tokens and Player 2 has 32 tokens at the start of the turn.
Player 1 defends 4 areas (cost 8)
Player 2 attacks and wins due to most controlled areas
Takeaway: Future Iteration Rule Changes:
In this iteration we realized that the game took a bit too long. Also, it’s exceptionally hard to successfully defend when allowing the opponent to take over land diagonally. So, by limiting the number of rounds, creating win condition for the player with the most area to win, and allowing players to only take land to the left of right of areas they own, I can anticipate a more fluid and fast paced game.
Rule breakdown:
Maximum profit is 5 (25 tokens) (for every 5 tokens you gain 1 extra tokens)
Maximum tokens = 40
Only able to expand to areas that are next to areas that are already taken at the beginning of the turn.
Can’t move diagonally (possible rule)
Limit the number of rounds (15 or 20 rounds)
The player with the most areas win (if it’s the last turn)
Throughout each iteration and trial, I’ve been able to make significant game changes to make the game as strategic as possible. This game is very intense and competitive because you need to focus on “macroing” enough economy such that you will be able to defeat your opponents without becoming too vulnerable and losing the game early on. It’s a game of balance and strategy.
It was game day, a stroller carrying about 30 board games were pushed into our classroom and all of the students from my game design class had spread into different teams to explore the mechanics of a plethora of board game types.
I was grouped with 6 very intelligent and a few… deceitful (as I had discovered through this game) students. We had 6 total players, wherein 4 random players would be a part of the Resistance and 2 random players would be spies against the Resistance.
My group members had unanimously assigned me to have the role as the ‘leader’ of the game. This implied that I had to deal the Plot Cards which are essentially special cards that grant privileges such as taking over the role of leader etc. and as a leader I had to make decisions on which players I wanted to bring with me on missions. This is an important role because If you go on a mission and a spy comes along, he/she can either pass or reject the mission. If a rejection occurs, we fail a mission, and if we failed three missions, we would lose the game.
As the game played out you begin to use deductive logic to try to determine who the spies are so that you can avoid bringing them with you on the mission. One of the most intriguing and distorting concepts that the game offers is that verbal communication is open for anyone to say anything. In the back of your mind you are constantly questioning the validity of any statement they make because you don’t want to be deceived in thinking that they are part of the resistance when they actually are a spy vice versa. When the games started I was dealt the character card whom of which was part of the resistance so my goal was to win three missions.
Session Report:
First Round: Dev got the Plot Card which made him publicly vote for the rest of the game. Sena and Katrina were chosen to be a mission members. Result Successful.
Second Round: Sena got the plot card which makes him steal plot card from Dev so now Sena has to vote publicly for the rest of the game. Julie, Calvin and Dev were chosen for the mission and mission failed with one fail and two success.
Third Round: Katrina got the plot card. Dev, Katrina, Julie, and Calvin were chosen to go on the mission. Voting was successful. The mission failed with one fail.
Fourth Round: Plot Card: ‘Open Up’, Julie got the plot card so she had to reveal her identity to Katrina and Katrina said Julie is Resistant. Katrina, Julie, and Sena were chosen for the mission and it was successful.
Fifth Round: Plot Card went to Dev. Katrina used her plot card to be the leader. Katrina chose herself, Julie, and Calvin. Vote was successful and the mission failed.
Spys won
Session Ended.
During the last round, we had 2 failed missions and 2 successful missions. My gut feeling had told me that Dev and Calvin were the spies because they would simultaneously attempt to dissuade anti-logic into my head. However, I initially had trusted my gut and had said that I was going to take everyone on the mission except for Dev and Calvin, however, Julie had played the plot card to take over my role to make the final decision.
There was much to learn from this very close game. First off, if a player is overly invested in telling you why sound logic is illogical, this may be a questionable act. Lastly, many of the times you will realize that your gut feeling is more accurate than one can attempt to reasonably logically deduce.
After re-visiting many of my childhood favorite Sega and Atari games, such as Paper Boy, Champion Boxing, and Indiana Jones and the Temple of Doom, I’ve experienced a new level of appreciation for the subtle complexities that these games offer for their time of creation.
In Particular, I’ll be discussing my experience with the Indiana Jones game. Unlike the 2 dimensional simplicity from Paper Boy and Champion box which where release in 1984, Indiana Jones was released in 1985, just 1 year after and seems to have been influential in introducing quest based 3 dimensional functionality.
This game is not only complex in function, being able to climb ladders, whip monsters, rescue prisoners, aim for a high score on the leaderboards, but it even has an interactive multi-leveled difficulty selections for stages (easy, medium, and hard).
In terms of playability with respect to playing on an emulator vs playing the game on the original hardware, I’ve realized that although the games are ‘playable’ there is a sense of disconnect with the full experience that I remember. First off, simultaneous multiplayer mode is essential unplayable if using 1 keyboard, this forces users to hand of the computer to different players during each instance. Also moving with arrows is significantly less involved than moving with a joystick. Thus, in order to fully revisit this game, I’d like to revisit the actual arcade box version.
Furthermore on analysis, it’s worth noting that even with the computational constraints that developers had dealt with, they managed to have very intriguing graphics, such as inmotion bright pulsating lava and on hit/contact reaction graphics.
Fair enough to say, although graphics and game complexity has incomparably and increase over time, Indiana Jones (1985) is clearly a memorable game that should be re-visited, analyzed, and appreciated as time continues.
By Kevin Benelli- Software Developer at Land O’ Lakes and Computer Science Junior at University of California, Davis
Teaching Computer Science in Primary School is important.
In the USA is that there are far higher paying Software based jobs available than there are qualified candidates in these related professions. This is in part due to the lack of computer science exposure in earlier education. It’s important to recognize that computer science concepts are not only limited to Software Development jobs. Significant portions of STEM-based professions are fundamentally driven by programming, this includes but is not limited to, Data Analysis, Data Science, Genetics, Agriculture, Statistics, Mathematics, Researchers, and Engineering fields. This can even be beneficial for Writers or entrepreneurs that are attempting to gain a web presence. If we want to allow our children to pursue their contemporary dreams, we must provide them with the tools to do so, by implementing computer science into primary school’s education. I will be talking about how to approach implementing Computer Science fundamentals in primary schools and what we should know when doing so.
Computer Science is a Multi-Disciplinary subject.
There is more to implementing a quality computer science curriculum than just having children code. It’s essential to place ourselves into the shoes of developing children, and ask what would be a productive, fun, and motivating way of learning code. Instructional software games that teach programming skills have the capacity to accomplish this task- we just need to provide children with the right games.
Computer Science is a multi-disciplinary functional medium that can be molded around any discipline. A Computer Science researcher and an English teacher with coding experience created educational software that allows children ages 5-11 to input code into a textbox- which is then translated into an actual animated story. Children are able to develop their literary knowledge through a coding medium.
This sheds light on the fact that computer science is not limited to STEM subjects and in fact, it can be integrated with the curriculum of multidisciplinary settings. This shows that even in subjects such as English, or teaching about stories, education systems can use programming to dually teach core literacy skills, such as storytelling, and computer science skills at the same time. Not only is this more interactive than reading, but this also allows young students to gain experience in engineering creative solutions to create their own stories. Many parallels may be made in the soon future. With the invention of the Educational computer science software, there is no doubt that teaching Computer Science can extend to history, physical and life sciences, or even a music class. Furthermore, in the research, through the simple game, researchers concluded that, at a very early age, children are capable of learning some of the most complicated programming languages such as Java.
Fun Educational Software Leads to More Creative Engineers
We also should understand that high-quality fun interactive programming games lead to more leaning success. A group of researchers analyzed how children in the age range of six and seven performed more program manipulations with games that were more functionally appealing, fun, and easy to play. The children were more thorough and meticulous with their programming approaches. Importantly, they also found that people who scored higher with reasoning and logic skill performed better when programming using educational software interfaces that were more user friendly to play.
In order to successfully implement interactive Computer Science educational software into a classroom environment, understanding how children respond to variations of software programs is important. It becomes clear that subtleties in the graphics, colors, and functionally contribute to how children will utilize the programs. In simple terms, if the program is black, grey, and boring, a student will be more inclined to reach the finish line but will not exemplify creative steps and workarounds for their own unique solution.
Gamification: Children don’t fantasize about Ones and Zeros
Above almost anything, if children are not having fun, it can be hard for children to become interested in learning about technical topics. A group of researchers explored solutions to counter the lack of motivations that occurs with higher education students when they are taught software engineering concepts. They introduce Threefold Gamification concepts in their lectures wherein they break teaching down into presenting a challenge, the gaming level, and the experimental learning stage, where they essentially are participating in a hands-on hackathon where they execute their early preparation and planning stages.
From childhood to adulthood we naturally choose to do things that we are intrinsically motivated in doing. I’m a strong believer that every subject has the potential to be amazing, however, it comes down to how well teachers can convey its admirable qualities. We need to gamify teaching Computer Science in primary schools to increase young student’s intrinsic motivation levels. We should break the teaching down into the “Threefold” structure. Similar to project-based teaching methods, or makers fairs and workshops that are well known in contemporary education, we should break the teaching of computer science into a practical connected project that involves the conceptualization of the issue, the theoretical planning, and the hands-on execution of group programming.
Improving Self-Efficacy and Gender Disparities
If you are opposed to teaching children programming at an early age, it is natural- computer science is a very new subject matter and we are all learning how to best implement this. However, it is important to recognize that there is a breath-taking disparity in gender among Software Developers in particular- much of which has a researched supported correlation to lack of early childhood exposure to computer programming. According to StackOverFlow’s annual 2018 report, out of 64,363 Software Developer respondents that participated in their annual survey, there was a 93% male to 7% female gender disparity in that of gender-based on Software Developers in the workforce. We need to emphasize the importance of exposing females children to computer science as early as possible to do everything in our power to attempt and bridge this distant gap. Much of this disparity may particularly be related to the lack of self-efficacy and confidence from people’s childhoods towards algorithmic thinking and debugging skill sets- which are very hard skills to attain, unless developed through early childhood exposure to such forms of thinking.
When teaching Computer Science in our classrooms, we should always keep a baseline statistic to gauge the learning retention our the student’s in our classrooms. Fortunately, a group of researchers have created a test/gauge to determine 5 core skill sets that best resonate with the ability to learn Computer Science. These 5 traits are Logical Thinking, Algorithm, Debug, Control, and Cooperation. There were identified differences in gender in the performance of the generally more complexly technical features of Algorithmic thinking and debugging. In this area of the experiment, they found that a group of males had performed at higher assessment levels than a group of females in the research project. However, the researchers also found that the increases in programming experience enhance adolescents’ abilities in their confidence with computational thinking in all of the 5 core skills, particularly Algorithmic thinking and debugging which had the lowest performing skills in the female groups. Thus, it is essential to provide early exposure to programming with a ‘can do’ attitude particularly to young girls learning Computer Science.
Letting go of Hindered Creativity
There is no perfect handbook to optimal methods of teaching computer sincere in primary schools. However, we now can attempt to form a common ground in understanding that children are fully equipped to learning complex programming languages through a plethora of mediums. Some of these mediums are through the use of user-friendly and fun software programming games. Furthermore, we now can see how computer science and programming can be used as a medium for multi-disciplinary teachings. In order to sustain student motivation, we should gamify the teachings of Computer Science and maintain the hands-on threefold structure of project-based teaching. Lastly, it is essential to recognize the unfortunate large disparity in gender, in the workforce of software development. The way in which we work towards equality is by tackling the core of the issue. We must increase young students’ self-efficacy at an early age by providing them with early computer programming exposure.
Every human is intrinsically born curious, innovative, and creative; we are designed to adapt, and the only thing holding the potential of our future technologists back, is the lack of standardized teaching of Computer Science in early education today. Teachers are the root of change for our future!
Technology-Education 