Jump to content
Sign in to follow this  
  • entries
    13
  • comments
    11
  • views
    1383

Game Development Lessons - April 14, 2018 Weekly Update - Untouched Earth Game Development Blog

WaterMoon

1395 views

Hello Readers! I had a great opportunity this past weekend to have some people play test the game. For the most part it went well…that is, until the frame rates dropped to a point of being unplayable, glitches caused the player to reset to random places on the map, and the controller seemed to invert itself through an act of black magic. The experience was very enlightening and served as a gentle reminder that making games is a TON of work and requires loads of dedication to see it through to the end. In the spirit of humility, I thought I would use today’s blog entry to discuss the lessons I learned, and how I intend to progress moving forward. I welcome any insights and comments, and I would love to hear about some of the lessons you've learned along the way.
 
Lessons
1) Play test early and often with people other than yourself.
2) Profile early and often on the target devices.
3) Don’t leave highly problematic bugs and errors for later.
4) Don’t change the algorithm for essential game mechanics too late in development.
5) Keep lots of backups.
6) Learn from other's mistakes
 
Play test early and often with people other than yourself
This lesson was a hard one to learn. When the first level of the game was complete, I thought I could simply play test it myself and would get good feedback. This was true, but only to an extent. When I let other people play it, I quickly found out that the controls are confusing, the map doesn’t provide enough direction, and players will use the main character in ways I never even thought of. It would have been incredibly helpful to test the core mechanics on another person early on while I was developing them, rather than waiting until multiple levels have been made. As it stands, I’ve spent around 12 hours changing the controls on the hero’s climb animation so the mechanic feels more natural.
 
Profile early and often on the target devices
There were some serious frame rate drops going on that I didn’t realize because I was only testing the game on my home PC, which has a strong specs. When I put the game on my laptop, the frame rates dropped to the point of losing playability. I learned that profiling isn’t something that needs to wait till the end of development, and it would have been wise to profile as I built up the core mechanics. Using the profile after each new level or major game change and responding to its results is a great way to avoid these types of issues.
 
Don’t leave highly problematic bugs and errors for later.
It’s easy to become so fixated on finishing the game that errors and bugs are pushed off until a later time. I find, however, that engaging in this procrastination results in a ton of errors that compound on one another. For example, there was a problem with the hang animation, which caused a problem with the physics system, which caused a frame rate drop, etc. etc. Fixing these errors and bugs in order to build a strong foundation for the game mechanics is essential.
 
Don’t change the algorithm for essential game mechanics too late in development
In an attempt to fix the problems with my climb mechanic, I decided that the current algorithm had too many bugs to be salvageable. I spent a good number of hours creating a new algorithm that ended up failing miserably. The worst part is I screwed up the main characters script so much in the process that I had to revert to an earlier backup. After restoring the backup, I discovered a way to upgrade the mechanic as well as fix many of the bugs. Nothing is more heart breaking than losing hours of unnecessary work, which leads me to the final lesson.
 
Keep lots of backups
After every major change, make a backup. After every development session, make a backup. After every optimization, make a backup. The point is, keep lots of backups. I made the mistake of optimizing a lot of code and then trying to redo the algorithm for the climb mechanic. Had I made a backup AFTER the optimization, I wouldn’t have spent so much time redoing work.
I know there are a lot of lessons left for me to learn.
 
Learn from other's mistakes
All these lessons bring me to my final point - Learn from other's mistakes. I do a good bit of reading about challenges other developers experience, but it is so easy to think "that won't happen to me." Humbling oneself and learning from another person's mistakes is wise, and I plan to listen to the advice of seasoned developers.
 
Which brings me to my final question, what lessons have you learned about development along the way?
_______________________________________________________________________________________
As always, thank you for reading. I would love to hear from you and would love to hear any comments or ideas you have. Feel free to leave a comment or email me at watermoongames@gmail.com.
_________________________________________________________________________________________


2 Comments


Recommended Comments

Good info, thanks!  This type of thing always seems simple but bears repeating because I can't even count the amount of times I've accidentally lost a day's worth of work because of neglecting to hit save and the editor crashes on me.  Save early, save often!

 

