Developing in pygame was a great intro to the concepts employed in typical game code. If there was something that needed to be done besides render a line/square/sprite on screen, read an input, or play a sound, I had to think it through and build that code myself! This was marvelous in a way because it pushed me to think through a lot of problems and create solutions for them. I then knew those systems top to bottom and could extend any part of them with relative ease and full control.

When it came time to move over to a modern game engine supported by a commercial developer, I found out just how many of those custom solutions were already solved for out of the box and often with a gui element to replace what I had build solely

At first it seemed like 75% of my dev time spent coding would go away and I would focus on design and assets. That idea quickly faded and the work was replaced with not just coding time itself, but learning the new 'unity approach' to things.

The challenges that hit me were:

• - big workflow change
• - relearning the unity version of concepts
• - learn new concepts and systems
• - learn new component design patterns (vs just OO)

First off my workflow changed significantly. With PyGame everything I did besides art creation looked like this:

While in unity, my work might start to look more like dropping in and configuring components in an interface like this:

I was no longer just code based, I was working in a mixed code and GUI enviroment now, which came with its own learning curve. Add to that the fact that Unity is highly customizable, so you could really ignore most of the GUI if you want and just use the engine in a mainly code-based workflow if you want, so I needed to learn where using the GUI was advantageous vs keeping my work in c#, or how to expose my scripts to the gui and prefabs to achieve efficiencies unavailable to just one method or the other. This still proves a to be a bit of a challenge as my needs evolve along with my familiarity with the engine itself and its support of component-based design over object-oriented.

In my pygame ARPG, I could trace the execution of every event back to the the line of code in the top level of the game loop and back again because I had to build all of that. However, when you pick up unity, you realize that main loop is already baked into the engine somewhere and the passage of time is obfuscated away from you. It meant I had to be aware of my lack of control over that particular aspect while rebuilding.

The next challenge was having to dig into actual physics systems and the like. In pygame and python for my 2d game, I didn't have to think much about actual physics computations, lingo, etc. I could just say this object was going to move in this direction at this rate. No rigid body talk, no apply velocity, no active/inactive bodies, just X + 1 for N ticks of the game loop.

It has taken months of learning and rework at this point, but I think I am finally at a point of hitting a development stride with the Engine, AND, I am now a more well-rounded dev because of it.

Growth is never wasted time! Looking forward to changing gears to discussing how my animations evolved during this rebuild on the next post, so keep an eye out!

-TheHocken