Asking the TDWTF hive mind [choice of language]
-
Let us assume I am some quotient of TR
. It is a given, so we can assume some level of brain damage inside my brain.I want to make a 2D game, nothing especially complicated that's new or going to set the world on fire - requirements:
- 2D graphics library that can draw images from existing media; no complex transformations required since everything is tilesets as long as it can draw transparency sanely
- sound would be nice ideally if I don't have to babysit it and can just go 'here, play this on loop until I tell you not to' for music
- input that can handle keyboard and mouse, ideally without me having to manually track 'state since last frame' so 'key pressed' can be treated as a thing rather than 'key is down, was it down last frame'. Mouse delta since last frame would be neat but can figure out myself if needed.
- crossplatform is nice but needs to build for Windows
- physics need not apply, I don't need anything complex I can't compute myself and collisions need only really go to AABB bounding boxes
The part I'm confused about is language... I could write this in something like JavaScript with any of the frameworks out there, I could even use something like Cerberus-X (the offshoot of Blitz Basic/BlitzMax/Monkey-X)
But because I am TRWTF I'm debating something a little less obvious and with a little more practical use beyond that field...
Contenders are Python (PyGame?), Go (Pixel?) and maybe Rust (needs more research)
Thoughts? I have some vague Python but nothing in either Go or Rust and for this I'd rather not touch Unity or Unreal.
Open to other suggestions though.
-
@Arantor game development in Rust is going to be PITA. Dunno about Go or Pixel. PyGame is just a thin wrapper over SDL, a pure C library with all the quirkiness of a C library (and it's all software rendered - be aware). It's been almost ten years since I last checked what's amateur gamedev done with, and back then it was still C++, but I'm pretty sure it's not anymore. But in case you want C++, the SFML library is easy to pick up and does everything you want (and more).
-
@Gąska well I'm not conceptually averse to learning C++ but I hoped to make my way there a little more gradually...
-
something like JavaScript
some vague Python
I won't be telling you that Lua is basically like Python (though it is pretty similar to JavaScript in a lot of the semantics), but check out LÖVE. Someone wrote Mari0 in it. It seems to have everything you need.
-
This post is deleted!
-
@Arantor oh, if you don't know C++ already then forget it.
If your primary goal is to make a game, then I'm sorry, but it seems Unity is your best bet. Most support and least boilerplate and fighting with the internals trying to make anything, let alone the game, work.
If your primary goal is to learn something, then pick the thing you want to learn and build your game with it. Every semi-popular programming language has one 2D library or another (just remember that half of them are SDL ports). The principles are mostly the same in every tech stack, so it doesn't matter that much. As for which language is best to learn - if you're looking at it career-wise, it's JS followed by Python followed by TS followed by Java followed by C# followed by Kotlin followed by Rust.
-
@Arantor said in Asking the TDWTF hive mind [choice of language]:
@Gąska well I'm not conceptually averse to learning C++ but I hoped to make my way there a little more gradually...
FWIW, there are a lot of C libraries out there for gamedev. Going C/C++ will give you a lot of infrastructure and you can start with the "C with classes" approach and see what C++ features end up making sense to you.
OpenGL does a bit more than what you seem to want. The more modern versions are in a semi-neat state. Probably does a bit more than you want to, but on the other hand, you won't be stuck with a library that can't do what you want. Learn OpenGL is a fairly reasonable starting point. You can skip a bunch of stuff there if you only want to do 2D.
The tutorial above uses GLFW. It's light-weight, but has all the essentials (create windows, mouse/keyboard events like you describe, can deal with gamepads/joysticks).
You will probably need to deal with some vector math (even if it's just 2D). One of the go-to libraries is GLM. This is the only C++ one so far (this is one of the cases where operator overloading isn't completely insane).
The one thing that OpenGL doesn't do for you is loading images. My go-to solution is STB's image loader, stb_image. I'm pretty sure that's also covered by the tutorial for OpenGL above. Worth linking because STB has a bunch of other libraries, and maintains a list of other easy-to-include ones as well.
It's a bit more of a piecemeal approach. Has a bunch of advantages and disadvantages. Advantages is that you can gradually add stuff as you need it, and if there is a component that you don't like/doesn't do what you want, you can just replace it. YMMV.
-
@Gąska yeah, I don't already know C/C++ though Cerberus-X which I mentioned is transpiled down to C++ which is dense and impenetrable to me.
Careerwise, I dislike JS enough that I'd never want to do it as a day job. I am laughingly a "full stack" dev with a back-end focus but can write JS if I have to. I just don't want to.
Mostly I was coming at it from the sense of I want to learn a new language, I'm not super invested in it being for a career but if it has some possible overlap, great. But I'm the sort that likes to have a goal in mind, rather than just having some learning in the abstract.
So I found myself a modest goal and was just approaching 'what are my choices for making it' other than Unity/Unreal and choices I am already directly aware of, which is what lead me here today.
A bit of poking around suggests Go might have slightly better libraries and ecosystem for this particular endeavour than Rust, but I was also curious to see what other suggestions TDWTF might have on the subject...
-
@Arantor if you want to learn just for yourself, then I'd say Rust would be the best - because learning Rust teaches you so much about programming in general. You'll either hate it or love it. And there are quite a few gamedev-focused libraries in decent shape. This one seems most popular:
The state of tutorials is pretty shit though. But I don't expect anything in Go to be much better.
-
@Arantor oh and don't even think about raw OpenGL. That's like learning assembly to make a simple web server.
-
Well, there's always Unity (i.e. C#). Created a multiplayer PacMan clone 4 years ago where one person played PacMan and the other 4 controlled the ghosts.
Yes, I know, you excluded it but it does check all your boxes.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
@Arantor oh and don't even think about raw OpenGL. That's like learning assembly to make a simple web server.
No, that would be suggesting raw Vulkan/DX12.
-
@cvi right. OpenGL is more like learning LLVM IR.
-
Ugh, do not touch PyGame. I’d much rather write a bunch of JavaScript from scratch to a CanvasRenderingContext2D (and, in fact, have done just that).
-
I may be interested in a collab of this nature if your choice of platform is agreeable.
-
Someone mentioned LÖVE already, so let me help stir the waters by mentioning HaxeFlixel instead.
Though that is another language altogether: Haxe.
Note I'm not talking out of personal experience. I've just seen it mentioned many times before and it does seem promising.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
(and it's all software rendered - be aware)
SDL does have OpenGL-accelerated 2D rendering. It's fairly basic, but enough to build a simple game with: https://git.wukl.net/ancient-project-archive/lbs/-/blob/master/src/main.c. It also has an audio plugin, SDL_mixer.
It's all easy to use, provided you know C. It's probably best to forget about C++ for now. For more serious game projects I'd consider a managed platform first, like C# and Unity.
And then there's this: https://pecl.php.net/package/sdl
-
@Wukl said in Asking the TDWTF hive mind [choice of language]:
@Gąska said in Asking the TDWTF hive mind [choice of language]:
(and it's all software rendered - be aware)
SDL does have OpenGL-accelerated 2D rendering. It's fairly basic, but enough to build a simple game with: https://git.wukl.net/ancient-project-archive/lbs/-/blob/master/src/main.c.
Oh, good to know. Last time I checked it was still very experimental and lacked most features of the software renderer.
Still don't recommend. Mostly because of C.
-
@Zecc said in Asking the TDWTF hive mind [choice of language]:
Someone mentioned LÖVE already, so let me help stir the waters by mentioning HaxeFlixel instead.
Though that is another language altogether: Haxe.
Note I'm not talking out of personal experience. I've just seen it mentioned many times before and it does seem promising.
I used Flixel with ActionScript, back when ActionScript still had some future (you know, it's Flash). I liked it. Nowhere near as nice as real Flash, but at least it was free.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
If your primary goal is to make a game, then I'm sorry, but it seems Unity is your best bet. Most support and least boilerplate and fighting with the internals trying to make anything, let alone the game, work.
That's not the impression I get from reading @Tsaukpaetra's posts about it...
Isn't using Unity for a simple 2D game massively overkill, anyways?
I mean, the features @Arantor is looking for is pretty much what SDL (and a few extensions) provides out-of-the-box. Yes, it is C-based, but it's pretty simple C and there are wrappers for lots of other languages.
-
@Zerosquare said in Asking the TDWTF hive mind [choice of language]:
That's not the impression I get from reading @Tsaukpaetra's posts about it...
I mean, if you don't want anything complicated, it will get the job done without too much fuss if you follow a tutorial....
-
@Zerosquare said in Asking the TDWTF hive mind [choice of language]:
@Gąska said in Asking the TDWTF hive mind [choice of language]:
If your primary goal is to make a game, then I'm sorry, but it seems Unity is your best bet. Most support and least boilerplate and fighting with the internals trying to make anything, let alone the game, work.
That's not the impression I get from reading @Tsaukpaetra's posts about it...
Isn't using Unity for a simple 2D game massively overkill, anyways?
Nowadays a budget laptop has 4GB RAM. Who cares about overkill?
I mean, the features @Arantor is looking for is pretty much what SDL (and a few extensions) provides out-of-the-box.
The one thing it doesn't provide out-of-the-box, even with extensions, is managing game objects. Creation, destruction, collisions, reaction to global events. If you're not using a ready-made engine, this stuff is going to take 90% of development time and will be very buggy the first 150 iterations.
Even for a 2D game, Unity, or any other full-fledged game engine, is going to be a giant productivity boost. I'm only aware of 2 game engines suitable for 2D games - and one of them is non-free even for personal use.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
Nowadays a budget laptop has 4GB RAM. Who cares about overkill?
@Gąska said in Asking the TDWTF hive mind [choice of language]:
Even for a 2D game, Unity, or any other full-fledged game engine, is going to be a giant productivity boost.
If you need to cut 300 sheets of paper, learning how to operate a laser cutting machine is a huge productivity boost.
But if all you need to cut is 3 sheets of paper, it's overkill. You'd spend way more time reading the docs (and finding out that 95% doesn't apply to your usage) and setting up the machine than the 5 minutes it takes to achieve the same result with a pair of scissors.
KISS principle, basically: start by implementing a proof-of-concept version of your game using simple tools. See if it's actually fun to play. See what works and what doesn't. See where the complex/tedious parts are. Then, decide if switching to something like Unity is worth it or not.
-
@Zerosquare said in Asking the TDWTF hive mind [choice of language]:
KISS principle, basically: start by implementing a proof-of-concept version of your game using simple tools. See if it's actually fun to play. See what works and what doesn't. See where the complex/tedious parts are. Then, decide if switching to something like Unity is worth it or not.
I agree completely, except you've got the tools backwards. Unity is perfect for quick prototyping; you have all the systems ready to go and you just have to insert the objects into the level and code the game logic. If you started from scratch (SDL gives you so little it's essentially from scratch), it would take you 100x more effort just to see a character move on screen. I'm not exaggerating. In fact, I might be underestimating the number.
After you have the basic prototype working, then is time to decide whether to stick to Unity or make your own engine. 99 times out of 100, the answer will be stick to Unity.
But that's all
because finishing the game in foreseeable future doesn't seem to be a priority.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
@Zerosquare said in Asking the TDWTF hive mind [choice of language]:
KISS principle, basically: start by implementing a proof-of-concept version of your game using simple tools. See if it's actually fun to play. See what works and what doesn't. See where the complex/tedious parts are. Then, decide if switching to something like Unity is worth it or not.
I agree completely, except you've got the tools backwards. Unity is perfect for quick prototyping; you have all the systems ready to go and you just have to insert the objects into the level and code the game logic. If you started from scratch (SDL gives you so little it's essentially from scratch), it would take you 100x more effort just to see a character move on screen. I'm not exaggerating. In fact, I might be underestimating the number.
After you have the basic prototype working, then is time to decide whether to stick to Unity or make your own engine. 99 times out of 100, the answer will be stick to Unity.
But that's all
because finishing the game in foreseeable future doesn't seem to be a priority.As someone that has created multiple have engines for fun, I agree with @Gąska here. If the goal is to build a game engine, pygame is ok, if the goal is to build a game something else is better.
-
@Gąska In concur. The PacMan game I mentioned? I got that working inside 24 hours.
-
@kazitor said in Asking the TDWTF hive mind [choice of language]:
I’d much rather write a bunch of JavaScript from scratch to a CanvasRenderingContext2D (and, in fact, have done just that).
The biggest problem with doing that is that you get no support for associating incoming events with graphical objects, and have to do all the geometry calculations by hand just to figure out what the fuck the user is pointing at.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
If you started from scratch (SDL gives you so little it's essentially from scratch), it would take you 100x more effort just to see a character move on screen.
Except that you've still got the (2D) character moving on the screen by the time you've installed Unity and figured how to create a new project.
-
@cvi are you for real?
-
@error said in Asking the TDWTF hive mind [choice of language]:
I may be interested in a collab of this nature if your choice of platform is agreeable.
Coming in from the sidelines, I briefly considered writing a (super simple) game clone with JS / ThreeJS, just to learn how to do it. So I guess you could provide some valuable input to that... But then, if I let you touch it you're probably done with the whole thing before I figured out how to open a page...
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
@cvi are you for real?
Valid question. There is of course a small amount of hyperbole (not that dissimilar to your post), but I do think that's actually quite doable.
But, ultimately, we're currently talking about a (starter) 2D game. Look at some of the games that people produce for various game jams and similar. You don't need to go all game-engine for a small game. You don't need complex entity management. OP mentions no need for physics, and only needing to test AABB bounding boxes. You don't need to go fully data-driven. You don't need to do scripting. Drawing tiles (with or without blending and/or masking) is simple enough as well.
But essentially, if you don't want to go Unity or Unreal, you don't need to. There are plenty of (much simpler) options. Maybe too many. On the other hand, if you want to learn Unity (or some other engine), hey, that's a valid reason as well.
-
@cvi That's all very true, but that doesn't change the fact that in the current year you're probably better off using a third-party game engine for anything, than rolling your own from scratch.
Hell, I'd probably even use Unity for making a text-based adventure, at this point. The mere fact of having all the boilerplate already done for you is worth the price of entry.
Sure, you'll need to learn the environment and workflow if you don't know it, but the same is true for anything. The difference is that the engine covers the most common use cases, so you don't have to reinvent the wheel (or look for code to copy and paste without understanding).
-
@cvi said in Asking the TDWTF hive mind [choice of language]:
Valid question. There is of course a small amount of hyperbole (not that dissimilar to your post), but I do think that's actually quite doable.
Download size aside, last time I tried messing with Unity (a couple months ago) it took me like 10 minutes to set up everything. It really is as simple as they advertise (the basic stuff I mean). A few years ago I wanted to make a fighter jet game (arcade-style, like Ace Combat). Ultimately it went nowhere, but in one weekend I managed to make an airplane fly over a randomly generated (ahead of time, not dynamically) terrain. I even had an editor panel for messing with plane's physics - in real time while playing. It was a lot of fun.
Look at some of the games that people produce for various game jams and similar.
These games are made:
- by experienced game developers;
- using either off-the-shelf game engines or self-made libraries prepared in advance;
- often in teams;
- usually in 48 hours with around 5 minutes of gameplay (by which I mean productivity isn't very high).
Not really applicable to OP's situation.
-
@GOG said in Asking the TDWTF hive mind [choice of language]:
Hell, I'd probably even use Unity for making a text-based adventure, at this point. The mere fact of having all the boilerplate already done for you is worth the price of entry.
You reminded me of a story from my high school. We've had a borderline sadistic CS teacher. In 2nd grade (11th in imperial), the final project - individual for each student - was to make some kind of a video game. In C++. Note that this wasn't an elective class or a special computer-oriented school - he just threw C++ on thirty Bogu ducha winnych teenagers. So of course I helped everyone by making the projects for them.
I had a little experience making console-based games. One of side effects was that I've become very fluent in WinAPI. Previously I made a roulette game, full color and shit. It took me about a month to make, mostly spent learning C++, learning WinAPI, learning good coding principles, and learning ugly workarounds for common problems.
So when it was time for the final projects, I was ready. I knew everything I needed, and just churned out games like there's no tomorrow. I've made poker, basketball duel, and several others I don't remember. I've made like 7 different, fully functional games in 2 weeks.
Of course as a star student, my own project had to be on another level. I wanted to make a Space Invaders clone, using SDL. That didn't work out. Between making classmates' projects (not for free mind you), studying for other classes, partying a lot, and
, I just couldn't find enough time to work on it. It also turned out to be waaaaay harder than I thought. In the end, the game wasn't even half ready by the deadline. So instead I dug up another game I made years earlier, a Minesweeper clone. Also in SDL, so advanced enough to show off. The plan almost worked. The fucker checked modification time of the files. To his credit, he didn't drop my final grade. He just roasted me in front of the class.I was really proud of that basketball game and it pained me I couldn't take credit for it.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
I was really proud of that basketball game and it pained me I couldn't take credit for it.
Games released in the Atari VCS (2600) era were often done by single developers who received no credit whatsoever. This was part of the reason Activision was formed - by disgruntled former Atari employees.
-
(Eh, removed, wasn't adding anything useful to the discussion either.)
-
@cvi said in Asking the TDWTF hive mind [choice of language]:
anything useful to the discussion
We don't do that here.
-
@GOG said in Asking the TDWTF hive mind [choice of language]:
I'd probably even use Unity for making a text-based adventure, at this point.
butbutbut.... Inform!!!
Filed under: It is very unlikely.
-
@error said in Asking the TDWTF hive mind [choice of language]:
@cvi said in Asking the TDWTF hive mind [choice of language]:
anything useful to the discussion
We don't do that here.
we're in help category, so yes we do.
-
@Gąska said in Asking the TDWTF hive mind [choice of language]:
I had a little experience making console-based games. One of side effects was that I've become very fluent in WinAPI.
Fear and loathing!
-
@GOG honestly, I much prefer WinAPI over all the web abominations of today. It really isn't that bad once you get hang of it. It's just very verbose due to being plain C.
-
@Gąska I was gonna be quippy, but... on reflection... it's not that bad.
The verbosity was one thing, but - in the Win 3.x days, at least - the (relatively) low level of operations was the big issue. When I look back on that time, the amount of boilerplate code was massive.
I remember coming across Borland's Object Windows Library (which I never did get around to mastering) at the time and the difference was staggering.
-
@GOG I am reminded that Borland had written large portions of WinAPI calls, magic numbers and structs. IIRC even
GetLastError()had a simple way to get the text . Now, if only MS had written P/Invokes for .NET the same way... (there is a "simple" way to get the text, but that's all).
-
@GOG said in Asking the TDWTF hive mind [choice of language]:
@Gąska I was gonna be quippy, but... on reflection... it's not that bad.
Yeah. I'm glad that the amount of WinAPI code that I need to deal with has decreased, but it's not that bad to deal with. Documentation is generally easy to find and tends to be reasonable.
I hate having to deal with raw X11 way more. Fortunately that also doesn't happen that often anymore.
-
@GOG said in Asking the TDWTF hive mind [choice of language]:
@Gąska I was gonna be quippy, but... on reflection... it's not that bad.
The verbosity was one thing, but - in the Win 3.x days, at least - the (relatively) low level of operations was the big issue. When I look back on that time, the amount of boilerplate code was massive.
I remember coming across Borland's Object Windows Library (which I never did get around to mastering) at the time and the difference was staggering.
I remember making resizable forms in visual basic 1.0. This involved an onresize function which explicitly recomputed the position and size of all relevant controls.
-
@PleegWat said in Asking the TDWTF hive mind [choice of language]:
I remember making resizable forms in visual basic 1.0. This involved an onresize function which explicitly recomputed the position and size of all relevant controls.
That's how all resizable UIs work, except that some GUI toolkits provide the on-resize handlers for you, so that all you need to actually do yourself is describe the layout policy.
-
You bastards! Now you've got me going through WinAPI docs, reminding myself how it used to be done.
I hate you all!