Share this comment


Link to comment

I couldn't agree more! I've definitely had my fair share of lost work from not saving. Thank you for the reminder!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By 3dmodelerguy
      For reference I am use Unity as my game engine and the A* Pathfinding Project for path finding as there is no chance I would be able to create anything close to as performant as that in any reasonable amount of time.
      So I am looking to build a game that is going to have a very similar style as Prison Architect / Rim World / SimAirport / etc. One of the things that I assume is going to effect performance is path finding. Decisions about the game I have already made that I think relate to this are:
      1. While I am going to be using Colliders, all of them will be trigger colliders so everything can pass through each other and I will not be use physics for anything else as it has no relevance for my game
      2. I am going to want to have a soft cap at the map size being 300x300 (90,000 tiles), I might allow bigger sizes but do something like Rim World does in warning the player about possible side effect (whether it be performance or gameplay)
      3. The map will be somewhat dynamic in that the user will be able to build / gather stuff from the map but outside of that, it should not change very much
      Now I am going to build my game around the idea that users would be in control of no more than 50 pawns at any given time (which is something I can probably enforce through the game play) but I am also going to want to have number other pawns that are AI controlled on the map (NPCs, animals, etc.) that would also need path finding enabled. Now I did a basic test in which I have X number of pawns pick a random location in the 300 x 300 map. move towards it, and then change the location every 3-5 seconds. My initial test was pretty slow (not surprising as I was calculating the path every frame for each pawn) so I decided to cache the calculated path results and only update it ever 2 seconds which got me:
      100 pawns: 250 - 450 FPS
      150 pawns: 160 - 300 FPS
      200 pawns: 90 - 150 FPS
      250 pawns: 50 - 100 FPS
      There is very little extra happening in the game outside of rendering the tilemap.
      I would imagine the most pawns on the map at a given time that need path finding might be a 1000 (and I would probably be able to make due with like 500 - 600). Now obviously I would not need all the pawn to be calculation paths every 2 seconds nor would they need to be calculating paths that are so long but even at a 5 second path refresh rate and paths that are up to 10 tiles long, I am still only able to get to about 400 pawns before I start to see some big performance issues. The issue with reducing the refresh rate is that there are going to be cases where maybe a wall is built before the pawns path is refreshed having them walk through the wall but not sure if there is a clean way to update the path only when needed.
      I am sure when I don't run the game in the Unity editor I will see increase performance but I am just trying to figure out what things I could be doing to make sure path finding is as smaller of a performance hit as possible as there is a lot of other simulation stuff I am going to want to run on top of the path finding.
    • By phil67rpg
      well I am able to get my sprites to rotate and move in all directions, I have drawn two plane sprites, I am also able to shoot a bullet in the up direction, I want to shoot bullets in all directions just like my plane rotates, I just need a hint on how to proceed, go easy on me this is new stuff to me. However I am making progress.
    • By Gas Lantern Games
      Hello!

      I have spent the last year and a half developing a game in my spare time in Unity! I am releasing it soon on Steam. Ant Empire is a strategic remake of some older games. It is influenced by games such as Ant Empire and Civilization.

      I am currently doing a kickstarter to help fund an AI before launch.

      I have attached some images (tried some gifs but they were too large) to show the current stage of Ant Empire, which is nearly completed.







    • By Alex Yarotsky
      Making games is hard. You need all kinds of technical and creative skills, you need a big team, a budget...
      But making your first game can be even more difficult if you have no previous experience in game development and your team is only two people.
      But it didn't stop us. We quit our jobs and started this indie game journey full of mistakes and pitfalls.
      Why? What encouraged us to make this stupid move?
      Inspired by Extra Credits, Hellblade Dev Diaries, and ThinMatrix we decided to start a weekly behind the scenes show. There we'll be showing bits of our production process. The whole project is a huge and risky experiment for us and we would love to hear your support and recommendations.
      We are opened to all sorts of feedback. Even if you consider something is of a low quality in our video, please let us know it as is. We would love to learn from the community and improve.
      Thank you.
       
       
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!