next »

[Darth_Dan]

Well...
Here goes the question you are probably getting every time from every newcomer. But hopefully it is going to be formulated at least slightly differently.

Do I need to use a game engine? If so, which one?

Trick question. It depends on the game, of course. I have 2 to talk about.

One has not formed itself as a general idea just yet, but there is a proof of concept I would like to make first. It's voxel-based physics sandbox. I wish to use voxel octrees for physics and destructibility. I want to be able to simulate transitions from solid to liquid to gas and all the way back. I know, it sounds very resource consuming for now. My experiment is toprove whether it truly is so and how can that be improved.

And the second (or, more likely, the first) is a large scale 2d (most likely 2d) simulation of a galaxy and strategic space combat. Now this is the one where I'm thinking of not even using any game engine. Just coding. But it is a large one, and I wonder if anyone here has ever done something similar.

Also, I've already seen this beautiful post about engines: https://forums.tigsource.com/index.php?topic=21471.0
It gives me a general idea, but I would still like to hear a more personal experience based opinion. Thank you!

[CodeLobe]

Physics Voxels?  Pretty ambitious, to be honest.  To make it playable you'll have to grossly simplify the sim and/or reduce the size & resolution of your game.  Be prepared for the end result not to work as you expected.  Put on your GPU compute shader hat for best results.  You'll be making your own engine there.  It's probably the only way to make it run fast enough to be playable.  I've been down that route from different directions.  Still there are 3D frameworks to get your engine started.


I'd start with something smaller than a voxel physics simulation if you haven't released a few small games yet.  Spend your first time on something that won't leave you sore.

Large scale 2d (most likely 2d) simulation of a galaxy

Depends on how detailed your simulation needs to be.  The "Processing" engine or other particle-heavy frameworks may be much of what you need.  However, when you throw in "large scale" it typically means you're either using an engine built for making games pretty much like your game (good luck), or you're building your own game engine.  Fortunately it's fairly simple to make a 2D engine these days even with SDL.

Todays huge game worlds have a hard enough time storing and syncing world events, to say nothing of running thermodynamic simulations.  Maybe watch some post-mortems of games with elements you like on https://www.gdcvault.com/ ?

If I were in your shoes, I would cache these brain babies for later.  It's best to work towards the mental offspring you cherish when you have already demonstrated all the skills required to do so (make small games that each have one element of the bigger game, then make bigger game).  If you don't want to quickly tear through some small game concept first, start to finish, sales and all (recommended), then at least start with a very small simulation.  Find out what game you can make in that medium.  You can grow from there.

Essentially, if you want to accomplish your dream, yes you'll probably need an engine for both of those simulations.  If you can settle for something smaller and not quite what you had in mind, then use an engine -- one that is very multi-thread aware or has tools for doing logic in a compute shader (good luck, you'll need it).

Consolation prize: Prototype of a 2D thermodynamic sim with 2 elements (water, and "air"). I used this to benchmark performance of browsers running a thermodynamic or other such sim.
Keys 1-4 changes views: normal, thermal absolute, thermal normalized, density.  Mouse = energy input: right button add, left button remove.  Remove some energy in a lower corner until a nice chunk of liquid then ice forms.  You'll notice the rain becomes heavier and a very crude "storm front" rolls across the screen as rain or snow flurries.  The "air" is colored orange in liquid state, green in gas state, and (white? I forget) in solid.  Water is grey as gas, blue as liquid, cyan as solid.  Violet colors are plasmas, but since there's no fuel you can't really keep a fire burning unless you just keep adding energy, and it quickly dissipates.

