next »

[Dr. Cooldude]

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!

respect++;

[impulse9]

ever wondered how floating point division really works?

Yes, I am familiar with IEE754.

A buddy of mine studied VLSI.  Ever done that?

Nope.

Then stop feeling superior.

I have no idea why you're attacking me here. I never said I am in any way superior, netiher did I imply it. I am as humble as a lamb. Or do you think having an inqusitive mind immediately implies superiority? Maybe you have a bit of inferiority complex yourself? Sorry but I really don't understand what you're getting at here.

Have you ever made a game?

Yes.

was it fun?

Not really.

What did you do wrong?

I had too little experience. I did everything wrong.

Programming is easy

No it's not. That's like saying kickboxing is easy. Sure it is, once you've been kickboxing for 10 years 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.

Ok. I want to make all that, but using a custom engine as well. Why? Because it's fun, I learn a lot in the process and I end up with something I can reuse.

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.

Again with the superiority crap. Why do you feel that the question of superiority is of any importance in the real world? News flash: it's just your ego! And ego usually doesn't help at all. What counts is hard and honest work. Again, I'm as humble as I can possibly be. But this doesn't mean that I'm not inquisitive. I am, and have always been, curious about every little aspect of reality. If you have a problem with that I suggest you tune down your attitude a bit, because it comes off as pretentious and ignorant.

You spent 2 years working on a game, was it any fun?

I spent less and I already answered that it wasn't.

Did others thinks so?

I generally don't care what other people think, especially if it's a rude attack on my personality. There is no use in that. Be constructive and think critically, otherwise I have no use for your opinions.

Any other questions, nosy?

[Xienen]

Before this turns into a back and forth flamewar between you two, let's remember that this thread belongs to someone else.  I know impulse9 did not deserve the attack, as he never stated any sort of superiority.  We should all agree that different indie game developers like to do things differently.  Some of us just want to make engines(very few of us, honestly), some of use just want to make games, and some of us want to make both.  We can argue about why we go whichever route we want to go, but it honestly doesn't frickin matter...we're all doing what we want to do and no one else has to understand that.  I think the "do you want to make engines or games(or both)?" is a perfectly valid question to pose to other developers, because it is a critical question that we all must ask ourselves.  At the same time, it shouldn't be thrown at people with the assumption of getting a "GAMES!" response, which is obviously how it is used around here by some. Some of us like to write engines and some of us like to write both engines and games.  We are not trying to be superior or say "we can make a better engine than anything that exists", but rather "we want to understand every aspect of our code base that we can" or "we want to see how all of this stuff under the hood really works" or "we believe we can make a solid engine for our game and learn some new stuff while we're at it".

There is NOTHING wrong with either approach to game development, as long as we're all doing what we love

Back to the actual thread, obviously the OP has stated that he's more interested in developing games than a generic engine.  He still wants to write it all himself, but not necessarily architect it in such a way that it could be used for any project.  Let's all respect that and let him start working on his game from the ground up(reusing some of his existing code).

[impulse9]

I agree. Everyone should do whatever the hell they feel like doing. 

[Richard Kain]

I personally find that working on an engine is great for learning, while working on a game using some else's engine is great for actually producing a game. I spent a few months trying to port Flixel to a different platform. The end result didn't turn out to be terribly useful, but it was a fantastic learning experience where I found out how the guts of a capable engine work. Even though there weren't any major results from that effort, I don't consider it to be a waste.

Sometimes starting over is the right approach. If your underlying structure just isn't right for what you're trying to achieve, it is sometimes advisable to burn it down and start from scratch. I've done this several times on multiple projects. It's a matter of weighing the time cost of starting over with the inefficiencies of continuing from where you're at. If starting over will result in massive time savings down the line thanks to a better core, it's probably worth it. If the only savings are going to be some minor details, or a feature that isn't really vital to the core game experience, than its probably better to soldier on from where you are.

Take a good hard look at where you are, where you want to end up, and what is really vital for your game. Then make the call you think is best.

[CowBoyDan]

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

^ superiority thing I was referring to, just to clarify.  That's all, do what you want.

[impulse9]

I was not implying superiority, I'm sorry if it came out like that.

[CowBoyDan]

I was not implying superiority, I'm sorry if it came out like that.

Sorry I was touchy. It wasn't aimed at you specifically.  Shake?

[impulse9]

Sure.

[enthrallstudios]

So, in the past 3 days, I have been coding like crazy. I can happily say that so far I have a much better product. I'm nearly to the same place I was before. I even have some other features like, full configuration saving/loading with support for setting/saving control schemes for Keyboard and Gamepads.

