Author Topic: QB64 REPORT S01E06 and S01E07: "Game development" (parts 1 and 2)  (Read 8039 times)

0 Members and 1 Guest are viewing this topic.

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

FellippeHeitor

  • Guest
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:

Here's part 2: https://www.qb64.org/forum/index.php?topic=2907.msg122217#msg122217
« Last Edit: August 29, 2020, 04:12:56 pm by FellippeHeitor »

Offline johannhowitzer

  • Forum Regular
  • Posts: 118
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #1 on: August 12, 2020, 07:38:12 am »
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.

FellippeHeitor

  • Guest
Re: QB64 REPORT S01E06: "Game development"
« Reply #2 on: August 12, 2020, 08:20:40 am »
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:
Quote
=== 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

Offline johannhowitzer

  • Forum Regular
  • Posts: 118
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #3 on: August 12, 2020, 08:43:31 am »
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.

FellippeHeitor

  • Guest
Re: QB64 REPORT S01E06: "Game development"
« Reply #4 on: August 12, 2020, 09:15:06 am »
That's awesome and so relatable. Now this really hit close to home:

Quote
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.

Offline Gets

  • Newbie
  • Posts: 28
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #5 on: August 12, 2020, 01:53:01 pm »
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.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #6 on: August 12, 2020, 02:11:04 pm »
Cool report!

@FellippeHeitor
about
Quote
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
Programming isn't difficult, only it's  consuming time and coffee

Offline johannhowitzer

  • Forum Regular
  • Posts: 118
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #7 on: August 14, 2020, 08:08:03 am »
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.
« Last Edit: August 14, 2020, 08:31:23 am by johannhowitzer »

Offline manstersoft

  • Newbie
  • Posts: 22
    • View Profile
    • My Games
Re: QB64 REPORT S01E06: "Game development"
« Reply #8 on: August 14, 2020, 01:12:37 pm »
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.

FellippeHeitor

  • Guest
Re: QB64 REPORT S01E06: "Game development"
« Reply #9 on: August 14, 2020, 01:46:38 pm »
@Gets:
Quote
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:
Quote
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.

Offline MasterGy

  • Seasoned Forum Regular
  • Posts: 327
  • people lie, math never lies
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #10 on: August 15, 2020, 06:26:05 am »
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 ?

Offline OldMoses

  • Seasoned Forum Regular
  • Posts: 469
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #11 on: August 15, 2020, 07:36:02 am »
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." ;)

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #12 on: August 15, 2020, 11:47:04 am »
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?)
« Last Edit: August 15, 2020, 11:51:06 am by bplus »

Offline MasterGy

  • Seasoned Forum Regular
  • Posts: 327
  • people lie, math never lies
    • View Profile
Re: QB64 REPORT S01E06: "Game development"
« Reply #13 on: August 15, 2020, 02:44:14 pm »
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.
« Last Edit: August 15, 2020, 02:45:29 pm by MasterGy »

Offline manstersoft

  • Newbie
  • Posts: 22
    • View Profile
    • My Games
Re: QB64 REPORT S01E06: "Game development"
« Reply #14 on: August 15, 2020, 10:35:26 pm »
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.
« Last Edit: August 15, 2020, 10:37:23 pm by manstersoft »