next »

[enthrallstudios]

Hey Guys,
So, about a year ago I began working on my current project, which is also my most-complex project in relation to gaming. It started out as a component-based 2D game engine, simply because I wanted to learn about component-based systems worked, and I really wanted to try my hand at it.

Now, I look at my code, and I realize that I have started to add very game-specific code this last month, because I have been developing a game idea in the background for about 2 years and I'm finally ready to focus on that. In all honesty, I see the component-based system as an obstacle because those systems work awesomely with a complex interface, and using said interface to develop a game from the ground up without too much access to the back end. At the same time, I have a test-bed that I have been using to test new things.

In this test bed it took me 24 hours to get a working physics system going, and it took be about 2 weeks to get that same system integrated into my component-based system for multiple reasons.

I am thinking about restarting and focusing on getting a single game done, and not worrying about scaling the engine to larger projects since I want to get the game done in a timely manner. What do you guys think? In all honesty, this past year has taught me a TREMENDOUS amount, but I think I could finish this game much faster with a simpler architecture, and my component-based engine should definitely be re-written at a later date, using what I have learned.

[impulse9]

The problem with restarting projects is that by the time you'll have a codebase of comparative size, you'll start feeling the same way about it because you will learn new things in the process. Be careful not to fall into this vicious circle. It's better to finish something than try to make every bit of it perfect by iterating the whole process endlessly.

[enthrallstudios]

While I completely agree understand your point. I have almost 8000 lines of code, and I don't even have colored boxes with complete physics.

I have a little testbed that I get this stuff working in SO much faster. Also, the code will need to be rewritten in some places regardless for proper error-handling. I wouldn't give this a thought unless I saw a huge efficiency reward.

[CowBoyDan]

Do you want to make games or engines?

[enthrallstudios]

@CowboyDan

That is exactly my point. It started as an engine, but the game itself is more important to me. That is why I think I should start over, especially with the knowledge I have now. I know that in under a month, I can get my game to a farther point than it is currently with this codebase.

[zalzane]

what language are you using? (this is a lot more important than one might assume)

[Xienen]

I'm assuming you haven't created a solid toolset, which is causing your component based design to slow your progress this much. I would echo some of the concerns stated earlier, however, as its often better to stick with what you've got than to trash it and start all over again. It may not be perfect or even good, but completely replacing it will probably take a lot longer than you think. At least that was the case with our game, Break Blocks.

[enthrallstudios]

Been working with C++. You're right that I haven't built the toolset yet. In all honesty though, a full built-out and generalized toolset won't help me all that much. My plan was to write a simple in-game level-editor for me to use, and for players to use as well. I could completely finish the TOOLS that go along with my engine in about a year at the pace that I have been going. One thing to take into account is that a lot of the code I have written can be re-used, but I will just need to take out some portions that really muddle it up and add in time that I don't want to spend at the moment.

I'll make this promise, I'll re-architect my game tonight, and start writing the code tomorrow.  If in 2 weeks I do not have at LEAST the same functionality that I have now, I will re-think this decision.

[CowBoyDan]

When I was younger I went the route of writing a game/engine together in C++.  Spent about 2 years working on it and it still wasn't a game yet.  You could play with the mechanics, the gui was there.  But no ai, no objectives, etc, eventually the project fell apart (I worked with others for some of the assets, mostly models and music).  Today using unity (or another game engine of your choice), I could have reached the same point in about 4 weeks.  (wouldn't be fair to estimate completion since I have no idea how much "game" was left to code).  In roughly the same time span as that game I've made a complete game with 20 levels, 2 android apps (non game), and several small games.  All games were in unity.

Tools like today weren't as available 8 years ago when I was doing my failed game though.

[enthrallstudios]

I agree that the engine approach isn't the best choice right now, even though it was a great learning experience. In all honesty though, I am not a fan of using Unity for 2D games at all. I generally have to rig up some unsatisfactory physics solution. My original reason was that it had no Linux support which means a lot to me. I like to support the community, and I prefer to do my development in a linux environment. I would definitely consider Unity for a mobile game, or for a simple 3D game though.

Using the right APIs you can get up and running very quickly in C++. SFML + OpenGL + Lua is a pretty powerful combo, and is where I plan to stay. Not only is it where I am most comfortable, but I don't have to learn a new API and fiddle with someone else's tools which can take a long time to get accustomed to. Also, I see becoming better with OpenGL/DirectX as more useful than learning a proprietary toolset, but that is just my personal opinion.

