I've seen a few mentions of Blitz in the forums and finally decided I would go check it out. I have to admit this language seems taylor made for creating games. Without a manual and using the demo product I was able to get some basic animation running in no time.

Has anyone here ever used Blitz to produce a complete game?

I'm planning on buying the product today and I would like to know if anyone has success or failure stories.

Well I can see one thing I don't like, arrays are global. You can't use them inside of a Type definition and you can't pass a reference to one into a function. This means you can't have a generic routine that does something to a passed in array.

hehe I went to www.retro64.com to try out some games, just to leave it again, when I remembered how tedious installers are for small puzzel games you'll just play for a short while. I guess Webstart, Applets and Shockwave has made me lazy

Anyway that would be something talking against Blitz, but that off-course is a subjective objection. As princec pointed out in another thread, it seems like most non-java people prefers installers.

2) Flexibility - seems like all the examples I look at are pretty damn similar looking and feeling. Although this could just be down to the developer...

EDIT: 3) Can't find any support for standards. No XML processing!!!? Web connections would have to be implemented by hand?

EDIT: 4) Can't find any support for database access?

EDIT: 5) Doesn't seem to be as multi platform as they'd lead you to believe. Lots of features seem to disappear with the loss of DirectX(etc..). This probably doesn't matter to Cas but it might bother some folk.

EDIT: Thought I'd found a way round it all by using custom shared libraries. However, the spec only seems to work for windows DLLs and even then the calling syntax appears to be a nasty hack. Still to push on..

That said, I think I'll take my laptop time out as a reason to go off and play with Blitz

EDIT: Plus side, looks like I could write a quake 2 clone in this in a matter of days! Yay!

I'm having quite the little riot converting some of my java utils to BlitzPlus. I can already do full screen or windowed, custom mouse pointers, fixed frame rates, draw strings using my own custom bitmap fonts.

Certainly Java has advantages in a number of places however for the type of games I want to do Blitz is looking like my "final answer". BTW did anyone look at the Cosmo Bots game, it is very nice.

OO stuff

Look up the Type keyword, in BlitzPlus at any rate.

Note : I saw an OGL binding for BlitzPlus so this would be like Java and LWJGL.

I've been playing a lot with DarkBASIC. I've been impressed by it, but frustrated at the same time (I guess it's like that with anything). I haven't tried BlitzBASIC to compare, but you might try it out to see what you think.

EDIT: 3) Can't find any support for standards. No XML processing!!!? Web connections would have to be implemented by hand?

EDIT: 4) Can't find any support for database access?

EDIT: 5) Doesn't seem to be as multi platform as they'd lead you to believe.

Basically the same advantages/dis as Flash then: it's damn fast and easy to get something that looks quite good going, but every time you try to do anything even remotely clever, time-saving, re-usable or (god forbid) slightly complex you pull aside the curtains and find a brick wall instead of a window (a la Matrix).

i.e. it's an excellent proposal at first, especially if you "try before you buy" rather than examining/evaluating on spec and/or have no "deep" example use-cases to test it against, but then you soon get more and more frustrated - unless your inventiveness and time are both quite small and you can stay within the tiny playpen without noticing how small it is.

This happens to have been my main concern about Dark back when it was new. I haven't even tried Blitz, beyond a ten-minute glance, so I'm going on what you're saying here,but it does sound a familiar experience.

I know a little of DarkBasic. Don't know how similar ut is to Blitz. But those packages have something that is at the same time a great limitation and a great advantage. Its very easy to start working with but they also made it very hard to do complex things. For simple games that don't require complex terrain algorithms, complex AI behaviors or a scene graph its the right tool.

File sizes of Blitz games are tiny. They are generally an order of magnitude smaller than having to deal with an embedded JRE, and a considerable percentage smaller than a JAR file.

DarkBasic is fairly insignificant compared to Blitz - Blitz is focused exclusively on delivering the goods. If you're doing XML processing, you're not writing a game. Look again, and look harder this time. There is no tool on the market today that is more effective.

Basically the same advantages/dis as Flash then: it's damn fast and easy to get something that looks quite good going, but every time you try to do anything even remotely clever, time-saving, re-usable or (god forbid) slightly complex you pull aside the curtains and find a brick wall instead of a window (a la Matrix).

I think this is an excellent summation of the problem with those "super weapons" like Blitz.

What some of you might need isn't Blitz but middle-wares. A rock solid exporter/importer for your great 3d models into your app, including boned animations etc. A smart data flow control system like there's one with Axiom (the Dotnet version of Ogre). Speedtree. Physics engine. And a lot more.

Look again, and look harder this time. There is no tool on the market today that is more effective.

