jjvgaming

[jjvgaming]

Pinout for Tomee SNES Extension Cable

This is the pinout for the Tomee SNES extension cable, which can be useful if you are wiring a cable for a Toodles MC Cthulhu or Akishop Customs PS360+.

The numbers refer to the pin position on the male end of the controller cable, starting with the round end at the top, and the colors refer to the colors of the wires: 

Black

N/A

N/A

Red

White

Yellow

Green

These findings are based off of testing two Tomee SNES 6′ extension cables. But, they may not be the same for other SNES extension cables from the same brand, or other SNES controllers or extension cables. 

[jjvgaming]

Creating Animations, and Starting a Beat ‘em Up

In the past month, I became really excited about Fire Emblem due to the release of Fire Emblem Heroes. I was also playing Odin Sphere Leifthrasir, and Fire Emblem Emblem Warriors was announced for the Switch, so I thought it would be fun to plan and develop a beat ‘em up style game for Fire Emblem on the PICO-8.

Since I needed to do a lot more animating than I previously did with my shmup projects, I spent some time working on my animation skills. All of the resources I reviewed encouraged creating good silhouettes and emphasizing your actions around your key frames. As a result of this, I started with creating a walking animation of Kamen Rider that I’m pretty proud of: https://twitter.com/hwajay/status/828406840987787264

Designing and creating a beat ‘em up required a different paradigm than creating a shmup. After a couple of weeks of planning and getting used to the paradigm, here’s what I got:

If Zelda: Breath of the Wild and Nier: Automata don’t take up the rest of my life this month, hopefully I’ll have a simple prototype by next month!

[jjvgaming]

Small Update to PICO-8 Shooter Project

In my last post, I created a small shmup game. One of the goals was to include scrolling backgrounds. After reviewing one of the demo games, I added some really simple scrolling background elements (see Twitter post). 

Another goal was to add music, but I will save that for my next project. Since this was just a project to test the functionality of the PICO-8, I did not want to spend as much time on music as I did in my previous Game Maker project. However, I studied music implementation in the demo projects and found that it would be better to wait on implementing music anyway. The PICO-8 has a limited amount of space for sound effects, and the slots for sound effects can also be used to create measures of music. In my next project, I will plan around this so I don’t have sets of sound effects mixed with music. 

Here’s an updated PICO-8 cartridge with the work done. I would suggest playing the previous version since it’s easier see what’s going on. But, if you are interested in what I did, you can go ahead and check it out below: 

Download link

[jjvgaming]

Developing within Limitations! Starting with the PICO-8

During my previous Unity and Game Maker projects, I felt like I could do anything as long as my computer could handle it. While this freedom could be comforting to some people, I didn’t know what to do with the seemingly limitless freedom that I had. I could have imposed restrictions on myself, but that would have felt artificial, and I don’t know enough about emulating hardware to know where to start. Coincidentally, after my last blog post, a Humble Bundle was released with the PICO-8. The PICO-8 is a “fantasy console” with very strict hardware limitations compared to current hardware, which is exactly what I was looking for.

The Fun of Limitations

I have always been fascinated with designing and problem solving within limitations. In elementary school, I could not afford a lot of Beyblades, so I used Legos to build tops that fit to the launcher. When Pokemon cards were banned in elementary and middle school, I developed a board game to play with my friends instead. Even now, when I play fighting games, I naturally gravitate towards characters with limited tool sets. These experiences forced me to use limited materials and be creative to continue doing what I liked, which led to some interesting results, and the process was always fun.

I did not appreciate this kind of thinking in video game development until I read this blog post about developing around the memory limitations of Gameboy Advance cartridges for the Ace Attorney games. This is quote from the article, which summarizes it nicely:

Honestly speaking, the thought “I wish we had that infinite amount of memory”... has actually never really crossed my mind. That’s because I believe that there is a certain kind of “fun” that can only be experienced in the face of extreme constraints. As for what that kind of “fun” is... it’s the chance to sharpen the team’s ability to find solid workarounds.

About the PICO-8

The PICO-8 is a fantasy console with strict limitations to emulate the look and feel of a retro handheld console. To give you an idea of how small the games are, and to emphasize the idea of retro handheld consoles, here’s the entirety of the current state of my project below. The games are distributed as .PNG images in the shape of cartridges, which is pretty cute.

The PICO-8 program boots up in a command line interface with a 128x128 resolution. It contains a text editor, sprite editor, map editor, and sound effects/music editor all in one package. Navigating the command line or performing actions involves typing in simple commands or using hotkeys. Everything else can be manipulated with the mouse. Programs are written in Lua, although it uses a custom Lua library or a subset of the Lua language.

Since the PICO-8 is in an early stage, there is not a lot of documentation for it. However, there are several demo games that are bundled with it to demonstrate all of its capabilities so far.

