It's good to get this information, and thanks for the explanation.

just as a general suggestion though, ---- probably for your future racing game, had you considdered using bgt?

Firstly, Bgt uses a C++ based language, and therefore if your already familiar with C++ cyntax you'll be off to a start. Secondly, and more importantly, Bgt interacts with uptodate windows components in order to do things like playing sounds, creating multiplayer servers, managing in put etc, also, sinse it's maintained by Philip Bennefall it'll remain uptodate.

Thirdly, sinse Bgt already interacts with the microsoft components, you don't have to. This means instead of using interfaces in direct X or direct play which are not taylored for either a blind programmer or the creation of audio games, you can use something which is! designed to create audio games and concentrate on th business of making a good racing game, ---- as your planely able to do.

I do admit it's rather early days with bgt and nobody has really disgned a game as complex as top speed with it, but from what I understand of reading the manual, and from Philip's own games, the technology is there just waiting for someone to use it.

Obviously, there is a financial isse if you are considdering the full version of bgt, but if you were thinking of a commercial game for your next title anyway, maybe this could be factored in to the decision sinse obviously if the programming end of things is easier for you, you are more likely to make a better game and indeed add some of the complex features which people might want.

Obviously, I am not a programmer, and don't have as much knolidge of bgt, it just did scrike me when reading your post that your use of C++, and your concern about windows compatibility and components are both things wwhich might make bgt a good idea, ---- thouh i freely admit I could be wrong on this.

Eitherway, please let us know about anything your planning, and I'll be glad to write news.

I will admit racing isn't personally my first choice of game genre, but I have played several topspeed games and can very much appreciate them as very well put together indeed (the options for street adventures and car creation very much impressed me).

And maybe this post could be used too encourage people to strive to program audio and complex games for the audio gaming community.

Sorry about the double post. I forgot about that link. My falte.

Hello everybody,

Thank you for your explanations.

I'm personnally don't like to pay for a game. I'm considering I'm not hard core gamer enough to do so. I'm a casual gamer who like to play various types of games for a while, but probably not enough to justify an investment.
I enjoyed Q9 demo, entombed demo, rail racer demo... but I hadn't mood to buy them.

I'm still a student, so I haven't a huge amount of money. If I were working and earn my life, perhaps I would consider donating, or buy more often something.

However, I would be happy to help playing in the dark in programming, or in beta-testing, as long as I have competances and time to do so.

I'm strongly opposed to MS visual things because I consider these tools to unaccessible, too slow, too hard to manage to do something with. I generally prefer command line tools, far too easier and much superior...
I can do C/C++ with MinGW, or java. All that without any IDE outside windows notepad and my own improved notepad program I created. BGT would probably not be a problem to learn, it appear to be very simple.

I'm not for BGT. The problem I see with BGT is that  it volontarily completely hide multithreading problems, and network is restricted to minimum. In one sens it is good, it is much easier to do simple games, but for a game like topspeed which is so complex, I'm not sure it would be a good choice. I'm afraid that the resulting game could be slow or instable.
My router has problems with UDP nats so I'm unable to host a topspeed game and any BGT-based game, but I have no problems with TCP so hosting a SoundRTS is okay for example. I'm sure many other people do have the same problem. I don't understand why UDP has been chosen for BGT.

Another problem I see with BGT is debugging :
Keyboard input is not correctly managed in all BGT titles when jaws is running, because of its keyboard hook. So if you want to try your game efficiently, you have to set it in sleep mode.
But if you are in sleep mode, you are no longer able to read an error message which would pop up.

