VBGamer

Pretty sweet game. I couldn't get past level one though since I couldn't fly that darn ship correctly =P

By the way, thats a pretty cool and very clever theory you have on the site about the gravity propulsion =)

Thanks for the feedback. There's a Tips section in the game and on the website which might be of some help. Generally, I confure the controls for a 3 button mouse, so the mouse hand controls the ship's orientation (mouse move), movement forward (right button), movement back (left button), and weapon fire (left button). This leaves the other hand to control sideways movement Q and W, which is extremely useful when dealing with the enemy ships and keeping asteroids in your view. Sideways movement can be used in conjunction with the mouse move ship orientation to partly circle around an enemy ship or asteroid whilst always facing it ready to shoot. This makes it easier for you to hit the enemy ships and difficult for them to hit you. In the old retail CD version we had included video game footage showing these flight ticks, but we had to sacrifice this for the downloadable version, to keep the download size small, pity.

Opting for gravity populsion rather than rocket propulsion meant that we could make the game different, using flying saucers, omnidirectional flying, and having an easy way to slow down in space. It also meant that we didn't have to worry about rocket engine and rocket trails special effects! which were difficult to do and get to look good on all Direct 3D cards and software rendering in 1998, when the original game was released.

Okay, I retried it and got to level 2 this time (yay! =P). Though, there was two little things I noticed that might make it a bit better: 1) If when the text about having to be in the sphere to be able to shoot is up then you go into the sphere, it should automatically go away. 2) The earth needs to blow up a bit faster, takes like a minute for the whole thing to happen =P Very good game though, especially for 1998.

Thanks for the feedback, this will be useful if we release a version 3 of the game, maybe next year. The game in its present state is quite different from the original version 1 which was release in 1998. Version 1 was pretty basic with simple low poly asteroids, and since then later versions added enemy ships, translucent explosions, fractal generated high poly asteroids, higher screen resolutions, slow motion destruction scenes, glowing asteroid textures, etc. I guess the moral of the story is don't be too ambitious for version 1 of your game, get something simple out so at least you finish it. You can always add improvements in later versions.

Any game done in VB should be freeware

Why do you say that?

Btw, why dont you enter it into the VBgamer X-Mas 2003 Competition? It's defently good enough ;)

I certainly do not agree that "any game done in VB should be freeware". This is like saying that VB programmers are second class citizens that are not capable of developing commercial quality games. VB is a professional development tool. VB is used by professionals, would-be professionals, and hobbyists. VB certainly isn't freeware itself. Commercial quality games can range from AAA retail titles at $40-50 developed by large teams, to budget retail/electronically distributed games at $5-10 developed by bedroom programmers. I do think that there is a place for commercial electronically distributed budget games developed in VB.

Since the Xmas competition is about showing "everyone what you've accomplished during this year", it wouldn't really be in the spirit of things to enter a game that we've been improving since 1998, and have only done a little work on this year. Anyway, thanks for your vote of confidence.

My reasoning behind "Any game done in VB should be freeware" is simply that VB is for beginners and newbies. VB is not expected to deliver advanced games people are willing to pay for because it wasn't designed for it. Therefore, any game done in VB that is even somewhat advanced is most likely very slow. If you ask me, sourcecode should be released with all singleplayer vb made games.

This has been gone over many times. Heck, probably some argument going on about it right now. Basically, VB is slower compaired to C++/C, yes. But, by how much is determined by the programmer. For example, I am always checking to make sure I optimize stuff with tons of different methods, but theres some people out there who leave millions of unused variables and functions lying aorund. Check out what Almar says about this, http://voodoovb.talosstudios.com/columnalmar1.html.

"VB is for beginners and newbies" - I agree that VB is not used in the professional AAA game development world, but VB is widely used by professional experienced developers in the business world on large projects. It is not used in AAA games mainly because it cannot be ported to PS/2, Nintendo, and because the majority of the game industry has the historic tie to C/C++. "advanced games people are willing to pay for", people are not only willing to pay for advanced games, they are also willing to pay for simple games too (e.g. Deer Hunter, Who Wants to be a Millionaire, budget games). "any game done in VB that is even somewhat advanced is most likely very slow", yes Quake 3 done in VB would be very slow, but I get the feeling that you are passing judgement on Close Approach without having tried it, on my PC (PII 450, NVidia GForce2GTS) it runs at 43FPS with the hightest quality options set and 640x480 mode. Close Approach, a budget game made in VB was released in 1998 the same year as Activision released a new version of Asteroids written in C/C++. Asteroids was given the AAA treatment even though it was just the same top-down 2D shooter as before. Close Approach offered something new, a 3D first person asteroids shooter, which in my biased opinion is a better game. I still do not think that out of these 2 games, one should be freeware and have its source code given away just because it was written in VB. Obviously you are entitled to your opinion and unfortunately this is a similar opinion to that of the free open source movement. It is not, however, my opinion.

