Uphill Struggle

I'm not really sure what to do - should I just go back and work on something simpler?

Yes.

Since posts should be more than one word long the rest of this is just padding, but the answer really is just that simple.
You’ve passed the point where you feel the project and your motivation can be salvaged, so stop working on it and start another project. It’s normal.


L. Spiro

I have an ever increasing amount of school work to be completing, leaving me less time to work on my projects. Apart from feeling that the platformer I was working on is far more complicated than it should be, I'm just not getting anywhere with it.
I'm not really sure what to do - should I just go back and work on something simpler, or what?

Yes, but remember that your school work has to come first. You're in school. Job #1 is your school work. As for your desire to make projects, start simple, absolutely. Same advice as everybody gets.

School work is the number one priority like Tom said.

I wanted to add though that your project is not a failure if you learn from the project. If you have reached a stage where you are unable to move forward with the project then I think you just learned valuable lessons about software design! Learn from it and move forward, and your next project will be better for it.

Hi,

I agree with everything written in response so far (!)

School is different than real life because in the institution of education your work is graded.

In learning game development, no one is going to judge you except perhaps yourself at this stage.


Frankly, if you are having that much trouble with making changes, then I would say that your source code is mangled [slang!]. Start fresh!

The next game will be much better. You will do more modulization. See this link:
http://en.wikipedia....ki/Modulization

Don't sweat it! You have only gained experience! Everybody is facing huge challenges at some point in game development.!

You will be just fine.


Clinton

Edit: See this link, too:
http://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions

I don't have anywhere near as much experience with game development as I would like to, and I have an ever increasing amount of school work to be completing, leaving me less time to work on my projects. Apart from feeling that the platformer I was working on is far more complicated than it should be, I'm just not getting anywhere with it. Due to my entity management system, I'm struggling to fix bugs with the collision detection and movement without breaking something else. I feel like I've either bitten off more than I can chew at this point, or am simply over complicating things.

Everyone has already told you to work on something simpler, and I agree with them, however here is a collection of important things:

1) Every day, when you come home, finish school work, then program.
2) Finish school projects in your normal "programming time" instead of procrastinating.
3) Read a Programming book. Read it at school, at home, while waiting for something. Just read it. It'll keep your mind focused and help further your understanding.

Now, about your platformer.

1) If your code is breaking, as detailed in the quote above: Your code is suffering from a case of Multi-Responsibility (Oh The Horror !).

Essentially, ideal code utilizes the single-responsibility principle to the best of it's abilities. What is the single-responsibility principle, you ask? Well:

I'm sure all of the senior programmers here understand the fundamentals of object oriented design, but this is for the beginners. First, let's define object oriented-design:

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem.[/quote]

That hits the nail on the head. One important thing to note about object oriented design is this, you're planning a system of interacting objects. That means you're objects will work together. Many a beginner programmer, including me , don't grasp this. You're objects should work together. They shouldn't be isolated from each other so you only make separate instances of them, you should be using them together.


This leads into the first Principle of good object-oriented design

The Single Responsibility Principle

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.[/quote]

This is the fundamental building block of object-oriented design. Before we continue, let's take a closer look at what a responsibility is. In programming, a responsibility is something the class handles or does. Let's use a pong example:


When I first programmed pong, I had my Paddle class drawing itself, checking for collision, and updating itself. <-This was how all my other classes were designed too. This led to fragile code that would break if I changed any class, and the only way to fix it was to go through all my source and header files to fix the problem. The single responsibility principles goal is to make the above problems nonexistent in your code, and it largely succeeds.

Let's look at how we could fix this:

Have the paddle classes main goal to only update the paddles position and values. It doesn't draw the Paddle to the screen anymore. Do the same for the Ball class and the AIPaddle class. Then create another class called GameDraw. This has one AIPaddle, one Paddle, and a Ball. All this class does is use my get() functions to draw my objects to the screen. This means making a change to how I draw the screen doesn't affect my classes at all, and changing how I update my variables doesn't change how I draw my objects. Then I create a gamelogic class. This class calls all my Update() functions, thus making a change to how I update my objects won't change this class, and making a change to the order I update or what I update won't change the other Object's classes. Then, I create a BaseGame class. This class' responsibility is to run the game. It includes the gameobjects I need and a GameDraw/GameLogic class. Now, changing my class' won't mess up the rest of my code, because my classes are handling their responsibility, and the rest of my classes don't have to deal with them.


I hope all beginner programmers can read either this, or another article about this, because the Single Responsiblity Principle is extremely important to writing bug/error-free code, and will save you a lot of headaches by isolating what's causing problems, while still letting your classes work together.

(I wrote this article myself, just copying and pasting )

Essentially, that's why your program is breaking. You should try to follow this principle (And please do more research on it, I'm not the best explainer.)

It is impossible to tell wether you have undertook too big task without knowing more about you and your game ;)

I have been in similar situations where I see how my code has grown into unmanageable mess. But usually at that moment I have already "seen the light" - i.e. what should have been done differently from the beginning.
I suggest not abandoning your current project - you have most probably already invested much time into the design of concept, gameplay etc. But be no afraid of starting over - as long as you consider it your learning project. Of course finishing crappy game is usually better than not finishing clean and elegant one - but on the other hand rewriting everything is better than abandoning it.

Lauris Kaplinski,


I feel strongly that strategic risk management is always in effect. The sooner the programmer drops a very bad spaghetti source code, then the sooner such person will succesfully finish the next much better program. Sometimes there is a borderline situation which would allow a good decision in either case - stay or move - but Silgen's source code sounds too complicated to salvage in a reasonable time, especially under frustration.