you know, aminiel, most games do not work with Jaws precisely of the same reason. In fact, I can't remember even one that I have tried with it and could keep Jaws running. so that really is not a problem as you can simply make your messages be read through Sapi or displayed in a message box, which should result in Jaws loading up again.
I'm no programmer but I still think there is no situation where you would really need multithreading for a game with BGT. I can't even think of a game genre that could not be created with it. What do you think cannot be done with its network object so far?
Sure, BGT is singleplatform and seems simplistic in its nature but these are two of the most crucial aspects of its very design. if you want multithreading or multiplatform portability, you can certainly go ahead and learn C++ but there is a high probability of you eventually facing similar trouble as the PIDT development team right now. What I like the most about BGT is that it actually managed to teach me how to code. I was not able to understand almost a single sentence of the Autoit tutorial, for instance. In a sentence consisting of 6 words, 5 of them would be too technically oriented in nature. the writing assumes that you do already have some basic knowledge, which I didn't at the time. However, after having mastered BGT, I am confident in my ability to pick up a C++ guide and begin learning straight away and relatively quickly, if my intentions and ambitions ever grow beyond the wish to develop specifically windows based audiogames. Until then, I am happy with BGT. :-)
Lukas

Hello there,

I won't fill this thread with BGT advertising, but I just wanted to point out a few things. Multithreading will not make or break a game. Sure it can improve speed for things such as timers, as the timer can continue running even while other code is executing that might be taking up CPU cycles. BGT handles its timer functionality in a separate thread. Q9, for example, has all its game logic in a single thread and runs fine even on a slow netbook.

As for networking, TCP is an absolute impossibility if you want to write high speed action games, where as it works just fine for games where 100 % real-time is not a requirement. BGT's network management is completely asynchronous, which means that it will not slow down even if you have a lot of traffic or a lot of connected peers. For more information about the networking in BGT, please check out:
http://enet.bespin.org/Features.html
This page also explains a little more why TCP is generally unsuitable for high speed games.

The problem with DirectInput locking up Jaws occurs in a lot of audio games on the market today. It is generally accepted that it is not a problem with DirectInput or with the design of the individualg ame but with Jaws, while it is also acknowledged that DirectInput is a very fast and efficient way of working with the keyboard. I could replace direct input with, say, WM_KEYDOWN/WM_KEYUP window messages, but I would risk slowing things down considerably that way.

Finally, whether a developer writes good or bad code really is not up to BGT or the design of its interface. If you want callback/event based functionality, it is very easy to wrap the actual engine calls in your own classes. I personally prefer a more procedural style API for the lower level functionality, where as I tend to write class architectures for high level game logic. This is my personal preference, but BGT allows for both and I am not campaigning for one or the other.

I am not saying that BGT is perfect. Far from it. I am merely trying to make a few points about its design a little more clear for those who are curious.

Kind regards,

Philip Bennefall