Please don't take my comments in a negative way. But why would you make a commercial game in VB? You say you use a dll made in C, so why not just remake the entire game in C/C++? I know Vb usually makes far less development time, but Vb isn't even portable, restricting all VB games to windows only. I doubt you get very much money, if any, from the game, so why not share its source code with the rest of the vb community and help to better educate us all, especially if the game doesn't have online play.

Most people choose to go closed-source even if they are releasing the game as free because the fact that someone can steal their code and claim it as theirs. It is like the same for graphics. Do you think the people who created SNES graphics appriciate them being ripped and used in many other games without credit? There was a big discussion on this with ORE over at the QBite.nl forums when Deloria used ORE and refused to give credit. Also, many people believe in not sharing source and instead sharing ideas and examples so that way you still have to make your own game and know what you are doing, not just downloading source, changing it to "Made By..." and calling it yours.

"But why would you make a commercial game in VB?" If you want to make a relatively simple game for budget release for the PC Windows market only, then VB is a good choice. Close Approach uses Direct3D which also limits it to the PC Windows platform. "I doubt you get very much money", this is true. Between Nov 1998 and June 1999 we sold 43 copies at 8 dollars each with minimal marketing. We then made the mistake of entering into an exclusive 2 year publishing contract which meant we couldn't sell the game direct. The publisher eventually sold the game in CompUSA 3 years later but then went bust which meant we received no money even though the game was selling in CompUSA, and we lost 3 years of selling direct income. Now that we've relaunched the game for selling direct we're hoping for some sales - remember we're not marketing the game to VB games developer websites, but to normal games download sites which the general public use. "help to better educate us all" we have our own ideas about what is the best way to get a complete novice up to speed with programming 3D games and without giving too much away we are working on such a product for release later in 2004. This product will have example games and source, and should be easier to learn from than looking at the more complex optimised code associated with a commercial game. There will also be a free version of this product and it will not require the user to purchase a development tool like VB, VC++, or Delphi - it is therefore aimed at the PC game development community in general not just the VB game community.

VB is a wonderfull language for game development. I think that when more comercial and shareware games are released in VB, then people will be more open to VB as a tool for game development. For the people that buy games and play them, the language that the game is programmed in really doesn't matter to them. In my opinion, I think the most important thing for VB developers is to strive for quality in their games. Of course, the same thing can easily be said of other programming languages. But quality really goes a long way in making a game more "professional." Game programming is a nice hobby, and I don't see any reason why people can't make a few dollars doing what they love.

I don't see any problem in VB. It's easy and at the same time powerful. It can be slower, but not that much. It's WIndows-specific, yes, but that's not a limitation, as most PC users use WIndows. Look at these successful Windows games that sold a lot, being usable only in Windows and DirectX. Also, not much related to games, VB is (in my opinion) the best language for database access. There is no meaning in saying that VB insn't a decent programming language. I use VB and do not plan on stop using it. But if you don't like it, then go learn another, like C/C++ or even C#. But do what you think is the best! If the people here like VB then they will use it, if you don't then don't use, it's simple. But as a VB user I won't say it's not good.

On the subject of speed I forgot to mention that Close Approach is just compiled to P-Code. Compiling to Native code didn't give us much extra speed and wasn't worth the extra file size. This supports the idea that for simple 3D games, if you are using a fast underlying 3D accelerated engine (e.g. Direct3D) in the way it is supposed to be used, then the speed impact related to your choice of language for your game code can sometimes be quite minor. This also fits well with the VB/database analogy, i.e. a C++ front end to a SQL server database isn't necessarily going to get the data out any quicker than a VB front end to a SQL server database - the real speed improvements come from looking at how the underlying database engine is used (data, tables, indexes, stored procedures etc) and how you interact with the database engine. Likewise for 3D work, the real speed improvements come from looking at how you use the 3D engine (choice of APIs, textures, low-polygons, etc).