Jump to content
  • Advertisement
DaTueOwner

Anyone who wants to write a little game engine?

Recommended Posts

2 minutes ago, Oberon_Command said:

just find a way to detect the jittering and then disable the ragdoll code for that body. :P

Thoughts of gamer:

Yeah, that's what you gamedevs do all the time. But i spot it! I want to be able to stack a pile dead ragdolls above each other, so i can climb up and pick up the shiny power up rotating there above. It would be so satisfying... i would feel so clever... But i can't do it. Because you lazy gamedevs just turn off ragdoll to hide you are unable to do proper physics. Now i can walk through the dead body as if it would not exist... lousy fakes. Decades ago you promised us physics would revolutionize games. But we never saw something batter after HL2, all you guys have learned is to turn physics OFF, but never to turn it ON.  ...better going watching a movie now... ;P

 

13 minutes ago, Oberon_Command said:

I don't know. I had a lot of fun messing around in Goat Simulator, but maybe that's the exception that proves the rule here.

Ha, i wanted to mention Goat Sim too. Yes it was fun but it also is really a good example of terrible physics in games. Because the player IS free to have fun with physics, glitches happen all the time. Even this game is about nonsense, it glitches too much to KEEP being fun for longer than a minute. Trying to do something interesting always ends up in jitter, collapsing, tunneling or whatever.

Probably i'm more triggered here than the average gamer, but i know we could do better.

It's not that i disagree with your arguments, but there are options not explored yet. We should go there :)

 

Share this post


Link to post
Share on other sites
Advertisement
1 hour ago, JoeJ said:

I want to be able to stack a pile dead ragdolls above each other, so i can climb up and pick up the shiny power up rotating there above.

That isn't usually the intended gameplay experience. Designers and programmers have enough on their plate already without trying to support this kind of thing. ;)

1 hour ago, JoeJ said:

Yes it was fun but it also is really a good example of terrible physics in games. Because the player IS free to have fun with physics, glitches happen all the time. Even this game is about nonsense, it glitches too much to KEEP being fun for longer than a minute. Trying to do something interesting always ends up in jitter, collapsing, tunneling or whatever.

But the physics glitches are the whole point of Goat Simulator! Every other game tries to polish that stuff away; Goat Simulator revels in the glitches. It's a parody of a game; it's supposed to be terrible, but in a funny way. "So bad that it's good." Those glitches are clearly amusing enough to keep a non-trivial amount of people entertained, or the game wouldn't be as popular as it was.

The whole time I was playing Goat Simulator I was trying to break the physics. Especially with that absurdly long tongue... I think I was having the most fun when I was trying to stick my tongue to the car or the hang glider. Or watching the animations freak out when I blew up the gas station. The most disappointing things in Goat Simulator for me were the parts that didn't overreact and break.

Edited by Oberon_Command

Share this post


Link to post
Share on other sites
3 minutes ago, Oberon_Command said:

That isn't usually the intended gameplay experience. Designers and programmers have enough on their plate already without trying to support this kind of thing. ;)

I admit stacking corpses tasteless example, but i remember such a situation in HL2: I stacked some boxes, got on a higher platform this way and from above it was very easy to manage an otherwise difficult situation with many enemies. I remember this moment the most about the game. It really was satisfying - and that's what games want to deliver. Surely it was not planned by the devs, but this way the game not only kept working within its designed illusion, it broke out of this. It became more than just a scripted, pre-animated show for puppets, and i felt agile and rich in options.

Back then the option to stack boxes was something new for a FPS game - nowadays this would no longer work so easy. It works best with new elements, and it becomes harder to come up with new ideas. But you have to agree we did not see much (or any) progress with physics since then (rare exceptions). In this case it is not a lack of ideas, it is a lack of progress tech wise. And as a gamer i would classify your quoted comment as a bad excuse. Similar to 'games are so expensive now, we can not risk to do anything different than our proven success formula'. For long i thought such critique isn't justified - games are hard work and gamers know nothing about it, they expect too much, etc. But i'm at the point of changing my mind here. I don't think we can ignore their growing dissatisfaction for longer. Sadly they don't tell us what they want (only what they don't want), so we have to come up with something. Relying on next awesome GPU or console gen to push details is no longer enough. Better physics can help to create believable worlds, more rich in options, less restricting... closer to our vision of a virtual space of adventure and fun. (IMHO this better tech already exists - free and open source, just nobody cares)

In this context... keep working on custom engines renderers / simulators / whatever... you might come up with something new! :)

 

Interesting your experience with goat glitches was just the opposite than mine. Seems i'm just too picky about physics to be no spoilsport here :)

Share this post


Link to post
Share on other sites
7 hours ago, DaTueOwner said:

What about rust?

Rust trying to prevent opportunity to Intentionally shoot you leg by cutting of all legs and hands. As mentioned before standart library good for about any use-cases for cost that it is best for about nothing. It why anything like memory managment containers and so on in C++ live as library - it make no difficulties with replacing it by components that match requirments of task best. Rust putting same that STL do under hood, making difficulties with replacing components and nothing else. For example what difference betwin borrowing and move symantic? But what you will do with rust when you need a copy-on-write  symantic or self-deletion of objects?

Also rust dont support OOP that making it concepts outdated for at least  40 years. Really looks like people that invent rust just has not understend basics concepts of C++.

Share this post


Link to post
Share on other sites
8 hours ago, DaTueOwner said:

Also I think you can get away with managed languages like C# just fine if you don't intend to create an AAA tier engine.

