QB64 REPORT S01E06 and S01E07: "Game development" (parts 1 and 2)

[Unseen Machine]

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

[bplus]

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

[FellippeHeitor]

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

[johannhowitzer]

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.

[FellippeHeitor]

Part 2: To wrap up the topic of game development and game cloning, Dave (aka @Cobalt) walks us through his process with his games.

[Gets]

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.

[TempodiBasic]

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?