[CowBoyDan]

Try JMonkeyEngine or others that are open source.  I'm not big on 2D so I'm not terribly familiar with whats good for that.  You say get up and running very quickly.  Like 48 hours from idea to playable prototype/concept?  Everything I have made in unity came from an idea I fiddled with in the course of ONE day. 

[Wilson Saunders]

Before you start on a new project write up a list of files and functions you think you can reuse from your last one. It will give you a sense of closure and save you from looking through 20 classes to find the one you did a particularly tricky bit of code in. My first few attempts at making a game were only valuable as a learning experience. However I did reuse some of the basic classes like Point.h in other projects.

[Muz]

http://www.joelonsoftware.com/articles/fog0000000069.html

That is, never restart if you can fix it at all. Old code is tried, tested, and debugged. New code is always buggy. Sometimes old code is a little buggy, but not as buggy as fresh code. If you can, reuse whatever code you can (this is why functions and OO programming are awesome).

I've gone through the whole phase of learning new things and wanting to restart things from scratch. It's a bad idea. My rule of thumb is that once you get started on a game with an engine, finish it. If you want to start over anew, do it for the sequel.

[enthrallstudios]

The good part is that a large majority of it can be reused, but the general architecture has to be re-done because I am trying to simplify it. If I had a beautiful, stable codebase, I wouldn't stop, but most of the code that im kicking to the curb will need rewriting just for stability purposes. It is in no way the best solution. I see it as this mess that I made whilst learning TONS of new idea, and now that I have learned everything it's time to get a solid, stable build going.

[Chris Koźmik]

Do not restart, do not reuse, just abandon this monster and start making normal games.


And do not overlook this CowBoyDan's quote (and he is not the only one that said it).

Do you want to make games or engines?

I will post it again, because it is important

Do you want to make games or engines?

And once again beacuse that's your major problem

Do you want to make games or engines?

And once more, just to be sure

Do you want to make games or engines?

[enthrallstudios]

@Archibald

I agree, im not looking to rewrite this massive engine. I'm simply writing the game. I just refuse to use Unity for multiple reasons, but im not writing an engine.

[ChevyRay]

Ugh, always hate the "make games not engines" response, it's unhelpful. I make engines all the time, and engine re-writing helps me both solve elegant problems on the fly with my games and also have a good grip on my code. Whenever projects fail, it's almost always because I tried to dive in too deep without having a nicely structured engine in place first.

So the answer is write engines, do it all the time, because it's fun and because the result can be a game anyways, and you'll probably be more happy with it that way.

If you're like me, anyhow.

WRITE ENGINES, NOT GAMES!

[impulse9]

ChevyRay++

Maybe I'm just the type of person who wants to understand things down to the last atom.

[Klaim]

Here is my advice:

It depends on the meaning of "restart".

Let's say you setup a clean empty new project. You start writting the game, not an engine (as already "discussed"). But then, each time you hit a problem that have been resolved, even in a brute-force or simplist way, by the old code base, then you carefully extract it, review it (to make it simple, clear and correct), then inject it in your new project.

This, would be... sane. It takes a lot of time, but at least you can fix the old code bits by bits in a way that don't make you think all the code can't be trusted (like any first big code base looks like, in particular when using C++). It would also allow you to focus on the parts that you really need for the specific game, because you have to extract old code ONLY if you have a need in the game code.

Any other "restart" definition would be a time and motivation killer. Also, might trigger depression and need to stop any coding for the rest of your life.

[CowBoyDan]

ChevyRay++

Maybe I'm just the type of person who wants to understand things down to the last atom.

In college I studied microcode and the construction of assembly languages, ever wondered how floating point division really works?  No you are satisfied that the cpu knows what its doing?  A buddy of mine studied VLSI.  Ever done that?  Then stop feeling superior.  Have you ever made a game?  was it fun?  What did you do wrong?  Programming is easy, I get paid lots of money to do it every day.  But when I make games, I want to make games.  That means art, music, models, mechanics and levels and putting it all together.

I've written games in x86 assembly (college homework actually).  Using C++ and writing your own engine does not make you superior anymore than someone sitting in a coffee shop with a mac book pro sipping lattes is superior.

You spent 2 years working on a game, was it any fun?  Did others thinks so?