Here are a few points, just so you know our thoughts on the matter.  Please keep in mind this is by no means a final decision or anything "solid".
-  The debate "DirectInput vs. Windows message handling", at least for keyboard input, is rather pointless.  Various sources claim DirectInput uses these Windows messages anyway, but besides that I found that DirectInput can even be slower and more quirky than Windows itself.  This is especially true for "polling", a system I have long abandoned and that will probably not make it into the potentiial new racing game either.
-  Multi-threading is a great tool for developing games.  Not because of speed and performance considerations, but because you can do multiple things at once (i.e. asynchronously).  This is in most cases preferred over synchronous implementations.  As an example, if you try to connect to a multi-player server in Top Speed and none is found, you'll be literally stuck for about two minutes.  Multi-threading can help there.
-  In most cases, the only active loop in an application should be the message loop (which doesn't run all the time anyway).  Top Speed is based on the old concept of looping and finding out what to do in these loops.  For a new game, we plan on having the operating system (or a third party library) calling the game if it needs to do something.  This creates a far more stable application if it's done right, and saves resources too.
-  We are not sure about the platform or platforms to target with this new game, if it's going to be written at all.  On one hand there's a lot to say for being multi-platform, on the other hand a native Windows-application, written in native C++, is faster and (once the fundamental code has been written) is easier to maintain and add upon.  Mind you, something like .NET could do the job just as well, it's not like your average audio game requires a lot of computer power.  We're considering C++ because we have at least a few years of experience with the language, and because it allows you to do virtually anything you can do on a given operating system.
-  TCP is bad.  That is why Top Speed uses UDP for all non-critical packets in multi-player mode.  As a simple example, the TCP overhead for sending your player data will usually be more than the cost of sending the 27 bytes that actually make up this data.

Alright, I hope this clarifies things and allows for further discussion.

It is not when playing a game. But it is when testing/debugging it.

Sleep mode is a great feature: you turn jaws off only in a particular application, so that you can go back to something else if you want. Some are useful even during a game: quickly exchange an IP address in MSN, call somebody on skype, etc.

Philip, thank you for the explanations on why UDP and not TCP. In fact you have convainced me, I will take a look at enet library.

I continue to disagree in the DirectInput vs WM_KEYDOWN/UP debat.

ABout multiplateform, I see that more and more people are moving from windows to mac. Platform independance appear to become more and more important.

Perhaps should we consider using only multiplateform libraries :
- SDL for windowing and input, unless you have something faster to propose
- why not that enet for networking, it looks not so bad
- OpenAL+tremor for audio

The only remaining thing is TTS... I don't know how it works on mac at all, and speech dispatcher is quite slow usually.

Philip, a good thing for you if you could add that into your BGT: the ability to use 3rd partie C/C++ DLLs. So that advanced programmers are not constrained in the API you provide. I don't know if you could add LoadLibrary/GetProcADdress for that, and I don't know how it is possible to translate C++ classes into AngelScript ones.

Being multiplateform would also be an excellent point for BGT, but I have the same problem as you: I haven't any mac to try out... that's why my own games are not multiplateform too.

One thing I found is that modern hardware is more than capable of quickly processing keypresses, audio, and everything else an audio game relies on.  As an example, look at how fluent .NET applications run these days, even though they use a language that is interpreted on the fly.  I'm not saying we should all go and develop something as quickly as we can, even though the code may not be optimal, absolutely not.  I definitely support the idea of writing efficient code, even if it seems harder or takes longer.  But modern computers certainly make life a lot easier.
Secondly, I'd like to point out that we're still wondering if the audio games community would like (and pay for) a new racing game.  So if you have any more thoughts on the matter, go ahead!  So far I'm liking the discussion.

Top Speed started as a hobby project, and I don't think its primary goal was to provide a realistic racing experience (much like Troopanum doesn't strive to present you with realistic starships).  The potential new racing game would definitely incorporate more of these concepts to make both the vehicles as well as the racing more realistic.  I've always been a big fan of games that try to simulate a real life situation, so this is certainly important to me.
Dark's post touches the very center of our dilemma.  Top Speed's life is nearly over, it would be stupid to make it more realistic, a game from scratch could do the job faster.  We haven't made any money with Top Speed, but given how much time we spent on it, we feel that future games of this size and complexity should be released as shareware.  We'd love to develop one, but we don't always have the time.  And when we spend time on the game, we'd like to receive something in return, if only because besides studying and programming games there's not much room left for further projects to raise some income.  But if we don't spend a good deal of time on the game, it won't be worthy of being paid for (I would hate to release a game that does less than Top Speed 3 as shareware).  This is why I (and I think the other developers too) may first release some smaller games, games that would certainly not cost more than $10.  Then, if or when we have the time and feel like doing it, we can always take on this vast project of making a new racing game.  This will also allow us to decide on programming language, and it would allow the community to finally enjoy Top Speed 3 in its final form.
Now, for a final note, please remember that all I said here is how I see things.  This is not Playing In The Dark's opinion, nor that of any of the others involved in the creation of Top Speed 3.

I actually agree with philip, progress in games is a great insentive for people to pay, sinse it's one thing to have a game which you complete and then it's done, it's quite another to have a game you can play and get better and better at.

Then, there's the matter of custom content, sinse if you've got game users making extra stuff to do in the game that just provides all the more reason for someone to buy.

I personally have no problem with people creating shareware games (one reason why this forum is so adamantly against game cracks), so that the time and trouble you spend, as well as any money you need to spend on buying resources like programming libraries gets some recognition from the game's players.

It'd be interesting to see what smaller games you came up with.