Want to be any more patronising? I'm looking perfectly hard and being pretty impressed. There are significant limitations already tho.

Using XML => Not writing a game, you look harder.. theres plenty of good reasons to be using XML in games.

The executables of Blitz3D at least are not small, in fact its noted in their own FAQ that they are pretty big compared. Not that this really compares to the JVM.

I'm having a go at a new version of Martian Madness in Blitz3D as we speak and its an interesting experience. More than any extended Java based functionality I'm missing real classes/objects. This pseudo OO just isn't really fitting in with my over zealous Java tastes.

Hey now, you know me - I'm a Java zealot If I'm going to patronise anyone it's going to the be the Game Technologies Group who appear to have sat on their arses for 6 months without anything to show for it...

Quote

Using XML => Not writing a game, you look harder.. theres plenty of good reasons to be using XML in games.

There may be but you generally find that XML is total overkill for most uses in games. And if it really hurts you'll also find that Blitz interfaces nicely with C libraries and is easily extended with plugins.

Quote

The executables of Blitz3D at least are not small, in fact its noted in their own FAQ that they are pretty big compared. Not that this really compares to the JVM.

I'm having a go at a new version of Martian Madness in Blitz3D as we speak and its an interesting experience. More than any extended Java based functionality I'm missing real classes/objects. This pseudo OO just isn't really fitting in with my over zealous Java tastes.

I do find though that progress is far easier to achieve when you have fewer decisions to make. In fact I even started using Java like this - deliberately cutting down on pointless object orientation, using more "globals", etc. End result: games get finished faster. Blitz tunes this to an extreme. Some OO is nice, and this is present in the new BlitzMax (along with garbage collection).

Blitz also adds scene graph functionality and toolage far superior to anything currently available in Java (an idiot can write a 3D game in Blitz).

Hey now, you know me - I'm a Java zealot If I'm going to patronise anyone it's going to the be the Game Technologies Group who appear to have sat on their arses for 6 months without anything to show for it...

And then this ...

Quote

I'm just wondering here - what's Java got to compete???

Cas i think you deserve your ass being wiped for that late statement.

Quote

There may be but you generally find that XML is total overkill for most uses in games.

Maybe XML is a total overkill when being used through the Java xml libraries but a text data format similar to xml is a choice for many comercial games. Look at the data files used in Doom3. Pak files are just zip files renamed pk3 to make bundles. Its possible to rename then to .zip and look inside.

And suprise suprise every data file that is not a picture or a sound file is a text file with definitions. This includes entity data files, meshes, animation data, configuration files, map files, everything uses the same text format similar in structure to xml. You can even have inheritance relationships between data.

Quote

Blitz also adds scene graph functionality and toolage far superior to anything currently available in Java (an idiot can write a 3D game in Blitz).

An idiot can write idiotic games with Blitz better than he can write them with any other language. If people want to make a good game they need a good game idea and that is not the programming language that is going to do the miracle. Its how much games people play and how much they assimilate of the game design and mechanics of game classics that will help them. The tools only make it easier or not to realise that game idea.

Man don't even say that again. That is a sacrilege for two reasons. One because this is a java forum and two because this is a games forum.

Maybe XML is a total overkill when being used through the Java xml libraries but a text data format similar to xml is a choice for many comercial games.

When you use XML wisely it isn't overkill: using it via the Java lib is straighforward and handy, even for simple games when they need to load/store any kind of hierarchical data. I wouldn't use it for plain flat non-hierarchical data files. For other data not using it means some kind of re-invention of the wheel... (and it takes time)

Quote

An idiot can write idiotic games with Blitz better than he can write them with any other language. If people want to make a good game they need a good game idea and that is not the programming language that is going to do the miracle. Its how much games people play and how much they assimilate of the game design and mechanics of game classics that will help them. The tools only make it easier or not to realise that game idea.

That's the point, really. Excellent summation!

I know why Cas' complains and I understand his motivation well: it's because today, writing even relatively small games can be tedious and take a long time. Unfortunately, today's computers/consoles/pdas aren't as simple as an Sinclair Spectrum, C64 or CPC has been... For many reasons.Like Cas I wished there was a super language allowing to program games by pressing some keys... but that's just fantasy. Remember this "Shoot'm up construction kit" on the Sinclair Spectrum? It remembers me to Blitzbasic (of course more complex) but it really sucked (Ok, even an "idiot" could produce "something" with it, but no game). :-)

Many game (and application) developers meet this increased complexity by using more and more middle-wares. A solid and comprehensive library for most dev tasks like the Java one is a good start. However there have to come more specialized middle-wares to the Java world, in particular for games.

