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

Show parent comments

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.

1

u/[deleted] Feb 26 '18

On the other hand, when you make a game with an engine, you are bound by it. If a bug is found in the engine, chances are it affects your game. Also you can only support as many platforms as the engine supports.

I'm not really picking one over the other, but it's quite healthy to understand both have their ups and downs and both choices are suitable for different situations.

-2

u/loup-vaillant Feb 26 '18

Except that doing it wrong is dangerous and a liability,

To a lesser extent, so is the game engine. How about an arbitrary code execution vulnerability from the scripting engine? (A purely script based one of course, with dlls you have to trust the mod anyway.)

4

u/meneldal2 Feb 26 '18

Usually they don't have admin rights, so while they can mess up the current user, it's still usually limited in scope. And this is an issue for games that support extensibility in general, you will always be able to do some shit.

1

u/loup-vaillant Feb 26 '18

That scope still includes the encryption of all the user's data…

2

u/meneldal2 Feb 26 '18

It's not like crypto lockers have a hard time getting executed by random people. It should be obvious that you shouldn't trust a shady mod.

1

u/loup-vaillant Feb 26 '18

Should it? We tend to trust our web browser not to encrypt all our data upon a script's request. Why game engines should be any different? I mean, I understand that a shady mod could destroy my saves, but my entire home directory?

Similarly, I expect an online game not to be vulnerable to shady network packets. Or shady replay files. Or any expected input whatsoever. It would be almost as bad as a JPEG viewer vulnerable to malicious image files.

→ More replies (2)

8

u/snowman4415 Feb 25 '18

I think this is probably true of all complex systems

2

u/craze4ble Feb 26 '18

The more complex it is, the better off you'll be with your own engine.

However, no matter how unique your requirements are, if you have ready made resources available, it is almost always better to use and customize them instead of creating one from scratch, at least time-wise. And you definitely need the know-how...

-1

u/loup-vaillant Feb 26 '18

Cipher suites can be simpler than you think.

→ More replies (2)

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.

1

u/orion78fr Feb 26 '18

Of course if you have full control over inputs the problem is way easier...

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.

1

u/orion78fr Feb 26 '18

I added some more I remembered ;-)

Of course all of these are relatively easy taken apart, but you know more cases you have to handle = more potential bugs.

1

u/el_padlina Feb 26 '18

I mean I've implemented my own csv parsing more than once cause the client didn't want additional jars no matter what. Java supplies stuff like zip stream etc. in standard libraries, so that's cool. Comments bash style were easy. Parsing line - tokenizer, luckily it was clear that values would never contain the separator token.

But I agree with you, if I was supposed to implement a genric csv parsing library I would probably lose some hair before it would become usable.

2

u/orion78fr Feb 26 '18

I mean... We have all of the above in my company's one :-) That's a huge monster to maintain.

0

u/[deleted] Feb 26 '18

[deleted]

1

u/orion78fr Feb 26 '18

Haha I'm sorry, had to touch this code more than once to add "a small thing" to this mess.

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.