2015-03-04 20:58:04 (edited by Genroa 2015-03-04 20:59:39)

BGT isn't really bad, this isn't what I say. But:
- sounds and some basic stuff is done, but nothing else
- oriented object programation is so basic you have to use AngelScript syntax to do even basic things in OOP BGT (remember how to convert a class into another, casting a superclass or doing the "java instanceof" ? You can do it in BGT, but you have to use AngelScript)
- you basically have to create any tool you may want to use (aaaaand that's why I'm making a game engine, because just starting with basic classes and saying "hey I will make a multiplayer shooting game from nothing!" is nearly impossible smile )

2015-03-04 22:01:52

I don't follow what you're trying to say.  Bgt's programming language is Angelscript, the FFI is not developed enough to let you talk to anything complicated, and therefore, yes, everything you do is Angelscript.  Unless you want to write an interpreter for a language of your own design.  By hand.
I don't know what your engine is trying to do, nor is it the topic of this thread.  But you will never, ever get away from needing Angelscript, and there is almost certainly no reason to port.  I can get pubsub frameworks, physics simulation, sound, database and network serialization, and an input handling framework just by installing some Python packages.  If I go to C++, I give up the easy serialization and the fact that the language doesn't have you constantly scratching your head in puzzlement or punching something in annoyance for like 50 different game math, physics, and collision options.  The reason that people use BGT is that all of the existing frameworks require you to use ticking and not explicitly wait on things, but as soon as you've gone there you've started rewriting things that you can just install as libraries in other languages.  Just wait until you get to needing something like behavior trees or an actually powerful implementation of astar (which does way more than pathfinding on your game map, if you want it to).
Sorry, I know my annoyance is showing.

My Blog
Twitter: @ajhicks1992

2015-03-04 22:31:17

I understand where you're coming from. I already am running into some of these problems, especially in regards to the physics and astar. The implementation in bgt requires a 2d array, which my game doesn't use. I'll probably have to throw together something for that, too.
Well, like I said. lesson learned. big_smile

Prier practice and preparation prevents piss poor performance!

2015-03-04 22:59:22 (edited by Genroa 2015-03-04 23:00:29)

I am currently only programing in C, Java and BGT. If I port my engine in Java, this will be a new thing, it has never been done before in Java smile

I don't know what everyone have with Java; the standart library is so huge that this kind of project doesn't need any extern lib except for physics, its object concepts are very developed, etc.