Just to clarify something, when I said, "I don't want to make engines, I want to make games." By "Engine" I meant a suite of tools and a codebase that are meant to allow the creation of a genre of games using said tools + API. I am still writing the core code of my game myself, it's just focused on a single game, rather than being a general "one size fits all" application.

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.

That's exactly what I am doing. My code regarding OpenGL has been particularly re-usable, as will 90% of my physics engine.

[racter]

I really like Fred Brooks' idea of the unavoidable "pilot system," which I think is relevant here:

In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.

Engineering something new can be a process of discovery and a kind of research. Software engineering is really complicated, and it's often impossible to deeply understand a problem domain before diving in and building a first-draft solution.

[Klaim]

Also, beware of the "second system" problem.

People who have designed something only once before, try to do all the things they "did not get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.

Source: http://en.wikipedia.org/wiki/Second-system_effect

[Graham-]

I don't really throw away large things. I just iterate pieces.

OP, sounds like your issue is solved, but for the theory.... I "deprecate" bad code. Then the second I want functionality that serves me in a better way than the original code, I duplicate it. I duplicate engine code. Then newer code can call the bad code or the rewritten code. Slowly I migrate over to a rewritten system.

A lot more is preserved this way.

[enthrallstudios]

Also, beware of the "second system" problem.

People who have designed something only once before, try to do all the things they "did not get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.

Source: http://en.wikipedia.org/wiki/Second-system_effect

What exactly do you mean by something I "did not get to do last time"? Are you talking about a form of feature creep that is present when creating a second iteration? My features are directly related to my design, and to be completely honest, I have less features than I had in mind at first, simply because I would rather have 3 great features/mechanics than have 50 mediocre features/mechanics. That being said, I'll look out for it. The purpose of this re-write is to simplify everything I am doing, not over-complicate it.

[Klaim]

I can't remember the different books that talk about it but basically the problem is like this:

 1. you do something for the first time: it's very unperfect but it mostly works;
 2. then you start working on a big new version of this thing, from almost from scratch, by relying on the tons of problems your previous version made you discover: you have high chances of "doing too much", by adding too much (whatever you add), and over-think some parts (that's where YAGNI helps a lot).
 3. either the last version was finished or you couldn't finish it because it was too big/over-engineered/hard-to-understand/buggy. Whatever, now you have explored both the simplist and the complicated way of doing it. You have far more chances to get it right, by doing what is necessary, by forgetting what might be useful but isn't proven to be yet, and by making things as simple as possible but not simplist.

Which suggests that all new things you builts are starting to be good only after the 3rd try. Which is one reason to make as much prototypes as you can to check new things. Which is also the reasons why it's important to go in an iterative way, where each iteration refactor/rewrite only one part of the whole. Which suggest that good encapsulation is key. Which also suggest that you'll get back to old code regularly, which imply that you should make the code simple to read, even when what you are doing might be complex on a large scale, it should be simple if you focus on different parts of it.


Feature creep is just one specific kind of stuffs that can happen in the second system (and with others too). The point to get is that the second time you do it, you might over-do it, putting too much effort for something that isnt' worth so much.

That's also why graphic people tends to put too much energy in details when they get to draw better than average people, and why very experienced drawers will draw simple line that are just straight to the point.

That's also why music composition by people not experimented enough will be made of tons of musical sounds not exploiting enough the relationship between sound and silence.


BRAIN ERROR : Pattern Stack Overflow...




When you know about this "problem" (most of the time because it happened to you in different domains where you were new or trying to do something new), then you make everything you can to quickly pass the first times of learning that thing.

[Graham-]

Fail fast and hard, then iterate.

[enthrallstudios]

I see what you are saying. Oddly enough, my first try was my over-complicated approach.I would write a small test application for each new feature, and once I had it working, I would add it to my large code-base. So technically, this is my third time re-writing all of this. I just got a point where I realized that 2 goals were conflicting and causing my code to get worse, and me to get stressed. I decided that making my game was more important than worrying about a component-based game engine.

[Graham-]

Well it's generally better to build your engine as your game demands it, unless you're building an engine for a feature set you know you will need - you obviously weren't doing that.

[enthrallstudios]

@Graham
That's precisely what happened. I was trying to write an engine that could be reused for multiple projects, and I just decided to go all out and do things I have never done before. I can definitely say I learned a ridiculous amount from the project. In the end, I just found the time-sink to be too much, and I just wanted to get my game finished. That is where the project fell short. I don't think I wasted my time simply because of how much I learned, but it definitely wasn't the correct path in regards to finishing a game in a reasonable amount of time.

[Graham-]

Yeah these kind of things are learning opportunities. I'm not saying they aren't valuable in that way. (done it many times... too many...)