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!
The 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.
If 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!
You must be logged in to post a comment.