C# have outdated memory managment that not applicable for realtime software. Also it unable to make static allocation of object and have no tools to implement automatic object lifetime managment. And it applicable to any managed language - it have outdated and useless GC, that required to no more then 0.001% of modern managment tasks, unlike task of plain chained buffers managment for wich it has been invented at 1959. Anything else works much better without GC and also GC prevent implementation of automatic memory managment schemes for modern graphs of links, like mix of composite and observer pattern, where objects without trace to root is impossible at all, and objects have to be deleted when it lost specified trace to root regardless of quantity of other existing traces. So really GC languages solve problens that never exists  making tons of problems as cost of it solution.

C# is not a "C++++" and not related to C at all. It just a Java++ intended to extend abilities of Java for visual development of GUI, and it almost fail to fit it task. First project for wich Microsoft has try to use C# was a C# Builder that thay has try to implement together with Borland. Results has so trimmed, in comparsion with Delphi and C++ Builder, so Borland  has refused to relase it and gift it to Microsoft together with Hailsberg. Delphi.Net that has been developed as side effect of C# builder ptoject, same has been so trimmed, so has been reased only once. Similar failure was with C++.Net. IT becouse GC not intended for modern memory managment tasks.

Really C++ is a first OOP language that eliminated outdated and useless for OOP GC. And still only language that make it efficiently - results allow to use much faster and much flexible automatucs that can be easily ajusted to fit needs of any hierarhy best.

Edited by Fulcrum.013

Share this post


Link to post
Share on other sites

I agree with the advice to work on the engine on your own. If it's for learning, then doing it on your own is the way to go. Create a document that details the entire scope of the project and only expand on that scope if another item in the design needs it to be completed.

For beginner level development projects, I don't think that's the most efficient use of your time. Obviously you might be different than most, but from developers I know and me making the same choice early on, you'll be wasting your time while other developers will be passing you by. If/when you get the project done, you'll have gained some in depth skills, that are highly specialized. That's not bad in itself, I suppose it depends on your goals. However, if you take on making games using already developed engines, make a few games, and then develop your own engine, then you'll not only have a better grasp of development in general, you'll also have a much better idea about you want out of a game engine.

I mean, you don't want someone who's never worked on a car to design a car engine do you? Even as a learning experiment, a person would be much more efficient by working on some cars and then designing and making an engine, than a person just jumping right in to making an engine.

tl;dr: It is a good learning experience, but making a few games with other engines first will probably work out better in the long run.

 

Also, I wanted to say, try not to worry too much about languages unless you are going for optimum performance. C# is just fine. I don't know about Rust, I never developed anything in that. C++ is great, but try not to take people touting it as the only option too seriously. You'll find problems with any language you choose, as well as benefits. Just pick one and run with it for the project. If you want, you can try a different language for your next project.

Share this post


Link to post
Share on other sites
43 minutes ago, DavinCreed said:

C++ is great, but try not to take people touting it as the only option too seriously.

For realtime software managed languages is not a option at all by definition of realtime. For video games, that is kind of "soft" realtime software (where "soft" only mean that malfunction of software will not cause a disaster, but not change any requirments to keep it in working condition), other native language that good for realtime, obviuosly not a option too, becouse it intended to other niche like ADA(for FA realtime most importent thing is to process device interrupts and timers at time with given priority, unlike games ) or too outdated to productively developt such complexive software as game engine  like Pascal/Delphi/Fortran/C.

Edited by Fulcrum.013

Share this post


Link to post
Share on other sites
1 minute ago, Fulcrum.013 said:

For realtime software managed languages is not a option at all by definition of realtime. For video games, that is kind of "soft" realtime software (where "soft" only mean that malfunction of software will not cause a disaster, but not change any requirments to keep it in working condition), other native language that good for realtime, obviuosly not a option too, becouse it intended to other niche (for FA realtime most importent thing is to process device interrupts and timers at time with given priority, unlike games ) or outdated.

I am sorry, I cannot determine what you're trying to say.

I've developed real time games in C++. While it is time consuming at times to develop safe software in C++, it's very possible to prevent run time errors in C++ from coming up and/or crashing the application. And if you follow OOP principles well enough, you don't have to worry much about requirement changes either.

Share this post


Link to post
Share on other sites
16 minutes ago, DavinCreed said:

I am sorry, I cannot determine what you're trying to say.

In short - i trying to argue why C++ is only option to productively developt a quality and reliable game engine. 

16 minutes ago, DavinCreed said:

While it is time consuming at times to develop safe software in C++,

Really in many cases it much faster to do, than using a managed languages. For example fact that memory leaks really exists on practicle, not in theory only, a has know from guys that use managed languages and expirience a indirect memory leaks problems wery often. 

 

16 minutes ago, DavinCreed said:

And if you follow OOP principles well enough, you don't have to worry much about requirement changes either

Of cource. Make once a 2-way smart-poiner system (that can fit at 250 lines of code) and never worry about how to remove object from model and dead references, or to keep temporaty memory leaks, that managed languages offer as protrction from dead references, temporary.

Edited by Fulcrum.013

Share this post


Link to post
Share on other sites
15 minutes ago, Fulcrum.013 said:

In short - i trying to argue why C++ is only option to productively developt a quality and reliable game engine. 

Then I disagree with you. It's not the only option. And this kind of attitude leads to perfection petrification.

From the details laid out by the one seeking advice here, any language would be a great learning experience for them.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!