You can read more about it on the website here.

Project

Goals of the Project

As with my previous projects, I decided to test the PICO-8 out by writing another simple shmup game. This is because I am more familiar with how to create a basic shmup than I would with a new genre, such as platformers, which allows me to focus more on learning how to work with the PICO-8. Since I was not familiar with the Lua language, and I was not familiar with the limitations of the PICO-8, I did not want to create anything more elaborate than my last project. My goals were to:

Create a simple scoring system, which included a score multiplier based on destroying enemies.

Randomly generate enemies for a more “endless” feel to the game, and to experiment with how much content I could fit in the limited space.

Knowing about the limitations, I wanted to see what it would take to create slowdown in the system and experiment with how to manage or design game play with the slowdown.

Current State, and Next Steps

I completed most of the coding today, although the scoring is very rough and the gameplay is not polished. But, I am satisfied enough with what I have now to start exploring the graphics and sound. Through this initial exercise, I have only used about a fourth of the space I have to code with, and less than one of four sprite sheets provided by the console, so I have a lot more room than originally anticipated to work with.

My next goals are:

Add scrolling backgrounds. I might try creating a parallax background since some of the demo projects use them.

Add more visual effects to add more impact to the game.  

Add music.

I would like to give a shout out to the developer who made this short tutorial. I was trying to figure out different ways of handling collision, and their method of handling collision and creating faux hitboxes was perfect.

Download and Play Instructions

If you have a PICO-8 console, you can download the .PNG file above and install it. Otherwise, you can download the file below and play it through a browser by opening shooter.html. There might be some input delay if you play through a browser.

To play the game:

Z - shoot

X - laser

Arrow keys - move

Scoring system:

Destroying enemies increases the multiplier, and increases enemy spawn rate. Enemy spawn rate currently does not decrease.

Using the laser decreases the multiplier.

Getting hit resets the multiplier.

The multiplier decreases after 180 frames, with time indicated by the blue bars in the upper left corner.

Higher multiplier gives a higher chance of spawning the stronger enemies

The game currently slows down when there are too many things on the screen. This intended, and will be tweaked as I experiment more.

Download Link: Here

[jjvgaming]

First GameMaker Experience

In September, the GameMaker Humble Bundle was released. I picked up the bundle since I was intending to try it for my next project anyway. For anybody interested in GameMaker, it’s available with a free license on the website. There are some limitations as outlined on the download page, but it contains enough functionality to try out. 

My goal was to become familiar with GameMaker, and create a simple shmup as I did with Unity at the end of my previous post. Based on reading other user experiences, and reviewing the documentation, GameMaker sounded significantly easier to use than Unity. Since it was theoretically easier to use, I planned on adding a little more complexity to the shmup, which I will outline later in this post. Excitingly enough, I’ve included something playable in this post. 

About GameMaker 

I am writing this section because I can’t think of another way to emphasize how easy GameMaker is to use. If you are reading this post, and would like to try game development, this might be a good place to start.  

GameMaker is designed to make game development as easy as possible. Creating a game in GameMaker requires little to no programming experience, because most of the development can be done through clicking, dragging, and dropping icons in the UI. The drag and drop functionality can be used to perform relatively simple actions, such as assigning health to an object, or assign a key to an object’s movement, to more complex actions, such as conditional statements that check on an object’s state before performing any actions.  Theoretically, you could create a whole game through drag and drop and not perform any scripting if you didn’t want to.

Example: Actions are assigned to specific Events experienced by an object, such as being created, or upon pressing a key. If you want to assign life to an object when it is created, it’s as simple as creating the object, adding the creation event to the object, and dragging and dropping the heart from the icon on the right, into the window on the left.

Example: Creating conditional statements. This is an action I have mapped to pressing “Z” on the keyboard to determine whether or not my object could perform an action. 

If you prefer, most of the actions performed through the UI can also be done through script using the proprietary GameMaker Language (GML). As you can see in the above screenshot, part of my conditional statement involves an action called Execute a piece of code, which I’ve included below as a sample.

Example: The aforementioned script. This spawns bullets in front of my game object if less than 10 bullets exist on the screen at once. GameMaker can be configured to use your preferred text editor. 

The tutorials available on the GameMaker page are very useful and easy to follow if it is your first time using GameMaker. There is also a marketplace if you’re interested in downloading assets or extensions to use for development.

The Plan, and Results 

As with the Unity shmup, my three original goals were: 

Show a score

Have bullets

There is a boss that can be defeated

Based on the previous experience, I added a few more goals to this project:

Plan out the project better than last time. This included planning the objects I wanted in the game, their hierarchies and relationships, and variables that I wanted to keep track of in the game. 