Note the very low resolution, most systems can not handle even double or tripple this, even though Javascript code is compiled to machine code these days and has had decades of intense optimizations by an entire Internet full of big powerful players... can any other scripting language say so? (and yes, I'm aware JS still sucks big time)  Still this sim uses HTML5 Canvas so it could be sped up about 2x to 3x using WebGL (sans compute shader), but I wasn't trying to make a GL engine then.  These are particles emulating thermal transfer and phase changes with a fairly real time timestep.  I estimate a much lower resolution system based on gross approximations, and perhaps breaking time (only sim what you see) would be needed for any sizable gameworld.

There has been some aerospace companies doing work on such sims for wing icing and reentry effects, etc.  Check out their white papers, and some have released source code (though the license may not permit commercial reuse).  Most of their newish sims use a dynamic quad tree and are not 3D...  A few cross sections will usually suffice rather than a full 3D body.




(fun starts at approx 22min)

Welcome to the engine dev club.  Bottom Up design, FTW.  Or, I would suggest instead: Play with some other game mechanics in an existing engine, prototype until fun, make your first published game out of that (and gain exp).

When I was a kid there was no such thing as "game engines", so we all just made game things from scratch.  I see Pure BASIC is your lang of choice.  I graduated from BASIC to C+Assembly pretty fast because BASIC is SLOW, too slow to do what I wanted back then (and that was just a smooth scrolling platformer).  Even if translated into native code the runtime is a giant lumbering beast compared to the equivalent C program.  Nowadays it's not as big of a deal, unless you're doing incredibly massive simulations....  Just don't be afraid to switch languages is all I'm saying.  You learn 2 langs, you'll pick up more langs with exponential speed, eventually you'll just see "language" as some bullshit you have to put up with to express your logic on a given platform.  If you're into simulations, you'll have to get familiar with low level stuff someday anyhow.

Don't take my advice at face value.  Everyone is different, so do some soul searching and ask around.  Who knows, you could be the genius that makes pure basic into the world's best physics simulation lang.  Anything is possible in this magical realm.  After all, when you gaze at night into the vault of the heavens all you see is magic (I'm not even joking, Padawan).

[Darth_Dan]

Thanks a lot CodeLobe.
I will indeed look deeper into your advice, but right now I feel the need to clarify a few things here.
First of all, the goal. You expect me to behave like every reasonable Indie developer does and publish whatever small thing they create. However, looking at it from a gamer's point of view, and looking not at what is "successful" (as "success" is a very relative term) but at what was fun/pleasant to play I can point out a few categories that are "worth publishing":

1.) Simple games with pretty artwork and nice storytelling. These ones don't have to shine mechanically, really. Just awaken emotions in the player. These games could be successful, but are simply not my aim.
2.) Small proof-of-concept games with interesting and innovative mechanics. These games could be REALLY small. They could be limited to a single feature. But that feature is advanced enough to be art of itself. That's where I aim with the voxel project.
3.) Relatively large games with well optimized (even though likely not very innovative) mechanics. These games is what I see as an average commercial Indie product. They are reliably playable and usually have sufficiently complex storytelling. That is a large, serious project. This is where the galaxy one stands.
4.) Large, final games which combine new mechanics, interesting gameplay, storytelling. THey've got everything. This is just so large that I do not aim to grasp something like that yet.

Anyway, publishing and sales are more of a nice bonus for me. It is not a goal of itself, it is a possibility to show the world what you've done. And I would take it - when I will have done somethng worthy.

Put on your GPU compute shader hat for best results.

I don't quite understand what you mean. Use GPU for graphics or for calculations?
Also, I don't think I'm ready to make a 3D engine that complex. I mean, I can draw cubes or donuts in 3D, sure. But advanced shapes with depth etc... I'm just not ready for it.

I'd start with something smaller than a voxel physics simulation if you haven't released a few small games yet.  Spend your first time on something that won't leave you sore.

What I'm trying to do is not that big. I'd be absolutely content with having just a single 50x50x50cm cube which would be fully destructible in a number of ways. So that I could slice it in half, or melt it, or shatter it.
But what would you actually recommend for "my first time"? I'm not used to not thinking big...

Depends on how detailed your simulation needs to be.  The "Processing" engine or other particle-heavy frameworks may be much of what you need.  However, when you throw in "large scale" it typically means you're either using an engine built for making games pretty much like your game (good luck), or you're building your own game engine.  Fortunately it's fairly simple to make a 2D engine these days even with SDL.

So far I see it as "multilevel". Each starsystem is simulated, then the movement is translated into a function of time (and no longer simulated). When something (or the player) gets close enough, it loads the function, punches the coordinates into the simulation and it goes on. Now the real difficulty is the so-called "multiple body problem". It is easy to simulate a bunch of planets moving around a star. But add another large body that should interact with them all... And you're pretty much screwed. Now I have found a few off-the-shelf solutions, just haven't quite looked into them yet.

Also, what's SDL?

I graduated from BASIC to C+Assembly pretty fast because BASIC is SLOW, too slow to do what I wanted back then (and that was just a smooth scrolling platformer).

I know Basic is not the fastest thing there is... But PB runs in windows... In C all I can do is run a CMD-like console window. And I am yet to find a decent tutorial on coding anything game-like on C.

[CodeLobe]

But PB runs in windows... In C all I can do is run a CMD-like console window.

Well, you can call MS Win32 API and use GDI API, or Google whatever you want.  It's dangerous to go alone, here take this. (see also the language bindings for use with other languages besides C)  It's a cross platform tool to get you past all the boilerplate of OS interface required to make a game.

GPU compute shader

I don't quite understand what you mean. Use GPU for graphics or for calculations?

It means use GPUs for most of the computation you'd normally do in your CPU code.  A compute shader lets you do (almost) any arbitrary computation on the GPU (right next to where you're rendering the data) so that the primary slow as molasses bottleneck of sending new data to the graphics card or reading data back from the GPU can be avoided.  This allows you to run the simulation nearly entirely on the GPU, just sending input changes, and perhaps reading back to save or do network synch.  However, if you're just doing a small scale sim, then damn near anything should work, even Game Maker.

You expect me to behave like every reasonable Indie developer does and publish whatever small thing they create.