Now come on, I thought you guys were being really open minded earlier in this thread, it now seems to have degenerated to:

Blitz Basic is crap because

- Its Basic - Its not Java- We write games that are much more complicated than anything you can do in it.

Bombadil was dead on so far to my experience earlier, its a tool. Its suited for some games not for others. It just happens Cas is viewing it from the Indie market and Blitz is very very good for creating games of that scale.

Thats not to say that we couldn't learn alot from the way Blitz is put together. If I could have the powerful scenegraph and tools I've been playing with in Blitz3D along with a language as great as Java, and of course finally a VM the size of a walnut which I could add and remove bits to as I felt my world would be a happy place.

So, come on, one of the things I really value about using this forum is the ability not to be close minded. We're so used to the assumption that "Java is too slow" lets not add outselfs to that camp.

Hear hear I'll just take back that ass-wiping and try and rephrase myself here:

To an aspiring game developer the initial choice of tool goes something like:

- Blitz- Java- C++- C#

Both Java and C++ require some serious buggering around before you even get a sprite on the screen. Java is more or less entirely useless until you plug LWJGL into it in the first place but at least it's easier than C++ by quite a huge margin.

C# is a major competitor to Java in the games space and it is already, ooh, about a light-year ahead in functionality. You get C++ power with its directly integrated DirectX and you get Java simplicity with its syntax and behaviour. But Sun are lucky! Microsoft have chosen not to distribute the .NET runtime with XP so far, so it's just as unlikely as Java to be used by games developers for the sake of compatibility. Remember - if it don't run, it don't sell.

But when your primary concern is getting a 2D or 3D game up and running and working and selling in the minimum amount of time, and make no mistake that's what the business is about, you just can't ignore Blitz. I couldn't give a rat's arse about the syntax "not being as nice" as Java - you get used to it. Or the relatively primitive OO capabilities. You get used to it. Or the lack of XML processing - the smart observer really tracking this thread will have already looked in the Bugatron installation and discovered that all the data files were once XML.

The huge extra size of embedding a VM with your game is just a final kick in the spuds. (Webstart still sucks, for the masses)

So Sun's trying to attract all these game developers, and old and new alike can turn around and sniffily ask, "So? Why should I switch from XYZ to Java when Blitz is doing it better already?"

Thats not to say that we couldn't learn alot from the way Blitz is put together. If I could have the powerful scenegraph and tools

We definitly could so. And not just with Blitz but also with commercial games that offer a excellent editor and modding resources. I sugest looking inside the Doom3 editor and the downloadable sdk. The TESCS (from the Elderscrolls game Morrowind) is also interesting to look at. But the one im waiting to examine is the HL2 engine.

I've been playing with in Blitz3D along with a language as great as Java, and of course finally a VM the size of a walnut which I could add and remove bits to as I felt my world would be a happy place.

The size of the java vm doesn't really bother me. This was discussed plenty a couple of months ago in a thread made by that univ teacher who was doing a book on java games.

As for the language im an OO fanatic since i first knew about the concept. I knew from the beginning that Java was not a complete OO solution and it is lacking many important features when compared to Eiffel and other stronger OO languages. But even knowing this, when choosing a working tool we have to be persistent with it. It's not a good idea to drop whatever tool we've invested so much learning for something that looks like its shining brighter at the moment.

Im not being hard headed here im just being persistent with my tool of choice. Besides there ae other things Blitz doesn't offer. For instance an IDE like Eclipse; a tool for automatic code checking/correction like JML; a package like JUnit to create tests; all the UML tools available for java. This may look like an overhead for a simple game but for a bigger one its a "pain in the ass" saver.

Its possible that Blitz scenegraph may be very good, maybe better than the one used in other solutions offered in Java. But wouldn't it be possible to wrap it in a couple of Java classes and build it on top of one of those opengl bindings for Java ? I think that what people are asking is something that lets them easly and fast create a functional prototype of a game and then throw it away after being studied and tested.