Create a more advanced scoring system. In the previous project, the player would always receive the same score after defeating the boss. For this project, I wanted to differentiate more “skillful” play from safer play by adding a multiplier to the scoring system. The intention was to add more complexity to the game and encourage the player to play more dangerously for more points. I currently have a few ideas for this, but I implemented a very stripped down version in this current project. 

Create additional bullet patterns. Due to how easy GameMaker was to use, I wanted to add different phases to the boss, each with a different bullet pattern. 

Create original sprites for all objects in the game. This was done through GIMP. 

Create music and sound effects using the 3DS Korg M01D software. I had some experience using Korg software on the DS and 3DS, and wanted to create a more complete product with this experience. 

I was able to create the following in less than 12 hours of work, which felt really fast for creating something playable. The most time went into creating the music, because I could not decide on the theme of the music, and wrote and tested a few music drafts. 

You will need to turn your volume up to hear the music and sound effects. Please be careful when you go back to what you were doing or listening to before. 

Want to try it out? 

If you’re interested, you can download the game here. 

To install, just extract the .zip file, and open the contained Project1.exe file. Please keep in mind this is not anywhere near a complete game, and will contain bugs. Through some quick testing, the game may not run at full speed. 

Controls

Z key - Shoot. Hold to slow down and increase multiplier. 

Arrow keys - Move the ship

Lessons Learned

The biggest lesson learned during this project was the importance of visual and sound effects in a game, how they depend on each other, and how they aid in the experience of the game. For example, think about how attacks connect in a game like Street Fighter V, or Super Smash Bros. When an attack connects, the game freezes momentarily (called hitstop), a small explosion indicates where the character is hit, a distinct sound is played, and the character receiving the blow may heavily reel in pain (or fly off of the screen). This might seem like an obvious realization, but in developing this game, the game felt like it was missing something before any visual or sound effects. There was no sense of satisfaction while attacking the boss, and no sense of dread when losing a life. Something even as unnoticeable as the sound of a bullet hitting the boss, and the small purple explosion for each bullet upon impact, filled this missing hole in my game. Once I added the visual and sound effects, then music, I felt like the game had a more emotional impact because every shot felt like it counted, and taking damage felt more alarming and stressful. Creating each effect was a deliberate choice, and in practicing this, I gained more appreciation for this aspect of game design. 

Specific to this game: 

This scoring system on its own is not interesting, and is flawed. Holding down the “Z” key and moving around increases the score multiplier, and slows down the ship, while getting hit resets the multiplier. The mechanic on its own has flaws, because the multiplier unintentionally feels like it increases every time the player decides to shoot a bullet, which does not necessarily mean the player will need to play more riskily to score more points. If I ever attempt to perform a full implementation of the scoring system, I will consider adding startup time before the score multiplier increases. 

This bullet pattern is almost worthless for the boss. I did not put any thought into this, and from the start, I knew that the bullet pattern would not be difficult to any player aware of how the boss acts. The boss moves from left to right, shooting a three way shot. This creates a safe spot slightly to the left or the right of where the bullets spawn, and to the left, right, and behind the boss. Due to this, the score multiplier could be manipulated by getting into any one of these safe spots. 

Closing Notes on GameMaker

The main thing I liked about GameMaker was how easy it was to use. Like demonstrated before, most of the development involved dragging and dropping things in the UI. 

However, I had some minor annoyances while working in GameMaker:

Although not writing any code sounds like a great idea, since most functionality is represented by a number of icons in the UI, the UI will (and did) eventually become cluttered for some complex conditions. 

Scripting is a cleaner way of representing complex actions on an object, but as you saw in a previous screenshot, a script is represented by a sheet of paper. If I added a script in one event that initialized some variables, but needed those variables in another event, there was no way to know which variables I initialized previously without re-opening the script, or keeping it open. The “Show Information” functionality on an object will show all of the events on an object, with all of the scripts expanded, but this functionality does not update in real time. 

Since GML is proprietary, it cannot be used anywhere else, so I did not feel completely invested in learning it. GML is intuitive and is documented very well, but with the minor annoyances of scripting, it feels like scripting is kind of discouraged. 

With the difficulties above, perhaps there are ways to reconfigure Game Maker or use extensions that will make the developing workflow easier. I plan on using this for at least getting out quick prototypes, if not developing fully fleshed out ideas in the future.

[jjvgaming]

First Unity Experience

In mid-2015 and early 2016, I began using the Unity game engine to dabble in video game development. My goal was to try creating a 2D game: either a puzzle game, or a “shmup”. By mid 2016, I had created a couple “drafts” just to understand how Unity worked. Unfortunately, I did not take detailed notes on how to use the engine, but I have some lessons learned, and took some progress videos of development. 

Puzzle Game - Panel de Pon? 

The Process

