Limitations of GLBasic?

Previous topic - Next topic

Jean-Luc Skywalker

Although we're mostly new to programming, a friend and I have some ambitious ideas for games. We really want to see them made, but we'd rather not spend years learning C++ or C#. It seems that GLBasic may be the answer to our problem.

But, what are its limitations in comparison to the "big" languages? We wan't to create serious, immersive games complete with decent quality 3D graphics, cutscenes and complex, varied gameplay. Maybe not quite to the level of the current generation of games, but something that could have commercially sold on the PS2.

I know this is a large undertaking any way it could be gone about, but can GLBasic as a language fully handle what we're wanting to do with it?

Thanks.

matchy

Cool. Tell us more about the game or this is just a troll post.

GLBasic is great "small" language for producers and programming friends teams with dreams and will handle large undertakings.

BlueSteel

Generally speaking MOST languages our there today can write great software. the real limiting factors are the imagination, experience, knowledge of the language of the person trying to use it. Also the skills of the graphic artist, movie maker, sound engineer, level designer, support desk.

Don't try to fly or run before you can walk. set goals , small projects that are realistic for your level of expertise and knowledge. DON'T TRY TO MAKE THE NEXT WOW OR STARCRAFT OR HALO OR MINECRAFT AS YOUR ONE OF YOUR FIRST DOZEN OR SO PROJECTS. unless you know the language inside and out, the OS your writing for instide and out, and have heaps of experience already writing those calabir of games.

IF you do then your just letting yourself in for big disapointments


Hatonastick

I pretty much agree with everything Matchy and BlueSteel have said.  Walk before trying to run, otherwise when you find yourself repeatedly getting stuck the chances are (and I've seen this countless times over the years with people new to programming games) you will end up walking away from it in frustration.  Really though only you can judge whether or not you are ready for such a project.

All I'll add is I sure hope your project isn't an MMO.  MMO's are a heck of a lot more complicated behind the scenes than most people realise -- standard MMO's that is, not talking about web based ones.  Even the network model is complex.  Things have come a long way since MUDs.

As to whether or not GLB is capable, yes it is.  GLB scales well to big or small projects, plus you can use C++ inline (within certain limits) freely (it's a cross platform _compiler_ so creates binaries and isn't a runner+script language setup like some) so it's not that hard (once you know what you are doing) to add third party DLL support eg. Newton physics which comes as an example with GLB.  The only two limitations of its 3D that you might want to keep in mind is that currently GLB only reads its own proprietary format 3D files (although there is a converter tool so you can import other formats) and it doesn't handle skeleton animation (keyframe only).  I know Gernot looked into both of those 'issues' at one point but don't know what his plans for the future are.  GLB does pretty much anything that OpenGL allows though including shader support.
Mat. 5: 14 - 16

Android: Toshiba Thrive Tablet (3.2), Samsung Galaxy Tab 2 (4.1.2).
Netbook: Samsung N150+ Netbook (Win 7 32-bit + Ubuntu 11.10).
Desktop: Intel i5 Desktop with NVIDIA GeForce GTX 460 (Win 8.1 64-bit).

Jean-Luc Skywalker

Yeah, I'm well aware of needing to take baby steps in reaching the end goal. In my head I have it worked out something like this :

- Learn base-level syntax
- Do several tutorials
- Make a couple simple demo games
- Make basic, individual aspects of the "real" game
- Build from, learn, revise

It's just that I want to make absolutely sure I'm not going to be wasting my time learning a language that will eventually dead end on me. I don't want to eventually hit a wall that makes what I want to do impossible.

The main game we're wanting to do, by the way, is a 2D platformer with stealth and puzzle elements in a fully 3D environment. It will at times have a lot of things happening on screen, and also have extensive cutscenes and voice acting. We've been working with and revising this concept for many years now. We have ideas for other games, but we want to do this one first for many reasons, not the least of which being that we think it would be the easiest to program (our other ideas are a city building-esque RTS game, which would require a lot of logic for the tech trees, and a 3D platformer/shooter).

BlueSteel

the only dead ends are those you make yourself. I have used over 12 programming languages over the years. NONE of them have been dead ends. as I'm always learning and programming is one of those skills that aren't limited to languages you use. sure the syntax is different but programming concepts remain the same. I always use this analogy of what a programming language is. If you want to tell a french person how to do something and a german person. its better if you speak THEIR language. the information and context , plot of your subject matter remain the same. you just have to talk to them in their language. thats all that programming languages are. a language that both you and the computer know and can communicate with, and the more you understand the language the more you can do with it.

I draw a lot of knowledge from all the languages i've used, none of it is wasted. you learn more from your mistakes than you do from doing everything right the first time. and believe me theres always more than one way to write the same program in the same language.

matchy

Delta, the 3D platform game sounds great. Try out the demos and post some of your GLB code!

BumbleBee

Most difficult part is graphics design. That's why many hobby-programmer stop their projects. Good luck. Keep us informed.  :booze:

Cheers
The day will come...

CPU Intel(R) Core(TM) i5-3570k, 3.4GHz, AMD Radeon 7800 , 8 GB RAM, Windows 10 Home 64Bit

Hatonastick

#8
Delta, that sounds very well thought out and achievable.  I hope it all goes well!

From what you've described there should be no (complete) dead-ends while using GLB.  One of GLB's many strengths is its flexibility.  Worst case scenario is you end up having to use a third-party DLL to get around a 'limitation', and that is no big deal.  It's also not that uncommon with any development language I've seen.

Sorry if we caused offence in anything said.  You tend to get a little cynical after spending years on programming forums where you get fly-by visits by people who have never programmed anything before and yet expect the earth with their first game.  You are obviously not one of those people.
Mat. 5: 14 - 16

Android: Toshiba Thrive Tablet (3.2), Samsung Galaxy Tab 2 (4.1.2).
Netbook: Samsung N150+ Netbook (Win 7 32-bit + Ubuntu 11.10).
Desktop: Intel i5 Desktop with NVIDIA GeForce GTX 460 (Win 8.1 64-bit).

Jean-Luc Skywalker

Thanks for the support and feedback, everyone! it's much appreciated. If this program has nothing else going for it (which certainly doesn't seem to be true!), it at least seems to have a fantastic and helpful community.