The risks of staying with a failed program to repair it are far greater than the risks in the next new project in general. Some things can not be realized in staying with the failed code. Some bad coding habits likely will remain by staying. A new program with the desire to learn things such as modulizing under certain interfaces, inheritance vs encapsulation, discrete variables, and so forth - should be the very next stage of learning for Silgen.

Of course, only the programmer can decide if the program is too stuck in the mud to free it, but it sounds to me like it got lost in the swamp. Ever hear about "flood vehicles"? Most people won't touch them because of all the many risks of malfunctions - just not worth salvaging them. I would claim the insurance and get back to work in a new vehicle - thank you very much.

Some battles are the same way: Too far gone to save so a strategic withdraw and preparation for a new battle is in order.


Clinton

A good rule is always "Finish what you start".

I'm in the same situation as you. I have to get a full set of A* to get into the school I want, and I have to do well on an interview that is likely to be torture, and I'm trying to make a game.

It's harsh, but for me... I finish what I start. That doesn't say I don't change things around. I basically only work on the game when I feel like it. I have stopped, if I ever started, to think that I have to finish it by a certain time. For me, the game has morphed from being a thing I have to finish to a thing I escape to when I feel like my mind needs to unhinge from everything.

So, maybe you should do the same. Finish it, but turn it into a relaxation thing instead.

Mmm... You could refactor your code! But don't take it as "trowing everything through the window and start anew" but as another project. Like if somebody said to you "Here, I got this bunch of code and I need you to make something better out of it".

Put your game on stand by and start a refactor project of your code, rethinking what you have done until now. Don't add features! Just think again about your design, see if you can come up with a better design that does what your current codebase can do now. Once that one is complete you can pick up where you left it.

I feel strongly that strategic risk management is always in effect. The sooner the programmer drops a very bad spaghetti source code, then the sooner such person will succesfully finish the next much better program. Sometimes there is a borderline situation which would allow a good decision in either case - stay or move - but Silgen's source code sounds too complicated to salvage in a reasonable time, especially under frustration.

The risks of staying with a failed program to repair it are far greater than the risks in the next new project in general. Some things can not be realized in staying with the failed code. Some bad coding habits likely will remain by staying. A new program with the desire to learn things such as modulizing under certain interfaces, inheritance vs encapsulation, discrete variables, and so forth - should be the very next stage of learning for Silgen.

Agree.
But that was exactly what I was suggesting - to abandon code but not abandon game. Even if one starts programming from scratch it usually makes sense to keep the existing non-programming design.
Also - even if you start programming from scratch you will normally end using many bits and pieces of previous codebase. The general design may be unreadable spaghetti code but simple parts and algorithms may still be well written.

Lauris Kaplinski,


Okay, so agreement we've got here.

Yes! We are recommending a new effort, program, and project to restart this game source code, beginning with looking at using some good lines of code in the old one. Silgen should begin now learning about things such as the "Single responsibility principle" and other already mentioned in this thread. The programmer is ready for the next stage of learning in refining this game design in preparation for the next one, while dropping the speghetti code for a fresh start on a new one for the game.


Clinton

Hey there! What you have described is actually very common from what I've seen and experienced myself.

About how the game is getting "too complex".. I know how you feel. Sometimes you program very elaborate systems which then have to interact with each other and you have to remember what all your variables are and it can get very confusing.

There are a few ways to help this.. First of all, I think it's good that the game is complicted.. When we are learning we often make a big mess of simple things.. we might use dozens of lines of code for something that one day we will only need one line of code for. But doing it the long way will actually teach you alot and later everything you learn will help you be able to keep things more simple. It's like baking a cake for the first time, you'll probably make a much bigger mess the first time you try it.

Another thing I find that helps me is simply working on your project a little bit each day. This keeps you "in touch" with your project and also keeps it moving along. You can also grab a pen and paper and write down things as you work that you might need to look up later, like a little reference note-book. Next time you can also create a detailed plan about what your game is going to consist of and what system's you'll need. When you have the overall picture in your mind it helps give you a good direction while you are working.

"Biting off more than you can chew" is something alot of us probably experience, but I think it's actually a good thing as it forces you forward into new areas of learning and expands your knowledge and skills as a game designer.

About the motivation thing.. This is very normal and it's something you have to learn to deal with if you ever want to actually finish projects and ship them.

The truth is, when you first get an idea, you just burn with excitement for the project, but that motivation always dies down as the projects get going, the challenges and hard work set in, and you get used to your own idea so it loses that "cutting edge" feeling it had when you first thought of it. You have to keep going despite these feelings. I think what alot of us game designers do is that we think of a good idea and start it... then we hit that phase where it's challenging and the motivation subsides, and we get a new cool idea so we abandon the old project and start a new one.

Then we just get stuck in a loop of unfinished ideas.

My advice is simply to make a list of the games you most want/need to complete. Whichever is at the top of the list as the one you want to finish most is the one you stick with. You tell yourself that no matter what happens, you will not work on another project until you finish the #1 priority.

And if you get an amazing new idea, bad luck! That new idea is shelved and maybe it can be the NEXT "#1 priority", but you can't touch it until you have finished the current project. Also, surround yourself with things that get you excited and motivated about your current project... This might be music that you imagine will feature in the game or the trailer for the game, or posters in your room of games that inspired you to make yours.. Stuff like that.

Oh and one more tip for getting things done.. Right click your current connection.. "Disconnect". Good luck!