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.

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.