Zingbat's and Kev's emphasis on the OO aspect is important I think. 1) Once you're used to use a full OO language like Java/Cpp - and aside Cas most of us are just partly/hobby game devs who use OO at day/part-time anyway - you'll naturally want to write even so called smaller games in a solid OO way.2) You'll want to approach a so called smaller game the same way you'd approach a 10 man-year game: from a development point of view it's the very same, it's just more thin and needs less graphics, resources, etc which I like a lot.So yes, it's again the tool question: once you're very good with your OO tool (maybe you're even a master) you'll be able to use it the same way for your smaller game - provided there are some appropriate middle-wares: JOGL/OpenGL_binding, Xith, Ode, ... depending on your game's needs.

So, for me the "fast" of Blitz doesn't mean the same "fast" which is important to me: to master an OO language; the better I know how to use that tool the faster I'll develop my game with it - and my daily business app by the way (that's the funny part of it: the things you learn with your game you can use for your apps and vice versa, this also applies to XML).

As of Cas saying Dotnet would be a light year ahead of Java: good joke! It's even complicated to make your Dotnet installation to use the correct managed DX version (forget to embed a Dotnet VM with your app)... Starting a Java plus Jogl application is very simple on the other hand. But that's another topic. Back to Blitz... ahem, Java. ;-)

By the way: the idea to embed a certain 3d scengraph inside a language looks like a bad idea to me. A scenegraph is a middle-ware and it depends on your game which middle-ware fit your needs best.Carmack wouldn't want to use a scene graph based 3d API like Netimmerse/Gamebryo for his indoor games... (and not for real-time terra-forming games, etc)

Writing a Blitz like library is definitely do-able with current Tech. However, its not here and each and every effort in this direction aims to get this really high end solution which is for most indies worthless anyway.

The VM size isn't an issue for large deployables, I agree. if your distribution is 100MB who cares how big the VM is? However, when you're attempting to sell games via the net with no CD distribution you're going to be pushed trying to get folks downloading demos of things they don't already know are great (i.e. people will of course download the 90 meg Doom 3 demo cause of the hype).

That comparision was *so* off and you knew it, Cas. The biggest chunk of SE is it's media. 12.5 mb of (byte)code would be pretty gigantic. Maybe you would get that much for something like photoshop, but not for a small game.

---

Ok. Back to the topic. Blitz. Well, it's basic and I'd written that stuff alot in the past, but I really really hate it.

Do you still remember why Java is so nice compared to C++? Because you aren't able to do those silly hard to track bugs. Because you won't crash your PC with a small typo or because you forgot a small detail.

I *heard* debugging in Blitz is a major PITA. Well, I won't take a closer look, because I won't use it anyways.

When doing a game you spend different amounts of time for different tasks. When changing one tool in the chain there will be a change in different places. Exermine if it will really make a difference at the end. Maybe it would be worse.

You have those once in a moon tasks for loading media or wrapping entities into objects. Loading media in Blitz is of course easier (from scratch), but you won't write that stuff too often anyways. And if you need that stuff you can either use a ready to use class or reuse some code blocks. For example I spend the last few weeks with writing game logic. Control flow, collision detection/response etc. This kind of stuff isn't less work in any language. If/else, loops etc. What's important there is the turnover rate (how long does it take to test a change).

With Janino that turnover rate is down to 1.5 seconds. It won't be any faster in Blitz (guess it's much worse) or C++/lua (about the same).

I'm really pretty much down to that amount of work, which needs to be done in any language/script language combination.

Actually the 12.5 MB is apparantly all executable, the media is more like 49 MB, I quizzed Cas on this earlier

Quote

Control flow, collision detection/response etc. This kind of stuff isn't less work in any language. If/else, loops etc. What's important there is the turnover rate (how long does it take to test a change).

See, there we go. Collision detection is actually one of the nice things I've found so far. A basic version (good enough for most Indie type games is already present).

Now I agree that "control flow" or "game logic" isn't going to get easier in any language. In fact it'll be easier in a lanaguage that supports OO.

However, I'm not sure I agree on your weightings of what takes up the time and causes the bugs. Why do we use scenegraphs and loaders for 3D rather than write the whole thing ourselfs? Simply because getting a 3D world working efficently and getting the media in isn't actually that easy. Getting the game to look and feel the way you want is at least half the battle. Ok, the game logic is still a big chunk.

Again, I'm not saying Blitz is a Java beater, just that if we just dismiss based on hear-say (debugging in Blitz isn't the greatest btw ) and conjecture we're missing an opportunity. From playing with Blitz I'd consider writing my next support library in a different way. I was wondering however quite how much of this stuff JME has already...

>Collision detection is actually one of the nice things I've>found so far. A basic version (good enough for most Indie>type games is already present).

Hum yea, a basic one. I wouldn't even mention a basic one, because it isn't much work (if simple rect/circle overlap checks are enough... AWT has that stuff).

>Why do we use scenegraphs and loaders for 3D rather than>write the whole thing ourselfs?

Yes, we use that kind of things. Therefore we don't have to write that stuff again and again. Exactly my point

Blitz is like any other language the only difference is that you start with a pretty usable framework. For a Java2D game it's copying some files over and paste a block of code... and I can start right away. Everything left to do is writing the game's logic and wiring pieces together. I don't really see what I could gain there with Blitz.

[Note: right now I'm doing 2D games only and it won't change that soon]

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org