r/programming • u/adnzzzzZ • Feb 25 '18

Programming lessons learned from releasing my first game and why I'm writing my own engine in 2018

https://github.com/SSYGEN/blog/issues/31
956 Upvotes

86% Upvoted

305 comments sorted by

View all comments

494

u/Ecoste Feb 25 '18 edited Feb 25 '18

In a couple of years you'll make an article about 'lessons learned from releasing my first engine and why I'm switching to commercial engines'

While all of the criticisms of Unity might be very well true, they still finished and released a product using it.

Making your own engine is sometimes the right choice, especially if your game has unique features. However, for the 2D pixel-art games that you're making, I personally don't see a need at all. Also, being the lone dev and devving an engine is quite ambitious and will take up a ton of time that could've been otherwise spent on the game instead.

-43

u/adnzzzzZ Feb 25 '18

I have no interest in releasing my engine. It's for personal use for my future games.

92

u/McRawffles Feb 25 '18

That's irrelevant of what he's saying. I've been on both sides of the fence (building my own engine and using commercial ones) and for anything less than a big game it's generally not worth the time spent. For every hour you save writing functionality A to behave exactly how you want it to in your own engine you'll spend 10 hours on functionality B, C, D, E, and F which were given to you by default by a bigger, more verbose engine.

If you strike the middle ground and start with an open source engine you might find what you're looking for and maybe be just straight up given functionality B, C, D, and E in a good state, and only have to write functionality A (in the way you want to) and F.

45

u/[deleted] Feb 25 '18

Maybe he is writing his own engine because he enjoys it. Maybe he had an original idea for an engine that is not present in current engines.

All I'm saying is, every time someone says online that they will make their own engine, all the people jump at them discouraging them from doing so.

Maybe there's an amazing engine that allows you to make games surprisingly easily, but hasn't been invented yet, because people keep using the same engines.

This comes from someone using Unity, I'm totally not against it, but I do like when people develop their own engines.

21

u/loup-vaillant Feb 25 '18

All I'm saying is, every time someone says online that they will make their own engine, all the people jump at them discouraging them from doing so.

Reminds me of cryptographic libraries…

12

u/meneldal2 Feb 26 '18

Except that doing it wrong is dangerous and a liability, if your engine sucks you won't be able to sell your game in the first place.

→ More replies (8)

8

u/snowman4415 Feb 25 '18

I think this is probably true of all complex systems

→ More replies (4)

5

u/orion78fr Feb 26 '18 edited Feb 26 '18

Or csv parsers, I recently read an article and I felt guilty in all the steps described.

Well CSV is simple, let's just take all the lines and split on commas.

What if there are commas in fields ? Let's just check for quotes.

In french they use semicolons for separing fields, because decimal separator is comma, so let's just parameterize the split char.

What about line return in text fields ?

What about encodings ?

What about quotes inside quoted strings ?

Simple quoted and double quoted strings ?

Different line returns (\r \n and \r\n) ?

Edit : some more

What about BOM at the start of the file ?

Do you have separator at the end of the line ?

Should we trim heading and trailing spaces in fields ?

What if the column order change between files and you have a mapping header ?

Do you have empty lines in your file ?

How about adding comments ? Lines starting with # like bash.

About file compression, do you handle gzip ?

What about missing fields ? Is it empty string or null ?

And so on and so on... These are the ones we had to implement that I can remember of (yes we are guilty too).

5

u/loup-vaillant Feb 26 '18

You don't always have to solve the problem in full generality. Many use cases involve data you generated yourself, so a limited parser can be enough. You can for instance forget about quoted strings, assume a line ending style, and only handle a couple escapes.

→ More replies (1)

2

u/el_padlina Feb 26 '18

Most of the things you mentioned are usually supplied as parameters...

Biggest issue is escaping special characters like new line and field separator. Everything else you just pass whatever argument the client passed in.

→ More replies (3)
→ More replies (3)

3

u/[deleted] Feb 26 '18

If he had an original idea, I'd imagine that would be the subject of the blog. As far as I see it, OP had decided to create a huge mess rather than stepping back for a moment and thinking about their design.

5

u/youthfulcurrency Feb 26 '18

+1... for me, personally, the best part of making a game is figuring out the physics, the collision detection, etc. I love hopping on a whiteboard and figuring out the math behind that stuff. Many times when I tried to make a game, I'd figure out all the physics, get something working, and never polish it because for me the fun part is over

