BDX alpha release: Testers wanted.

As some of you already know, I’ve been working on a small, cross-platform game engine for Blender, built on top of libGDX. I wanted my initial release to be something more complete, but due to various setbacks, and an overall recognition that my initial goals were a bit too ambitious, I decided to release BDX in its current form, and work from there.

I need the community to test the core of the engine, so that I can ensure that existing development architecture functions properly on most systems, before I go on to add more features, write documentation, and make tutorials.

Here’s a video that elaborates on those points (and also demonstrates a portion of the existing API):

While I will be grateful for whatever time you can actually contribute to test this project, what I really need are testers willing to re-test new releases of BDX, as I provide them to address reported issues.

So, reporting an error/bug to the issues tracker is good, but sticking around to confirm that it’s resolved would be really helpful.

Project page: https://github.com/goranm/bdx

Link to the latest releases, the issues tracker, and the wiki are all available from there.

Thanks!

Great news! I’m gonna get right on it!

Nice work, Goran. I’ll be checking it out too. For questions could I ask here? For issues I’ll go to github.

Awesome! I’ll take a look. Like Raco, I’ll hit up your github project with issues and feedback.

So it seems like the major bugs preventing further exploration might have been ironed out. Perhaps getting a roadmap up on the wiki would be a good idea to help give some direction as to where to go next?

Also, have you considered posting about it on Reddit’s /r/gamedev community? I’m sure a lot of Java-users are there, and they’d probably be more than happy to contribute to BDX.

I have a couple of questions:

  • If no SDK directory is specified when creating a BDX project, will it be possible to do it afterwards, so everything will also work on Android?
  • Which necessary steps I should take to be able to specify an SDK directory? It would be nice if you could show this in a video, because I guess it’s a bit complicated.

Reason I ask is because I would like to test with Android too.

I’d like to thank everyone here for generously offering their time to test BDX, and helping to bring the project into a functional state.

There are still a few issues remaining, and there will probably be more in the future, but at this point, the basic setup seems to work, for most people.

@SolarLune

I don’t think it would be wise to reach out to the wider community until I have a solid beta -> 0.1.0

From my perspective, that would include the following:

  • A reliable BDX release, that “just works” on all relevant platforms (I think we’re basically there, or really close).
  • Good documentation, covering the currently available API.
  • A decent tutorial series, where users can see the development of a small/simple game from beginning to end.

With that, I think I’ll be able to draw in a sufficient number of users, a decent fraction of which will be able to make games for various platforms, including the browser. The browser target is especially important, because for game jams, like Ludum Dare, people are hesitant to download and install anything, so being able to just give someone a link to your game will be a big motivator.

Where users go, developers seem to follow, and that’s basically my strategy for attracting developers.

Without that … Well, I can post to a bunch of places, and people may be interested initially, but if they can’t find anything more than a github repository, most of them will just feel blocked.

Even with developers, one has to be careful: If I just have a github repository, and some grand “roadmap”, but no actual users, making actual games … It just looks like one more project that’s likely to go nowhere, even if it holds some potential, in theory.

First impressions are very important, and I want BDX to make a good one, based on what it can concretely do in practice.

@Raco

There is no straightforward way to include the android SDK after the project was already created. I should definitely take the time to include that feature, but for now, if you want to test android, you’ll have to specify the path to the android sdk while creating a new project.

That makes sense. In addition to good API docs would be a Building BDX topic that covers how to build BDX to assist in contributing. I managed to use Ant to build BDX and make class files, but it never turned into a JAR file (which is what I need, right?). I guess I should look up some info on Java in general first, though.

Yeah learning how to contribute would be cool (not sure how much I could do, but I’d love to try). You can use something like Eclipse IDE to build your project… Though I don’t know how to import projects without having to annoyingly add every individual file.

I am a silly person,

who does not understand how to get started,

is there any way to get a 32 - bit windows exe?

or a addon for blender?

thanks.

It’s an addon which you can get from https://github.com/GoranM/bdx/releases
Watch the first few minutes of this video for an explanation:
https://www.youtube.com/watch?v=Ja8K-HdVE1g

:slight_smile:

I feel like the source is, at this point, rather simple. There’s not a lot to the engine right now, which should make it easier overall to learn. Java seems to be a bit easier to comprehend compared to C++, as well, which should assist in learning. Maybe Goran can speak on this, but it’s kinda weird to have the assets for the project in the Android folder. I’m sure this was a calculated decision that is pretty much the best of both worlds (being able to access the assets easily in development, and where the android compiling process expects them to be).

I have to get some understanding of Java and exactly what the user of BDX is dealing with (i.e. Is all of the BDX API “compiled” and contained in core/libs/bdx.jar for each project?), but I think the process to contributing would be a basic “check out source > compile and test > write code > compile and test > fork > send pull request” concept. I think I’d like to try adding in gamepad functionality from LibGDX if possible and an easy task to approach.

