Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 13 May 2013 - 08:52 PM

So recently I've been working on building my own Game Engine ... after i finish my engine [I'm thinking] of developing a game off of it, it'll be a Breakout like game, that is a small game that will show what this engine can do.

In my experience, these "engines without games" projects do not go well. The list of things that an engine could do is endless, and the list of ways that you could solve any single one of those things is also endless. On the other hand, a particular game, like Breakout, has a very definite list of requirements.

IMHO, you should always build an engine alongside a game, so that you know exactly which things you should build, and you'll be able to concretely compare different approaches to any problem, by actually testing your engine's features in practice, by building a game that uses them at the same time.

 

I'm also a strong believer in YAGNI, and I've found that if you write some particular feature months in advance, without actually having a need for it yet, then you won't do as good a job of it. With these kinds of game engine projects, the entire project violates YAGNI! I've found that with these kinds of engines, when you finally decide to use them to make a game, you realise that many features don't quite work the way you'd like them to (or are buggy, because they've never been properly tested), and you end up doing a lot of re-work.

 

Also, a game like Breakout doesn't need a very complex engine. If you go and create a really complex engine and then use it to create Breakout, then both your game and your engine will be over-engineered.

It would be best to keep your engine as simple as possible while making Breakout, or to make a more complex game with an existing engine, or, make your own very complex engine but also make a very complex tech-demo to go with it.

 

The best course also depends on what kind of programming you want to do.

A breakout-from-scratch project is a decent project to show that you're a competent programmer in general.

A game with lots of particle systems or post-processing effects might show that you've an affinity for graphics programming.

A game with enemies that take cover and flank the player might show you've an affinity for AI programming.

A game with a GUI level editor might show you've an affinity for tools programming.

A game with a professional data-compilation pipeline might show you've an affinity for engine/tools/build-automation programming.

A game with 10000 enemies on screen at once might show you've an affinity for engine optimisation.

etc...

 

2 - Depends on your country. You likely need to register a business number and do your taxes correctly. Speaking to an accountant would be recommended.

3 - Your English is perfectly fine smile.png


#3Hodgman

Posted 13 May 2013 - 08:51 PM

So recently I've been working on building my own Game Engine ... after i finish my engine [I'm thinking] of developing a game off of it, it'll be a Breakout like game, that is a small game that will show what this engine can do.

In my experience, these "engines without games" projects do not go well. The list of things that an engine could do is endless, and the list of ways that you could solve any single one of those things is also endless. On the other hand, a particular game, like Breakout, has a very definite list of requirements.

IMHO, you should always build an engine alongside a game, so that you know exactly which things you should build, and you'll be able to concretely compare different approaches to any problem, by actually testing your engine's features in practice, by building a game that uses them at the same time.

 

I'm also a strong believer in YAGNI, and I've found that if you write some particular feature months in advance, without actually having a need for it yet, then you won't do as good a job of it. With these kinds of game engine projects, the entire project violates YAGNI! I've found that with these kinds of engines, when you finally decide to use them to make a game, you realise that many features don't quite work the way you'd like them to (or are buggy, because they've never been properly tested), and you end up doing a lot of re-work.

 

Also, a game like Breakout doesn't need a very complex engine. If you go and create a really complex engine and then use it to create Breakout, then both your game and your engine will be over-engineered.

It would be best to keep your engine as simple as possible while making Breakout, or to make a more complex game with an existing engine, or, make your own very complex engine but also make a very complex tech-demo to go with it.

 

The best course also depends on what kind of programming you want to do.

A breakout-from-scratch project is a decent project to show that you're a competent programmer in general.

A game with lots of particle systems or post-processing effects might show that you've an affinity for graphics programming.

A game with enemies that take cover and flank the player might show you've an affinity for AI programming.

A game with a GUI level editor might show you've an affinity for tools programming.

A game with a professional data-compilation pipeline might show you've an affinity for engine/tools/build-automation programming.

A game with 10000 enemies on screen at once might show you've an affinity for engine optimisation.

etc...

 

2 - Depends on your country. You likely need to register a business number and do your taxes correctly.

3 - Your English is perfectly fine smile.png


#2Hodgman

Posted 13 May 2013 - 08:46 PM

So recently I've been working on building my own Game Engine ... after i finish my engine [I'm thinking] of developing a game off of it, it'll be a Breakout like game, that is a small game that will show what this engine can do.

In my experience, these "engines without games" projects do not go well. The list of things that an engine could do is endless, and the list of ways that you could solve any single one of those things is also endless. On the other hand, a particular game, like Breakout, has a very definite list of requirements.

IMHO, you should always build an engine alongside a game, so that you know exactly which things you should build, and you'll be able to concretely compare different approaches to any problem, by actually testing your engine's features in practice, by building a game that uses them at the same time.

 

I'm also a strong believer in YAGNI, and I've found that if you write some particular feature months in advance, without actually having a need for it yet, then you won't do as good a job of it. With these kinds of game engine projects, the entire project violates YAGNI! I've found that with these kinds of engines, when you finally decide to use them to make a game, you realise that many features don't quite work the way you'd like them to (or are buggy, because they've never been properly tested), and you end up doing a lot of re-work.

 

Also, a game like Breakout doesn't need a very complex engine. If you go and create a really complex engine and then use it to create Breakout, then both your game and your engine will be over-engineered.

It would be best to keep your engine as simple as possible while making Breakout, or to make a more complex game with an existing engine, or, make your own very complex engine but also make a very complex tech-demo to go with it.

 

2 - Depends on your country. You likely need to register a business number and do your taxes correctly.

3 - Your English is perfectly fine :)


#1Hodgman

Posted 13 May 2013 - 08:42 PM

So recently I've been working on building my own Game Engine ... after i finish my engine of developing a game off of it, it'll be a Breakout like game, that is a small game that will show what this engine can do.

In my experience, these "engines without games" projects do not go well. The list of things that an engine could do is endless, and the list of ways that you could solve any single one of those things is also endless. On the other hand, a particular game, like Breakout, has a very definite list of requirements.

IMHO, you should always build an engine alongside a game, so that you know exactly which things you should build, and you'll be able to concretely compare different approaches to any problem, by actually testing your engine's features in practice, by building a game that uses them at the same time.

 

I'm also a strong believer in YAGNI, and I've found that if you write some particular feature months in advance, without actually having a need for it yet, then you won't do as good a job of it. With these kinds of game engine projects, the entire project violates YAGNI! I've found that with these kinds of engines, when you finally decide to use them to make a game, you realise that many features don't quite work the way you'd like them to (or are buggy, because they've never been properly tested), and you end up doing a lot of re-work.

 

Also, a game like Breakout doesn't need a very complex engine. If you go and create a really complex engine and then use it to create Breakout, then both your game and your engine will be over-engineered.

It would be best to keep your engine as simple as possible while making Breakout, or to make a more complex game with an existing engine, or, make your own very complex engine but also make a very complex tech-demo to go with it.


PARTNERS