I believe ticking is a must have in games, along with threads (pleaaaaase give me threads in BGT :'( ). Every modern game engines uses ticks, you can't make a non blocking architecture only with hundreds of threads xD


Oh, and I have been forced to learn python during my studies, I hate it and for me it is a dead language smile (but it's just what I think)

2015-03-04 23:36:15

If you think you need threads, I shudder to know what your engine will look like.  Most non-3D games use exactly 1 thread only.  Many giant webservers use exactly 1 thread only.  Threads solve nothing in terms of complexity.  Threads solve exactly one problem: I can't make this run on only one core.  We have had the threading conversation before on this forum.
I'm not going to comment as to your like or dislike for Python.  That's a preference. 
And as for why we don't do much Audiogame development in java?  Swing accessibility sucks.  There's a 200 MB runtime that everyone has to go install separately, or which has to be bundled with every single game.  Talking to C/C++ is hard without external libraries like JNA.  The sound situation sucks worse than anywhere I've seen.  Redistributing runs into all sorts of really strange issues, at least according to CAE_Jones.  So, yeah, not worth it.

My Blog
Twitter: @ajhicks1992

2015-03-05 00:11:53

Java as no need to use the swing dinosaur or any GUI for audiogames smile

2015-03-05 00:48:02

No, it doesn't.  I am merely listing all the problems with Java.  If many blind people were using the language for hobby programming, then we'd probably see audiogames in it.

My Blog
Twitter: @ajhicks1992

2015-03-05 01:35:33

I will change that! *epic voice and all* seriously, we really need more bases for audiogames, everyone is inventing the wheel again everywhere

2015-03-05 01:54:32

It'shard to say. I think, for me, even though doing this has been incredibly annoying, I've also learned a lot from it, which is always a good thing.

Prier practice and preparation prevents piss poor performance!

2015-03-05 05:00:28

Learning is always good.  And there is something to be said for duplicating existing technology specifically to learn about it.
But we don't need more bases for audiogames.  We need people to realize that these bases already exist.  If you build an engine in BGT, that's fine, but it'll be just as complicated to use as if I left for a mainstream language; the ease and beginner friendliness of BGT are then completely lost.  So I don't get it.  Just find a mainstream language that doesn't make distributing completely impossible or require ridiculously large dependencies and use it.
As a bonus, this can give you nice things like cross-platform support, GUI libraries, the list goes on and on.  Maybe I'm too far divorced from new programmer to see it anymore and should just give up trying to understand.

My Blog
Twitter: @ajhicks1992

2015-03-05 14:39:57

Hi there,

I fully agree, Genroa. A lot of people cannot develop cause they are reinventing the wheel again and again.

Hum, curious, Camlorn saying we don't need more basis... But he is developing another audio library. Wait, wait, I see an incoming  500 words long post about what is and what is not a base...
I mean any technology which make game developing easier, .

We don't need new languages, absolutely not, but audio libraries and game classes and game components made for audiogames design may accelerate game creation exponentially.

Most game engines (virtually all of them) are made with visual design in mind, so they are hard to deal with.
Some use ides in witch you build a game project (like Unity), some use complex classes that make difficult to separate audio from graffical elements (like irrlicht/Irrklang).

Templates, classes and engines are just what many developers are waiting for.

Unfortunatelly, audio was not the most important part of a traditional game (take a look at any review of any new generation console, a lot of information about its graffical capabilities, nothing about sound). Designing visual games is easier than ever, but the audio part remains almost the same.
Pygame, for example, has not 3d audio at all. And yes, you can add another library, or create your own, but I'd like to add only a library to my projects and get out-of-the-box game classes, game components, math methods, high level audio  management, physics, user input, etc, etc.

Mainstream industry has its own priorities, and each audiogame developer writes code for his own use, so, yes, we need more bases and more sharing.

Alternatively, we need an slave army of camlorn clones to solve  all our questions, but I think we are nearer to the first option... lol!

Just my opinion.

2015-03-05 16:57:11

This is exaclty what i'm trying to do with my own projects : providing ready-to-use classes like characters, weapons and items, all working together with a big Game class. I don't think it will remove the "easy part" from BGT, but it may give more power to developers to create games focusing on the creative part more than on the functional part smile

2015-03-05 21:09:02

Libaudioverse isn't a base.  Libaudioverse isn't even really aimed at audiogames specifically.  Libaudioverse equivalents exists in exactly two forms currently.  One is GPL with no option for dual licensing, available only in Python,  and with major speed issues.  I worked with the other for a year: OpenAL.  And you can arguably use it.  But does it ever have problems.
believe me, I'd not be doing Libaudioverse if something both reasonable and for less than $5000 or so existed.  The last thing I want to do is duplicate tech.
But I suppose my point here is that not only are we trying to make basic game classes, we're duplicating stuff that you can just get libraries for.  And by the time you're done, you've made BGT as complicated as it would be if you'd done it in something else, but it's still BGT so you can't really bring other stuff in if you want it.

My Blog
Twitter: @ajhicks1992

2015-03-05 21:15:38

What about fmodex and/or bass libraries?

2015-03-05 23:56:56

So, I'm a little confused about how dictionaries in bgt work. do I just assign the value to a handle of whatever enemy? or, something else.

Prier practice and preparation prevents piss poor performance!

2015-03-06 00:21:27

@Dranelement:
yes.  The id is the key, the enemy is the value.
@Genroa:
Unless something has majorly changed in the last 6 months, no.  You have to write chunks of code in C just to get most libraries to fit BGT's pitiful DLL support.  No callback functions, no structs, no pointers to pointers.  You can't even call enough of the Windows API to open a Window and put a button in it, forget audio stuff that wants to call your code from a background thread via a callback function and stuff.  The number of C libraries you can effectively talk to completely is pathetic.
now, maybe it's been completed and is less lame, and someone feel free to correct me if that's the case.  But I looked into it for Libaudioverse and actually do have BGT's manual installed, and that's what it says.

My Blog
Twitter: @ajhicks1992

2015-03-06 00:31:20

Ah, thanks. So then, how would I effect the enemy via the dictionary? From what I understand from the helpfile, I'd have to create a generic enemy, then do something like enemies.get("key", enemy);
Where enemy is a handle to the generic enemy, that will be populated with the properties of the dictionary entry? Sorry about all the questions again, and thanks very much for the help!

Prier practice and preparation prevents piss poor performance!

2015-03-06 00:33:12

Grr. You've just moved into Angelscript specific territory and consequently are beyond where I can help.  That's the basic idea, but I don't know how Angelscript type casting and polymorphism stuff works well enough to help you finish it.

My Blog
Twitter: @ajhicks1992

2015-03-06 00:39:18

Ah, okay. I'll see if I can find the angelscript docs and figure it out. My regret at choosing bgt is growing very fast, though... sad

Prier practice and preparation prevents piss poor performance!

2015-03-06 01:02:04

The idea is this: it's an enemy base class, but some things are going to want to "cast" down the tree.  That is, if a piece of code knows that enemy 53 is actually a tank and needs to do tank things to it, it'll cast the enemy class.  In C++ this is done through pointers; in java there's dedicated operators; in Python you just treat it like a tank and it is.
For the most part inheritance should do the trick.  The fictitious tank can mostly if not completely live inside the things the tank class overrides.  But avoiding the above completely is nearly impossible.  BGT almost certainly has a way to do it, but I don't know what that way is.

My Blog
Twitter: @ajhicks1992

2015-03-06 01:15:07

Ah, thanks. So then, how would I effect the enemy via the dictionary? From what I understand from the helpfile, I'd have to create a generic enemy, then do something like enemies.get("key", enemy);
Where enemy is a handle to the generic enemy, that will be populated with the properties of the dictionary entry? Sorry about all the questions again, and thanks very much for the help!

Yeah, pretty much.

Class casting in Angelscript is kinda cumbersome, but I don't think it should matter in this case, especially if you only put enemies in this dictionary.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2015-03-06 01:41:14 (edited by Genroa 2015-03-06 01:49:16)

@camlorn : a 3D sound lib is available for BGT, using FMODEx wrappers smile it's still in debug but it's working! How, will you tell me, because it uses a lot of structures? In fact, you only keep the reference of the structure and give it. You never give the structure as a parameter. And for things where it is an obligation, dlls have been coded to manage them  smile

For BGT casts, you can cast a handle using : MyChildClass@ castedObj = cast<MyChildClass>(NonCastedReference); it returns null if the cast is impossible smile

For arrays and all, creating a SuperClass@ array lets you storing SuperClass or a subclass object references smile

2015-03-06 02:25:48

I know how one can go about getting libraries which do not work with the BGT FFI to work with the BGT FFI.  I have seen the library in question.  I am almost certain this is a specific example where someone wrapped FMODEx with a C layer that lets it talk to BGT, but it's possible FMODEx is simple enough if you forgo some features.  Also, FMODEx is missing HRTF, or so says the internet; when this particular library came on my radar, I checked.
Even if FMODEx doesn't require the intermediate layer, half the things you might want do.  If you really want to spend time writing C libraries to call other C libraries so they can be used from BGT, fine.  But know this is not necessary in most other languages, and you're still not going to be able to hit the ones that need to use callbacks, i.e. every scripting language ever.

My Blog
Twitter: @ajhicks1992