QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on August 12, 2020, 01:59:03 am
-
Is it necessary to use a modern language to build an engaging game or can you do it with BASIC? In this episode, let's talk about game development; find out some interesting games written in QB64 and go over what it takes to be a game developer, with a suggestion on how to become more experienced with it.
Relevant links:
- Games board: https://www.qb64.org/forum/index.php?board=18.0
- Stranger Things Retro Game: https://sites.google.com/view/astrangerthingsretrogame
- 486 The Game: https://486thegame.com/
- The Ultimate Oldschool PC Font Pack: https://int10h.org/oldschool-pc-fonts/fontlist/
Here's part 2: https://www.qb64.org/forum/index.php?topic=2907.msg122217#msg122217
-
I started using QBasic sometime in the 90s, and I've been doing my own game development in one form or another since I was four years old. Now that I am ready to create a real, professional game of my own, and possibly even sell it on a major platform eventually, I've been sketching up my ideas in QB64, and have been coding my own engine for my game from the ground up. You've seen snippets of my code here and there, as I've been asking for help when I couldn't resolve a major issue, like the shift issue with _keydown, or the overlay routine I debugged yesterday.
Two things have kept me from sharing more about my project on this forum. First, my game is going to be very story-heavy, and I want to keep that side of things completely under wraps until release to avoid spoilers.
Second, I forget where I saw it, but I remember reading some clause about programs developed using QB64, something about ownership of the code or requirement to be fully open-source or something. Can't remember the exact wording, but that is a deal breaker for me. I may share large chunks of code, like my sprite parsing system or the movement or stage scripting, but I am not willing to release the whole thing for everyone to look at before release. Hopefully you can understand where I'm coming from.
QB64 also has some particular things I would need to resolve to continue using it all the way through the game's development, otherwise I will be porting to C++ as I learn that language. The issues are things like sprite sheets being visible to the end user instead of baked into a data file, same for audio files; limited support for complex audio manipulation, such as playing the same sound over itself, looping a music file to somewhere other than the start, smooth fades, etc. Perhaps some of these issues can be solved within already existing QB64 features... the thing is that I need to solve all of them.
Barring the occasional limitation I run against and the clause I think I read somewhere, QB64 has been a fantastic place to hash out design issues and build the skeleton of the game. Partly by virtue of my already knowing QBasic, but there's also a lot of very simple plug-and-play stuff here that makes it great for entry-level game coding. I certainly don't regret using QB64 at all.
And as you mention, I've done quite a bit of game cloning on the side, just to see "can I make that?" I did part of an SRS-based Tetris engine to mimic Puyo Puyo Tetris for the Switch, which I've played a lot, and I cloned Panel de Pon / Tetris Attack in a limited capacity. Back when I got started, my two big projects were a text-based adventure and a lights-out puzzle game, both extreme spaghetti code of course. I believe the text adventure was a labyrinth of GOTO statements.
-
Hold on, *four years old*? That's a story I wanna hear.
Regarding having to release the source code, that refers to programs that use the built-in sound capabilities, due to the licensing of the sound libraries we use. From licenses/COPYING.txt:
=== IMPORTANT LICENSING NOTE FOR QB64 PROGRAMMERS ===
All executables which perform any kind of sound operation are subject to the LGPL license (due to incorporation of mpglibdll and OpenAL).
Other components are licensed under various permissive licences.
When sound components are included (thus the LGPL is in effect), the easiest way to meet terms of the LGPL is to make your program's source code (.BAS) available.
If you are not using sound components, you do not need to release the program's source.
If you are using fonts, you are bound by the terms of FreeType's license. Somewhere in your software package should include a notice that your program includes the FreeType library (see licence_freetype_ftl.txt for details)
In all cases, you should distribute the licenses folder with your program.
It should be noted that providing source code is not the only way to meet the conditions of the LGPL (eg dynamic linking) but it is by far the easiest from a technical point of view at this current time.
=====================================================
Extra emphasis on the last part: It should be noted that providing source code is not the only way to meet the conditions of the LGPL (eg dynamic linking) but it is by far the easiest from a technical point of view at this current time.
It is completely understandable that a project that relies in the story to be catchy needs some secrecy, of course.
Thanks for your input, @johannhowitzer
-
Yes, I started drawing up really simple, crude stuff on graph paper when I was very young, like making my own Mario levels for Super Mario Bros 1. Did graph paper sprites and cut them out with scissors. Growing up, we had an IBM 286 in our bedroom, and my brother and I would tinker with DOS and play a lot of old games, including Commander Keen, Jazz Jackrabbit, really a huge amount of shareware games our dad found on bulletin board services. Eventually, we found QBasic on the computer somewhere, I think it came with the machine, and started playing around with that.
In my early teens, which would've been the early to mid nineties, a friend and I decided to start our own "video game company," Sapphire Games, and we had a number of very beginner-level game projects using QBasic, good old line, pset, circle graphics commands in screen 12, eventually started messing around with sounds and screen 13 palettes. The lights out clone we made, titled Temporal Archer, had 64 levels I hand-tested on graph paper, and a medal system based on how many moves you took. We sold a couple copies to friends at church, on floppy disks. The text adventure I mentioned was a mishmash of themes, including robots, space, Atlantis, and it never got anywhere near finished as my ambitions kept growing and exceeding what we knew how to do.
Fast forward to college, and I found another circle of friends and started another game project that barely went anywhere. I didn't know how to lead a team, there were artistic differences, and I graduated shortly after and the project ended.
After that, I still kept dabbling in game design wherever I could; I've made a full game in Super Mario Maker 2 over the course of a year, fully themed worlds in a mimicry of Nintendo's style. Watched plenty of game design youtube content, including some GDC videos.
Finally, last year, inspiration struck, as a bunch of the ideas I've had over the past two decades congealed together around a new, strong central concept. The game started designing itself in my head around that one idea. At this point I'm making this game because I really want the game to exist so I can play it. The engine is complete enough now to create fully playable stages, and I am working on finalizing the code and demo stage design enough to pass out a few copies of a closed alpha demo. Got a lot more work to do, but it's a passion project and at this point I am making it my primary focus.
-
That's awesome and so relatable. Now this really hit close to home:
At this point I'm making this game because I really want the game to exist so I can play it.
I guess that's the strongest push.
-
Qbasic had a solid development community. The "this was made in Qbasic!?" you heard with Black Annex was the exact same thing you heard with games made almost 20 years before that. Some people think modern systems allow for Qbasic to be able to muscle its way through games that would have been impossible in the past, but the reality is that older games were all made at lower resolutions with less color using less RAM, so no one would have run into any walls trying to make similar games back then. I think the big limits in Qbasic were file size and native RAM limitations rather than the language itself holding people back, but libraries that removed a lot of the limitations were available.
The biggest lesson for me in developing games was how simple the basic design for them could be.And of course, the design had to be simple because hundreds of games were being released every year, but the fact that the complexity of my favorite shooter might have just been the same as a version of Pong where your paddle shoots balls that blow up other paddles was a revelation. Something like Final Fight uses the same basic system, but you have an animation play before the collision detection, and instead of making the other character disappear, you check their state and play the appropriate response animation. That's it. Under the hood, a substantial portion of 2D action game catalog can be reduced to Pong ports.
if you can move an object around on the screen, tell when it touches another object, and make something happen as a result, you've created a basic core engine for 2D action games
Because of that, I think Fellipe's Particle simulation is actually a perfect introduction to game design and how simple it actually is. Ignoring all of the design theory and game loops and all that for a moment; Fellipe created, in a few minutes, a program that put objects on the screen, moved them around, had them react to each other and respond to player input. How much time would it take to fully gamify that?
You could base the game around protecting some vital cell from attack by surrounding the invaders. The player can use the mouse to control a boss particle that sends commands to and tugs on the particles it connects to. You can create multiple types of particles that behave differently, increasing the strategic range; gain power ups for every enemy surrounded,etc. You can spend 3 days optimizing it all to a Game Jam level of quality. You can spend months working on graphics, sound and interfaces to create a polished indie game, or spice it up for a year with a full fledged story mode and completely overhauled graphics engine.
But the majority of the work on the game itself would have been done on that first day of putting together the basic system. Everything that follows is just deciding what to do with the game you've already created. A lot of the QB64 games in text mode or using simple line art simply aren't devoting a lot of energy to dressing the games up in obvious ways.
-
Cool report!
@FellippeHeitor
about Regarding having to release the source code, that refers to programs that use the built-in sound capabilities, due to the licensing of the sound libraries we use. From licenses/COPYING.txt:
so if I use no QB64 instructions about sound because I use an external soundlibrary am I free from that limitation of distribution?
for examples if I use a DLL or a my library that calls OS's sound functions like DirectX of WIndows....
I think that the next can be around Game Design in QB64 if there are other members interested to this issue.
@johannhowitzer
fine to read so much determination and will to get the goal of seeing alive own creature!
@Gets
interesting point of view about game engine
-
Out of curiosity, is there a way to post still images on this forum?
Figured it out, just use attachments. Posted a brief overview and screenshot of my game project over in the in-progress projects section.
-
I liked the quote "Write games, not game engines". I've certainly been guilty of that a couple of times now.
Even though writing the game engines was a great learning experience, I have nothing to show from them. I regularly cannibalize code from them, but I could just as easily do that with a fully-written game.
I love making games in BASIC. I couldn't stand making a game in something like RPGmaker. Even an object-based language like vbasic loses a lot of the oomph for me. Only con is no Android functionality.
-
@Gets:
The biggest lesson for me in developing games was how simple the basic design for them could be.
Totally agree. Nothing stops you from going the extra mile and making it full-fledged, but a simple idea can also get you far.
@TempodiBasic:
so if I use no QB64 instructions about sound because I use an external soundlibrary am I free from that limitation of distribution?
for examples if I use a DLL or a my library that calls OS's sound functions like DirectX of WIndows....
I think that the next can be around Game Design in QB64 if there are other members interested to this issue.
Exactly. Using any other way to play sounds that doesn't rely on the builtin functions exempts you from having to share your source code.
BTW, Cobalt is preparing a follow-up episode on the topic of game development, it'll be pretty good.
@johannhowitzer:
Not only you can attach images, but you can also insert them in the body of your post - look for "Insert Attachment" as soon as you select your file. You can do it afterwards too, by using the "Modify" feature.
@manstersoft:
Here's a recommended read regarding the same "games, not engines" topic: https://geometrian.com/programming/tutorials/write-games-not-engines/
Thank you all for your feedback.
-
Kérdezhetek egy hülyeséget ? Én sajnos nem látok a basic mögé, egyáltalán nem ismerem hogy mik történnek a háttérben. Lehet gyorsítani a műveleti sebességet ?
-
I'm with Fellippe here, I can totally relate to this statement.
At this point I'm making this game because I really want the game to exist so I can play it.
It's the same thing with my star system simulator. While not a game in the classic sense, it's the table top RPG gaming utility that I wish I had when I was active in that community. My attitude is, "Damn it, when I leave this shit show, it's gonna exist." ;)
-
Kérdezhetek egy hülyeséget ? Én sajnos nem látok a basic mögé, egyáltalán nem ismerem hogy mik történnek a háttérben. Lehet gyorsítani a műveleti sebességet ?
English (as per Bing):
Can I ask you a stupid question? Unfortunately, I can't see behind the basic, I don't know what's going on in the background. Is it possible to speed up the operational speed?
(Still after translation, I don't know what he is referring to?)
-
don't be angry Bplus! :) I describe it differently. I want more speed. lower the limit, calculate the program faster.
the game program must be restrained because it is stalling to run.
-
Regarding having to release the source code, that refers to programs that use the built-in sound capabilities, due to the licensing of the sound libraries we use. From licenses/COPYING.txt:
Extra emphasis on the last part: It should be noted that providing source code is not the only way to meet the conditions of the LGPL (eg dynamic linking) but it is by far the easiest from a technical point of view at this current time.
How would one dynamically link to the sound library? I'm getting closer and closer to releasing one of my games commercially and I am also using the built-in sound. I never read the licenses before, but I just assumed by using ogg I would be in the clear.
-
Hi folks,
Why it had four mins of talk about fonts is beyond me but ok, @FellippeHeitor you've got a very soothing voice my man!
When i was at uni (my degree was in computer games programming) we had to use many different langages to make games. XNA, Unity, Flash and others. I would always make two versions, one in the specified language for the project and the other in QB64 using UnseenGDK. This was when we had the SDL version only so i dont know how much it will have improved but QB64 was never able to match the frame rates i could get in the other languages.
Because of the limitations of the language, such as types not supporting arrays, no function overloading and other things, making games in QB64 is tiresome in comparison to using for example, C++.
This being said, QB64 is an excellent way to introduce someone to coding for any purpose though games are of course the most fun, but it lacks a lot of what modern game dev engines incorporate, such as "a physics engine", but thats something im sure Steve or someone else who understands math much better than I could easily piece one together as a .bm library.
As for me, I dont make games much, i definately never finish them! This is only because i enjoy making the tools to make games more. My Quake 3 model loader for example, whilst it's still not finished, it does now support animations and positioning of objects via their tags (i.e you can add a gun to a model and it will be in the right position/rotation).
I've stuck some pics of some of my previous(and totallay abandoned) game engine dev work, thanks folks and happy coding.
Unseen
-
@Unseen Machine
Great screen shots, so that's what Quake Chess was supposed to look like. :)
I have demo'd how to write an overloaded function and how to use strings to store arrays in UDT's but of course we all know these things do not help the speed of execution that is needed in games.
Come to think, isn't an Eval function overloaded? Sort of an ultimate one unless you want to consider an Interpreter that takes a file for a parameter.
-
How would one dynamically link to the sound library? I'm getting closer and closer to releasing one of my games commercially and I am also using the built-in sound. I never read the licenses before, but I just assumed by using ogg I would be in the clear.
If your program is going to be distributed solely as a Windows binary, for example you can use Windows' API to play sounds: http://www.qb64.org/wiki/Windows_Libraries#Play_WAV_Sounds (http://www.qb64.org/wiki/Windows_Libraries#Play_WAV_Sounds) - that would bypass static linking with OpenAL entirely.
don't be angry Bplus! :) I describe it differently. I want more speed. lower the limit, calculate the program faster.
the game program must be restrained because it is stalling to run.
We've come a long way since QBasic times, so much that we need to cap the execution speed of programs from the era, like Gorilla or Nibbles. But we have a few layers of code separating your BASIC code from the end product that gets compiled by GCC, since there's a graphic middle-man which is then rendered by OpenGL. If the speed QB64 achieves is a key factor in hindering your game development, then a modern language is probably your target after all.
Hi folks,
Why it had four mins of talk about fonts is beyond me but ok, @FellippeHeitor you've got a very soothing voice my man!
Lol, thanks for the compliment. About the font talk: we've had this segment where we discuss something that was recently highlighted here in the forums... it would have been a much shorter episode in the end if that bit wasn't there.
This being said, QB64 is an excellent way to introduce someone to coding for any purpose though games are of course the most fun, but it lacks a lot of what modern game dev engines incorporate, such as "a physics engine", but thats something im sure Steve or someone else who understands math much better than I could easily piece one together as a .bm library.
STxAxTIC has a fully-working 2D engine floating around, with a few built-in proof of concept little games written with it as demos. I believe it's worth checking out: https://www.qb64.org/forum/index.php?topic=2295.msg115260#msg115260
Thanks for sharing the screenshots, they look really good.
-
The hard part about making games isn't making the engine, it's making the content to put in that engine. The further I got in my project, the more I realized the bulk of the work is going to be sprite art, animation, level design, story writing, sound design, music composition, and tweaking game mechanics.
-
Part 2: To wrap up the topic of game development and game cloning, Dave (aka @Cobalt) walks us through his process with his games.
-
Cloning seems like it would work extremely well with creating expansion packs for older games. I played a few roms that were hacked to do something similar, but that obviously provides a lot less freedom on the development end than reverse engineering the entire engine.
-
Yep! I was imaging at these words
Cloning seems like it would work extremely well with creating expansion packs for older games.
but QB64 can use external C/C++ library so can we write a MOD or an Expansion Pack of games like DOOM, HEXEN, WOLF3D?