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!

This Just in! One Man Team Creates World of Warcraft!

Or maybe not. Remembering your resources, and setting a reasonable scale can be one of the most important things you do when creating a game. If you are working alone, I am going to go out on a limb and say it would be difficult to create a replacement for World of Warcraft in the next 4 weeks.

It is hard telling how many projects I have seen that haven’t been finished. It wasn’t for lack of effort and it wasn’t for lack of passion. It was usually for lack of planning. Most of them were hobby projects that were staffed by volunteers. Then life happened.

building blocksThis is one of the main reasons that I recommend Scrum to most hobby teams that I talk to. This allows, if done properly, for the project to be broken up into bite sized pieces. This has a two fold effect. First off, it makes the project seem more manageable. You don’t have to create and entire world. You only have to take these pieces that are already completed and make a city. You don’t have to make 42 different kinds of buildings while designing an entire metropolis. You only have to create one building. Secondly, if someone has to leave mid project, you can ask them to finish that bite sized chunk that they are working on. Since it is such a small chunk, this seems like a very reasonable request. Once that chunk is done, then they can leave without having too profound an impact on the rest of the project as a whole.

Scrum, like I said, is about bite sized chunks. The idea being that at the end of each “story”, or chunk, should be a self contained chunk. In terms of Unity, this could be creating a Prefab for a building, or for completing a script. The Prefab or the script doesn’t have to be used anywhere, but it should be completed, tested, and ready to be used. If, for whatever reason, you can’t break something down to a bite sized chunk then most likely you don’t really understand what you are attempting to do. Remember, a story shouldn’t be creating a city from the ground up but rather there should be stories for the building prefabs and later another where you are simply using the prefabs that are all created and ready to go to create the city.

Long story short, look at the building blocks, not the model.