My first project was creating a single-player puzzle game with a friend that was similar to the puzzle game, “Panel de Pon.”  In America, this game was brought over from Japan as “Tetris Attack,” and eventually evolved into “Puzzle League,” which has recently been ported to Animal Crossing: New Leaf on the 3DS. The idea was originally my friend’s, and I decided to work with him to give myself some motivation. Basically, the game was supposed to be exactly like Panel de Pon, but a robot character acting as a store clerk to move the blocks, and obtaining gifts after clearing pieces. After reading some Unity documentation, I decided that he would create the sprites (and basically the art direction), while I worked on programming, and we jointly worked on some designing. 

We began by taking notes playing Tetris Attack, such as: 

What is the objective of the game? Conversely, what is the losing condition? 

How is the game played in single and multi-player mode? What are the controls? 

How large is the game’s grid?

What color are the pieces? How many colors are there? 

How are the colors and pieces generated? 

How do the pieces move and interact with each other? 

After that, I began working on programming the game, while my friend began working on the sprites. The idea was that he would create sprites, learn how to use them in Unity, and send me the sprites. Since I was programming the game, I came up with places where I would need the sprites, and asked him to make sprites for those places. Here is what came out of that: 

Understanding how to create and move objects in Unity. Blocks, border, and background are all placeholders:  

Adding gravity, and interaction between objects: 

Experimenting with spawning blocks. Friend also sent over a sprite for a character, and sprites for blocks that I added. 

Coming up with a spawning algorithm, and learning about collision issues for the first time: 

In the end, we did not finish even half of a game since it was still unplayable. But, I was able to walk away with some basic, but valuable lessons.

Lessons Learned

These lessons learned are from memory, so they only include some highlights: 

Since I was solely programming the game, I had to consider most of the design choices for the game play, and how to put those design choices into a working, enjoyable game. There were many iterations of the game as I learned Unity over time, but I tried to stick to the goal of Panel de Pon. This led me to discover a couple of questions that I still consider when thinking about an idea, and playing video games in general: 

What is the main goal of the game? Who is the game intended for? 

How can I make it enjoyable for that audience? Conversely, why is a game enjoyable for me? 

Are any of the design choices unnecessary? Why? Could the design choice be useful elsewhere? 

Working on a team is not necessarily dividing up the perceived types of work, such as art and development. More collaboration is required to understand what is needed between different team members so all members can fairly influence the final product.

Physics and collision are more work than expected.  

In the case of this game: should a puzzle always be solvable? How do I generate blocks so that the player is never stuck with an unsolvable puzzle?

Understanding how to organize your assets will make finding them easier. This includes file structures, naming conventions, and creating meaningful relationships between assets.

At the time of development, developing in 2D with Unity did not feel natural. The issues that I ran into included:

Making graphical assets pixel perfect 

Understanding resolution and the screen space, and how to to design and plan around this in Unity’s scene

Mixing of “2D” and “3D” functions. Based on some tutorials, some of the functions that were named specifically for 2D were not used. Instead, their 3D counterparts were used, but I was not sure why at the time.

Generic Shmup? 

Based on learning from the Panel de Pon project above, I started a less ambitious project. The idea was to create a shmup with these requirements:  

Shows a score

Has bullets shooting at the player

There is a boss that can be defeated

I have no notes on my process or lessons besides the code. But, I imagine it was the same as the previous project due to how close the development of this project was. 

This is the outcome: 

Main Lesson Learned

I chose to start with Unity for two reasons:

Perceived familiarity and flexibility. Since I was programming in a couple of languages that I was kind of familiar with (C#, JavaScript), it was easy to create and manipulate objects. Also, there was a large library of extensions via the Unity Asset store, and parsing through the code or documentation for these extensions may have been easier with my background knowledge. Lastly, the ability to create 3D games was there if I ever wanted it. 

Ability to export to multiple formats, including mobile, which I originally aimed to develop for.

Unity is clearly a powerful engine that is used for many popular games. However, it did not feel natural developing in 2D with Unity. This is because I felt like I was fighting with the engine and working around its 2D inefficiencies more than working with the game. Although it is the first engine I worked with, I read about other engines that may intuitively work better for developing in 2D, such as GameMaker and Love2D. I may re-visit developing with Unity in the future as I learn more about game development, but for now, I will explore other engines and post about them here. 

[jjvgaming]

First Post

Over the past year (2016), I’ve started slowly developing games, and unintentionally collecting games. As I’m coming up with ideas, learning about game development, and playing games, I thought that it would be a waste to not write down my experiences for myself to reflect on.The blog will start with some experiences in hindsight, and will eventually cover current experiences.

My aim for this blog is to:

Record any meaningful lessons learned while developing

Progress of development

Maybe create some short tutorials for things learned

Some thoughts of games that I’ve picked up