Hi guys,
It is my dream to one day make my shmup. The thing is I don't like all of those soft programs out there like GameMaker, theUnity engine, Goydot, etc..
Anyways, like I was saying, is it possible to make a shmup in C with a Notepad and .BMP files for graphics with custom sounds and music? Would I need libraries for that?
Cheers,
Grzegorz Sączcietrzewski
Can you make a shooting game using just code?
-
Jonathan_PSX
- Posts: 7
- Joined: Fri Apr 16, 2021 8:55 pm
Re: Can you make a shooting game using just code?
Sure. The easiest way would be to use an all-in-one library for games to handle graphics/input/sound/files/etc such as raylib (there are many others, look around). Otherwise you'd have to use lower level APIs such as DirectX and Vulkan directly, which generally means thousands of lines of code before you get to anything resembling a game.
That said, you might want to consider why you don't want to use other tools. If you just don't want to use their editors, it's often possible to completely ignore them outside of running and configuring the game and just code everything (Godot in particular is pretty friendly to this, you don't even need to use its scene tree if you don't want to). If you just want absolute control over your main loop, then it still might be better to use a higher level language like C# with a game library.
That said, you might want to consider why you don't want to use other tools. If you just don't want to use their editors, it's often possible to completely ignore them outside of running and configuring the game and just code everything (Godot in particular is pretty friendly to this, you don't even need to use its scene tree if you don't want to). If you just want absolute control over your main loop, then it still might be better to use a higher level language like C# with a game library.
Re: Can you make a shooting game using just code?
Notepad is pretty shitty for coding, but if that's what you prefer for C, then I guess be my guest.
I'm not sure why you wouldn't be able to?
I'm not sure why you wouldn't be able to?
Re: Can you make a shooting game using just code?
Windows BMP files are
Why do you want to use pathetic rudimentary tools? Even with "just code" (in C, C++, Javascript, Python, Java, other advanced programming languages) you should expect to use
- not compressed
- not transparent
- complicated and antiquated.
Why do you want to use pathetic rudimentary tools? Even with "just code" (in C, C++, Javascript, Python, Java, other advanced programming languages) you should expect to use
- advanced IDEs (Emacs, Microsoft Visual Studio, Eclipse, Visual Studio Code, something more specific)
- advanced image editors
- advanced 3D model editors (e.g. Blender)
- GPU debuggers (e.g. RenderDoc)
- build automation tools (CMake, Meson, Ninja, custom scripts, etc.)
- specialized tools to edit and preview assets (e.g. tilemap editors and particle system editors)
- specialized tools to package and process assets (e.g.texture atlas builders, archivers)
[Scribblings of a madman]
Sure, you could build all the infrastructure yourself from the ground up in a low-level language, though it's liable to take much more time than it's worth!
Modern architectures - particularly the graphics side of things - require a staggering amount of boilerplate to make work compared to the old days of fixed-platform hardware. So in practical terms, you're probably going to end up standing on the shoulders of giants and using external code to achieve your goal without wasting lots of time reinventing the wheel.
Which isn't to say that the ideal of avoiding big monolithic dependencies like game engines or hefty frameworks is a bad thing - I think it's actually a more healthy standpoint than picking up an easy-to-use tool that claims to do it all, and then getting tangled up in a mess of somebody else's shitty domain-specific bugs.
And let me tell you, all of the engines, every last one, suffers from some big issue or other. Clickteam, Game Maker, Unity, Unreal, Godot, Bevy - throw a stone in a random direction and you'll hit one that has poor development direction, long-standing dealbreaker bugs, bad documentation, an excess of legacy baggage, or whatever else. And it only ever becomes obvious once you're waist-deep, shit's a trap.
They do offer plenty to make up for it, but that ends up pushing you in the direction of becoming an <insert engine> developer, rather than a software engineer in the more general sense. Which sucks, because programming is so much more than wrestling with someone else's software stack.
Though in a sense, it depends what you're looking for - if it's about the ideal of that old-school bedroom programmer experience, wringing the most out of simple hardware that's relatively understandable, fantasy consoles like Pico8 are a worthy choice. They abstract away all of the modern hardware concerns behind a fictitious microcomputer interface, so you can worry less about the boring system wrangling and more about making your thing.
But, fantasy consoles are like The Matrix - you're completely wrapped up in someone else's system. Ignorance can be bliss, but it's not for everyone.
On the other hand, if it's a more ideological concern (as it is for me,) then choosing the right tooling is going to be be key. Pick out a good language, and shop around for small well-maintained libraries that do one thing (ex. graphics, sound, input, etc) and do it exceptionally well.
That way, you can build your own setup from the ground up, have total knowledge of it (which is critically important, since you're the person who'll have to fix it when it breaks,) and benefit from other people's good code while retaining the liberty to restructure the whole thing at your discretion.
As for languages; if you're fixated on using C then fair enough, but I wouldn't recommend it. There are compilers out there nowadays that are as-good in terms of being full-control systems languages, but will also bend over backwards to help you write good bug-free code. By contrast, the C family is extremely manual in every way, and often needs extra tooling (CMake, Meson, static analysis, testing frameworks, etc . etc.) stacked on top to make it usable.
I'd say take a look at Rust if you want something comparably 'systems' but ten times nicer to actually use. Or, if you're open to something more exotic, a functional language like Haskell. Perhaps one of the Lisp family as a nice middle ground between "I want to write logic, not machine instructions" and "I don't have a Master's degree in category theory".
To quote King: "There are other worlds than these", where programming is concerned. At the very least, you owe it to yourself to learn of the paradigms that exist beyond classical imperative C, because getting caught up in the mud of learning to speak on the machine's terms when a compiler can do that for you, is so much wasted time when you have a game to make. It should learn to speak you, as best it can
I ditched VSCode for Neovim (also great, if esoteric!) after MS decided to arbitrarily mark all my workspaces as 'insecure' in a particularly obnoxious update a while back, and happen to have spent the last month migrating to Emacs after finding out about all the awesome stuff it wraps around the core text-editing.
Went for the whole-hog 'Ultimate Lisp Machine' experience - it's my shell, terminal, desktop, just about everything from the login prompt down. Total consistency, best computer setup ever
Modern architectures - particularly the graphics side of things - require a staggering amount of boilerplate to make work compared to the old days of fixed-platform hardware. So in practical terms, you're probably going to end up standing on the shoulders of giants and using external code to achieve your goal without wasting lots of time reinventing the wheel.
Which isn't to say that the ideal of avoiding big monolithic dependencies like game engines or hefty frameworks is a bad thing - I think it's actually a more healthy standpoint than picking up an easy-to-use tool that claims to do it all, and then getting tangled up in a mess of somebody else's shitty domain-specific bugs.
And let me tell you, all of the engines, every last one, suffers from some big issue or other. Clickteam, Game Maker, Unity, Unreal, Godot, Bevy - throw a stone in a random direction and you'll hit one that has poor development direction, long-standing dealbreaker bugs, bad documentation, an excess of legacy baggage, or whatever else. And it only ever becomes obvious once you're waist-deep, shit's a trap.
They do offer plenty to make up for it, but that ends up pushing you in the direction of becoming an <insert engine> developer, rather than a software engineer in the more general sense. Which sucks, because programming is so much more than wrestling with someone else's software stack.
Though in a sense, it depends what you're looking for - if it's about the ideal of that old-school bedroom programmer experience, wringing the most out of simple hardware that's relatively understandable, fantasy consoles like Pico8 are a worthy choice. They abstract away all of the modern hardware concerns behind a fictitious microcomputer interface, so you can worry less about the boring system wrangling and more about making your thing.
But, fantasy consoles are like The Matrix - you're completely wrapped up in someone else's system. Ignorance can be bliss, but it's not for everyone.
On the other hand, if it's a more ideological concern (as it is for me,) then choosing the right tooling is going to be be key. Pick out a good language, and shop around for small well-maintained libraries that do one thing (ex. graphics, sound, input, etc) and do it exceptionally well.
That way, you can build your own setup from the ground up, have total knowledge of it (which is critically important, since you're the person who'll have to fix it when it breaks,) and benefit from other people's good code while retaining the liberty to restructure the whole thing at your discretion.
As for languages; if you're fixated on using C then fair enough, but I wouldn't recommend it. There are compilers out there nowadays that are as-good in terms of being full-control systems languages, but will also bend over backwards to help you write good bug-free code. By contrast, the C family is extremely manual in every way, and often needs extra tooling (CMake, Meson, static analysis, testing frameworks, etc . etc.) stacked on top to make it usable.
I'd say take a look at Rust if you want something comparably 'systems' but ten times nicer to actually use. Or, if you're open to something more exotic, a functional language like Haskell. Perhaps one of the Lisp family as a nice middle ground between "I want to write logic, not machine instructions" and "I don't have a Master's degree in category theory".
To quote King: "There are other worlds than these", where programming is concerned. At the very least, you owe it to yourself to learn of the paradigms that exist beyond classical imperative C, because getting caught up in the mud of learning to speak on the machine's terms when a compiler can do that for you, is so much wasted time when you have a game to make. It should learn to speak you, as best it can
A fine recommendation!
I ditched VSCode for Neovim (also great, if esoteric!) after MS decided to arbitrarily mark all my workspaces as 'insecure' in a particularly obnoxious update a while back, and happen to have spent the last month migrating to Emacs after finding out about all the awesome stuff it wraps around the core text-editing.
Went for the whole-hog 'Ultimate Lisp Machine' experience - it's my shell, terminal, desktop, just about everything from the login prompt down. Total consistency, best computer setup ever