Well, not really.  But I do assert.h that it's usually better to sacrifice a project you don't care as much about on the altar of the Exp gods than to spend blood sweat and tears completing a greater labor-of-love, only to have it suffer due to lack of marketing level, timing dexterity, missed community dialog trees, or etc. non-production skills / dev side quests.

If you've completed projects you haven't released then more power to you.  Actually finishing a game and releasing it is a cathartic act of self transformation.  It's like learning the magic spell of creation. You just wiggle your fingers for a while using various instruments and incantations, muster the courage to cast it upon the unsuspecting, then `:,Poof';, something exists from nearly nothing but creative energy and countless others' experience is shaped by it.  If that's not sorcery I don't know what is.

I typically tell newdevs to make Pong, or Tetris, Space Invaders, Brickout, Pacman, Galaga, Mario (in that order, for reasons [progression in complexity and toolset features needed]). When (re)making existing classic games the design is set and all that's left is to familiarize oneself with the tools and act of creation.  Hell, Tetris is my "Hello World"; I remake it every time I learn a new lang or dev platform, just to say "hi" to all the core gamedev features (sound, music, input, render, timing).

Once, to win a silly bet, I made Tetris using only the URL bar of a web browser during the course of a single day (3hrs worth of my break time @ work).  I still use that program about once a month or so just to keep my stacking skills fit... In fact, I just used it to play tetris on this website right now.



Point being, crappy throw-away titles have more benefit than simply publishing a ton of crap to try and earn every bit of you can from gamers.  From a gamer perspective, no one is impressed by some fool with a crappy web-version of tetris.  From a dev perspective I know for a fact that I can use damn near anything to make a video game.  I can't think of anything that would keep me from making games except myself.  I don't even need a multi-line text editor.  Had I not won that dumb bet I might think I could pull off such a project but I wouldn't Know.  And Knowing is half the battle!

[Richard Kain]

What you're describing would actually be a good fit for certain game engines. Prototyping for short, fun experiences based more on experimental mechanics can be very rewarding. It's fun to play around with mechanics.

Prototyping usually works best with flexible, general-purpose engines. Something along the lines of Unity. From the sound of it, though, you are planning on using more low-level languages. (such as C) I'm going to recommend you take a look at Godot. It has a lot of similar strengths to a system like Unity, but features open-source support. I believe it uses C++ for its core engine, as opposed to C, so there is that. But for most performance-intensive tasks, having a C++ base is sufficient.

SDL is a standard game-related library often used as a basis for game development. I've experimented with it in the past, and it can be a bit tricky. But it supports lower-level languages, which is why it is a popular shortcut for fans of C and C++. It wraps a lot of back-end functionality that is a pain to code yourself, like loading functions for standard file formats. (images, 3D levels, etc...) While you would still need to tackle a lot of the custom drawing yourself, it would provide a solid base to start from, as well as tons of helpful hooks to common libraries. Because it doesn't have any pre-defined game-specific structures, it doesn't qualify as a game "engine."

Going the complete custom route is usually something that code junkies and demo-scene people play around with. If you are primarily focused on experimenting with mechanics, I would recommend picking an engine to use as a base.

[-Ross]

Yes, you should use a game engine. Even if you are sure at some point you'll want to write your own engine, you should try out at least a few existing game engines so you have some idea what the deal is. It sounds like you don't have much experience making games, so you should focus on learning. Engines take care of the hard and annoying parts of making games: low-level busywork, optimization, and large-scale universal organization stuff (that you must have made a game or two to even know about), to name a few. You really don't want to start with those parts. Starting from scratch, it's possibly you could work for a month without getting anything meaningful moving around on screen.

What I'm trying to do is not that big. I'd be absolutely content with having just a single 50x50x50cm cube which would be fully destructible in a number of ways. So that I could slice it in half, or melt it, or shatter it.

Centimeters don't have much meaning in game making, but if you're talking about a destructible cube with 50x50x50 resolution, that's 125000 sub-cubes, which is absolutely enormous. Plus, stuff like slicing, melting, and shattering are generally challenging to do at any scale. You should be thinking about making games that involve maybe 10 objects at once. I second the suggestion of Pong, Breakout, Pacman, Space Invaders, etc. At least make playable prototypes of those before you try to take on the world.

A 2D space sim/combat game is actually not the worst idea, because it's easier to see the progression in building that. You should start by aiming for a decent Asteroids game, then gradually add extra stuff.

Probably only your own experience will convince you of this, but you really should start small and simple if you don't want to get frustrated and give up. Take the long view. It's like, if you wanted to learn the violin, you wouldn't start by trying to play a Beethoven sonata at full speed. That would be awful. You would probably quit before you got anywhere. You would be much better off first learning how to actually hold the violin, how to hold the bow, how to play a single note, and so on. (you might want to learn how to read music somewhere in there too.)

[eyeliner]

Unless you are extremely good, have ample time and resources to master all the grunt work of making even a simple prototype of ayof your ideas to life, I'd say, "Use a framework". Scratching that, an engine would provide results way before you burn out and throw away your idea and hard work.