I would also prefer to have assets in the core project (that seems logical), but LibGDX projects expect all assets to be in android/assets, so I have to follow that convention.

Java is not exactly my favorite language (I actually prefer C++), but LibGDX is a Java framework, and they have a working cross-platform pipeline, so I’m willing to push aside my bias, and just use the language they support.

More detailed BDX development instructions would be useful, and I plan to write some, but for now, to build, all you have to do is just run ant in the root directory (where build.xml is located). I didn’t test things on other platforms, but if it works properly, that will generate a new bdx.jar in blender/bdx/libs. With that jar built, blender/bdx represents the complete addon, which can be zipped up and installed like any other.

However, for testing purposes, doing that every time, just to test some feature, is far too tedious, so you might want to make a bdx symlink in …/scripts/addons, which just references blender/bdx. That way, whatever changes you make are automatically picked up when you restart blender.

Also, if you’re testing engine features (as opposed to just addon features), and you want new versions of bdx.jar (which are generated with ant) to be picked up in a previously created BDX project, it would probably be a good idea to replace core/libs in that project with a symlink to bdx/libs.

^ Good bits of info that would be nice to push onto a basic preliminary “Building BDX” wiki page. I checked my source, and I do indeed have a built version of bdx.jar in the blender/bdx/libs folder (though I’ve yet to test to see if it works correctly).

As a side-note, do you mind if we write on the Wiki pages? Seems like it’s open - maybe just for contributors (and we’ve opened issues and stuff, so I guess that counts)?

I have no idea how the github wiki system works. As far as I can tell, anyone with a github account can contribute.

I hope that the system will require my approval before making changes public, but I don’t know.

Having you add that page would be a good test - If you have the time, give it a try.

OK, I gave it a try using some of the info from your post. Here are the build instructions. :open_mouth:

It seemed to go through immediately, though, so I dunno if it can be or is set to “Contributors only” or not - you should be able to set that as the administrator of the repo.

I think I’d recommend it, since it seems like I (and so anybody, I guess) can edit or even delete pages you’ve already set up. :1

Well, the wiki itself is just a git repo, so I guess I could always reset to a previous revision, if someone did something nasty.

It’s just a shame that changes are immediately public - It would be nice if it functioned like pull requests, where I would have to merge it in before it becomes visible …

I think it’s a big barrier for contributors to wait for me to put them on the collaborators list, before they can actually make edits.

Leaving it all open may actually turn out to be a net positive.

For now, I’m ok with leaving it open.

I think an alternative would be to close off the main repo and make another repo for the documentation? You would then allow people to write on that one and do pull requests from that one into the main repo for articles that are good.

But yeah, you should be able to roll back wiki-style, so I guess it wouldn’t be an issue (though I’m not sure, myself; not too much experience with Github or Git in general).

In any case, I think I might do a “Using BDX” kind of basic walkthrough page soon.

The API itself should be easy to document and upload to the Wiki through automated means, right?

Yeah, I considered that, but then anyone who wanted to edit would have to know some basic git before they could contribute, and that’s also a fairly big barrier. For now, I can just look at the wiki repo, and see who did what - If there are problems I can reset to earlier commits (and also report malicious users, if any).

Feel free to put whatever you deem beneficial on the wiki (I trust your judgement). If there’s something I want to change later, I’ll consult with you, and we’ll work from there.

As for the API docs: A lot of popular generators seem to require heavily annotated source code, and I don’t like that - I think it clutters the source, needlessly, in many cases. I’ll do some research for a better tool, or I might just write something myself.

… Or, maybe we could just do it manually? I mean, with all the annotations we would have to make, to get the generator to spit out something truly useful, we might as well just write it directly into the wiki.

That’s something to consider, but then you’d have to manually update the API if you change the API (update a function to take a different type of argument, for example). Similarly if you change the Wiki page’s API syntax (i.e. you want all pages to begin with "API: "). I’m guessing an automated solution would be able to handle that kind of stuff trivially. It’s not SUCH a huge deal, especially if the Wiki is easily edit-able, but then again, it could prove problematic, I think…

But then again, if the API is written by hand and is well documented, then it could even stand in as a tutorial for some cases (i.e. you can easily inform the user of what a certain function does, and what it could be used for). The BGE API docs that have a little example showing how to move an object is an example, I suppose.

So I dunno. If it were to be written manually, what would the style be? One page per .java file from the source (i.e. API: Scene for the Scene.java file)?

EDIT: Also, where are the LibGDX (com.badlogic.*) dependencies? Are they downloaded somewhere? For using an external editor, would the best results be to download LibGDX and install it into the local JDK for the editor to use, or is there a way to point it to the LibGDX dependencies?