I've downloaded the free version of GLBasic and will start tinkering with it a bit in the near future. At the moment most of my focus is going into mastering PHP, in an attempt to get into freelance web designing (I'm pretty fluent in HTML and CSS already, but of course that's not saying too much). Bills come before leisure, not the other way around  :). That said, I really do want to get these games made, sooner than later, and will devoting down time to learning the BASIC syntax.

Thanks again!

ketil

I don't quite agree with the "language is not the limiting factor" statements.

GLBasic is perfect for small to medium- sized games.

Maybe even better than most c++ frameworks because of the ease and the development speed.

But ... at one point you will miss full object orientation. Classes, inheritance, templating and several other oo features.
That point is usually when the game grows over an certain size that demands a lot of variation (or similarity).
When you need to reuse code. Then oo is needed.

Pointers are also VERY nice  =D

I am using GLB for small sized project, and Airplay SDK(C++) for larger ones.
Airplay is by the way free for iphone/ipad platforms, and is also quite reasonably priced for the other platforms (Android, Symbian, Brew, Maemo ++)
"Sugar makes the world go 'round. Caffeine makes it spin faster."

Jean-Luc Skywalker

#11
Hmm. How big would you say is too big?

EDIT: A thought comes to mind. Would large games become more feasible if I learned a bit of C++ and used it inline in GLBasic? Would that allow me to use object oriented features without needing to know C++ by heart?

Slydog

#12
I wouldn't worry about c++ too much.
There's no real definition of 'too big'. I think to make things clear, it should be reworded to 'too complex' as in game logic.

If you split your project into multiple source files, each with a specific purpose, and have a multi-file library that is generic (and not specific to your current project) keeps things pretty organized and modular.  (plus future game projects will already have a library to work with!)

I have a folder in my project source called '_LIB' and have about a dozen library files in there that take care of 'Input', 'Sound', 'Gui', 'Vectors', etc.  Then my main game project source is kept very tidy by simple calls to my library such as 'Gui_Add(GUI_MAIN,...)', and 'Gui_Display(GUI_MAIN)', 'Mesh_AddQuad(...)' etc.

I like the updated TYPEs with the option to include functions, it brings GLBasic closer to OOP, and so far this seems to be enough.

My project is approaching 5000 commands as reported by the compiler, including my library, which is over half of that.  If organized, I can't see any problems with size, except initial compile time!  (I think libraries can be pre-complied into . . . library files)

To be honest, the only limitation I find with GLBasic so far is the lack of 3D physics, but that's just a matter of someone porting an existing library, such as iXors3D, over to GLBasic.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

Jean-Luc Skywalker

Thanks, Slydog. I'm beginning to become a little concerned, though. Our games will be completely 3D and will require fluid and lifelike 3D movements. Is this going to be (overly) difficult using a system with nothing but keyframe animation (no skeleton), and no established physics engine?

Slydog

#14
If those are your requirements, them maybe GLBasic may not be the answer.
I hate to mention a competing SDK, but you may want to look into 'Unity3D'.
It is a much more professional and full featured game development SDK, and their Windows version is now free.
And they allow coding in C#, or a modified Java Script.

But it has a much steeper learning curve.
If you are already familiar with 3D modeling and animations, maybe it wont be as difficult.
I first tried Unity3D, before GLBasic, but being a complete game programming noob, I was lost in the game graphic terms such as shaders and materials etc and even when I learned what they were I found it difficult to get Unity to behave how I wanted, no fault of Unity, but my lack of experience in game programming.

I prefer GLBasic's simplicity and the control it gives you with knowing what is going to be executed next etc.
With Unity, a lot of the game editing is done in their IDE and each game object has it's code separate from the rest, and I found it confusing when trying to find out how it all worked together and it what sequence the code was being executed, but again, this was probably because of my inexperience with Unity.

I don't think I've abandoned Unity3D all together, but I decided to purchase and go with GLBasic for now, and build up a library and finish at least one game.
Then for future projects I'll decide which SDK is best for that project.

I think if it is a more simpler project, I'll stick with GLBasic, as I find it easier to develop in, and will be able to complete it faster (once my libraries are done!  dang, there's always something I need to add!)
Or 2D, as Unity's support for 2D is (or at lease was) limited to using 3D polygons to simulate a 2D sprite.

You could try a smaller scale project in GLBasic to start, like I did (or intended, man its getting complex!) and learn the ropes.
Then decide later when you want to try your current idea.  Your experience can be applied across the various SDKs generally.

[Edit]
Perhaps I should have started with a 2D project!  But come on, 3D seemed much more fun!  And I've done 2D before on the C64.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]