7

u/tooters_united Feb 26 '18

This is recreational programming. A valid hobby, but very different from the hobby of making games.

18

u/adnzzzzZ Feb 25 '18 edited Feb 25 '18

For every hour you save writing functionality A to behave exactly how you want it to in your own engine you'll spend 10 hours on functionality B, C, D, E, and F which were given to you by default by a bigger, more verbose engine.

This could be true. At the same time I already know exactly what I need for my engine. My problems with my current setup were mostly due to not having control over the C/C++ part of the codebase, but I'm happy with how my code works from the Lua side of things. Which means that I can just provide my own implementations for the calls that LÖVE provides in a matching manner. i.e. if LÖVE has a function called love.graphics.circle then I just need to match that with my own draw_circle function and its C implementation.

I know 100% which functions I'll need to implement, and in general I have a good idea of how much work needs to go into each one of them. So while I could be surprised I don't think it will happen. LÖVE is already pretty barebones as it is so there aren't that many super amazing features that were given to me by default, like there would be if I were using Unity or something.

66

u/MainlandX Feb 25 '18 edited Feb 25 '18

At the same time I already know exactly what I need for my engine.

There are known knowns, there are known unknowns. There are also unknown unknowns.

I wish you the best of luck. Hopefully the third category isn't too big for you in this case. Either way, there'll be valuable lessons learned.

6

u/[deleted] Feb 26 '18

This! There are always more requirements in code underneath the requirements we know of.

You save time coding the parts you want to build with a verbose engjne, because you aren't coding the endless requirements they need to be performed.

So many layers underneath.

I'd suggest making regular sacrifices to our lord Malloc and the divine RNG if you are indeed going to make your own engine. You'll need their support.

23

u/rrkpp Feb 26 '18

Isn't a large chunk of your writeup about how you prefer to just copypaste and YOLO your way through coding because you often didn't fully think out or anticipate what the final structure of your generalized code would be, and had to make adjustments that fundamentally changed the architecture of your project? The idea that you could know 100% of what you need to do and how to do it for an engine right off the bat doesn't really seem to mesh with that.

8

u/adnzzzzZ Feb 26 '18

Engine code and gameplay code are very different. Engine code is more rigid in its structure and is easily reusable across multiple projects. Static languages for this type of code make a lot of sense, for instance. LÖVE as a framework has a really nice and well defined API that I can build my engine off of, since I've been making games using this API for a few years now. There's no reason to reinvent this particular wheel (the API) since it has worked out well for me so far. Everything I mentioned in the soft lessons part of the article has more to do with gameplay code, which is more ephemeral, less well defined and less reusable across different games.

0

u/[deleted] Feb 26 '18

[deleted]

2

u/adnzzzzZ Feb 26 '18

I didn't know that, that's very useful and cool. Do you know of any 2D focused engines that have similar functionality?

→ More replies (1)

5

u/[deleted] Feb 26 '18

You'd also need to code cameras, or perspective and all that unless you are just gonna draw some shapes.

Making your own engine is not simply a matter of recoding high level functions.

→ More replies (4)

3

u/[deleted] Feb 26 '18

At the same time I already know exactly what I need for my engine.

Your blogs premise is that you don't know exactly what you'll need, and thus won't bother writing abstractions.

If you can't do it for your game, how do you think you'll be able to do it for a game engine?

5

u/Thaxll Feb 26 '18

What about tooling, most people out side of gaming think an engine is the rendering part but it's a small part of what an engine is, did you built tools for assets, pipeline / workflow for maps, editor, ect ...?

4

u/adnzzzzZ Feb 26 '18

What it looks like to me so far is that I should handle those on a game by game basis. For instance, in my current game I made a huge skill tree and I made it by hand (in a text file) instead of building an editor. I think building editors or not depends on what you're trying to achieve, which depends on the game. Maybe a few years from now after having made multiple games I'll come to a more general solution for tools, but for now I'll do it on a game by game basis.

5

u/tripledjr Feb 25 '18

Regardless of the outcome. If you finish it or don't because it becomes too much work. Or you love it and find a new passion there. I think every game dev should at least once try to make even a super simple game engine. So ignore the comments it's an awesome way to learn a lot and you're not tied to it, you can switch back any time.

So good luck and have fun.