Fall 2018 GameDev Challenge: Frogger – Post-mortem

November is coming to an end and that means the fall challenge from GameDev.net is ending. I wanted to start taking part in these challenges as a way to continue flexing my gamedev muscles, but sadly the gamedev muscles aren’t the ones that apparently need flexing.

The challenge that was going on this fall was to recreate Fogger. That is straight forward, but still has enough room to let you be creative. I decided that I was going to go with an old-school style of gameplay, but with bug graphics instead of the traditional frog. I wanted to mix the old and the new.

Since I am not very talented with graphics, I turned to Game Developer Studio, as always for projects like this. I his art style and it gets the graphics done in a hurry for me. Win-win!

I didn’t allocate time for this challenge, but was planning on just working on it when I had time. Big mistake…

The gameplay was a bit interesting to get done. I wanted to have the jumping movement that the retro versions have. This is easy enough since I can just change the position of the game object. The only issue that this brought was with collision detection. A quick raycast, however, takes care of that problem. The next problem was the top half of the level where you wanted to jump onto the moving obstacles instead of missing them. Here, I created a game object “death zone” and had the obstacles be moving safe zones. This is the only part of the gameplay that isn’t done yet.

Lets talk about the “isn’t done yet” part now. Life happens. That is a given and there is nothing you can do about it. I didn’t allocate time for this challenge, but was planning on just working on it when I had time. Big mistake. I honestly thought there was more than enough time to get everything done. I thought that I would be able to finish it up in about 8 hours and since I had a month and half to finish there was no point sweating it. I was wrong.

For the next challenge I think it will suffice to have 2 hours during the week and 2 hours on the weekend. I don’t have a lot of time between my full time job, my family, and my other random activities that I do. 4 hours a week should be possible though. I suppose I will have to put it in my calendar.

The other issue that I had was with the planning. It was a smaller project so I didn’t see the point in laying out a plan. That was also a big mistake. Feature creep is a real thing and it is ugly, especially in a small project. I have a todo list that keeps my entire life in order and on track, and I will definitely use that for the next challenge.

It was a smaller project so I didn’t see the point in laying out a plan. That was also a big mistake…

All in all, it was a great learning experience. I have never done anything like this before and I think it has helped show me what I need to improve upon for next time. There will be a next time!

Until then….enjoy!

Choosing an Engine

Making a game is all about weighing pros and cons. If you prefer, you can think about it in terms of cost benefit analysis. This starts with picking a game engine.

While there are the well known like Unity or Unreal Engine, there is the less known like Construct 2 or Coco 2Dx, and there is also the option to create your own. To be perfectly honest, you could also go without an engine and just create everything that you need as you need it. There are pluses and minuses for each of these choices so how do you really decide what is best?

Unreal_Engine_logo_and_wordmarkThe first thing to look at is why you are making the game. If you are making the game in order to showcase your skills to future employers, then it would be best to use one of the more popular choice. You want to show the world what you can do with the tools that they are most likely to be using. There is no point in showing them a game made with Coco 2Dx, if they are only going to be making 3d games using Unreal Engine. Since there are so many engines out there, it is best to make a variety of games with different engines, if this is truly your goal.

moaiattribution_vert_whiteIf you are making games in order to experiment with technology, then it is best to use the lesser known engines. There is enough information out there that would allow almost anyone to make a basic game in Unity. Try using Löve. What about Moai? While these might not say much to most people, those in the know might still be impressed. These more obscure game engines also give you an excuse to learn a new programming language!

Finally, you can create your own engine, or go without one predefined. This is the hardest route to take. You are forgoing the knowledge and time that others have invested in order to reinvent the wheel on your own. If you can do this, it shows that you are capable of truly great things. Programming a game engine from the ground up requires foresight, planning, and immense testing. There is the documentation, the maintenance and feature requests from others, and the tutorials on how to use it. This can easily be a project bigger than most games.

As you can see, choices abound when you start looking at it. While the basics are good, you have to think about what you are trying to prove with your game. Who are you trying to impress?