A Literal Programming Language

#61 @Will: But you still have to know how to use 3dsmax or any modelling program, and to achieve the quality of the graphics done in moves you need years of experience. Same for games, i you have no clue on programming you shouldn't be making games. Some things are left for professionals, others are meant to just play games.
As to your physics post, almost every game doesn't use real physics, they are just simulations of physics made to make the game fun to play. Example? Tribes is the closest example I could give, the skidding on the terrain wasn't real, it was actually a bug in their physics, that made it a lot of fun to play in the end. So, do that with a predefined physics system like Havok that is meant for realistic physics... you can't. Same for flight sims, you usually make a fake physics system depending on the target you have for your users, a fun combat flight sim won't have real physics at all, and it would need to have it's own predefined physics engine. Same applies to any area of game dev anyway, you want to do a new effect, blown, your engine doesn't have it. There's no way in earth a single game engine can cover everything you will need. Heck even doing games with Torque always needs modifications to the engine. And even if you remotely included all the stuff that could be used to make almost any game, your game would suck, since it would need dual cpus and a gig of ram to run a game that could be made by coding it in c++ from scratch and run it in a Pentium 3. You have a lot of imagination, which is good, but in the real world things don't work like in the etereal world.

#62 Yeah, every game I've worked on so far had to be written from the ground up, whether it was an xbox, PS2, PC or one of my current blitz games. THe engine had to be designed and written to meet our specific requirements.

BTW Will I sent you an email earlier, don't know if you got it. Used the account in your profile.

#63 @Will: But you still have to know how to use 3dsmax or any modelling program, and to achieve the quality of the graphics done in moves you need years of experience. Same for games, i you have no clue on programming you shouldn't be making games. Some things are left for professionals, others are meant to just play games.
As to your physics post, almost every game doesn't use real physics, they are just simulations of physics made to make the game fun to play. Example? Tribes is the closest example I could give, the skidding on the terrain wasn't real, it was actually a bug in their physics, that made it a lot of fun to play in the end. So, do that with a predefined physics system like Havok that is meant for realistic physics... you can't. Same for flight sims, you usually make a fake physics system depending on the target you have for your users, a fun combat flight sim won't have real physics at all, and it would need to have it's own predefined physics engine. Same applies to any area of game dev anyway, you want to do a new effect, blown, your engine doesn't have it. There's no way in earth a single game engine can cover everything you will need. Heck even doing games with Torque always needs modifications to the engine. And even if you remotely included all the stuff that could be used to make almost any game, your game would suck, since it would need dual cpus and a gig of ram to run a game that could be made by coding it in c++ from scratch and run it in a Pentium 3. You have a lot of imagination, which is good, but in the real world things don't work like in the etereal world.

#64 A lot of modern game engines arent that different to work with than working on movie graphics. It's not uncommon for people to use a 3D app as a level editor these days. Thats the way I prefer to work, but it does require a more technical artist, and a team thats willing to design en engine together making the best use of each others skill sets.

#65 Yep, that's my point exactly... people/developers would rather work within a 3D modeling program to make everything from levels to characters... and to define properties from within the editor too. This is streamlining your pipeline for production... you can work faster and focus on what's important: gameplay, art/sounds and design.

...oh, and I didnt get an email from you that I noticed, sry.

About gameplay... Coding does not equal gameplay. ie. you do not have to be able to code to define gameplay mechanics or make them work. For example, lets say that in my game I wanted no reloading to make for faster gameplay... well, then I would go to this interface of this engine I'm talking about and I would simply click the "weapon reload" check box to turn in off. See, I didnt change any code, but I have fundamentally changed the core gameplay of this game by doing this. I'm sure you can think of many other possibilities.

@Xavier:

Quote:So, do that with a predefined physics system like Havok that is meant for realistic physics... you can't.

So you are saying that Havok couldnt simulate the effect of skidding? Or coming to a slow stop? I highly doubt that.

Quote:Same for games, i you have no clue on programming you shouldn't be making games. Some things are left for professionals, others are meant to just play games.

Wow, that's really condescending... hehe

Xavier, that's like saying, "If you don't understand the internal workings of a camcorder, you shouldnt be trying to make a movie with it."

or... "If you don't know how the internal combustion engine works, you shouldnt be driving a car"

The whole point of an engine, is to create an abstraction layer, an interface through which you can more easily create a game. Ultimately this means coding will not be necessary to make even a complex game. This isn't my imagination, this is where everything is headed. So prepare yourself, things are changing.

#66 @Will: Absolutely not, your comparison is plain wrongs. Both camcorders and cars are meant to be used, not created or tweaked. Games are meant to be created. (in the context at hand of course, which is game development, not playing)

As for your weapon example, then your game engine has to contemplate weapons, any kind of weapons, with 1,2,3,4,5, infinite shooting modes, auto and semi auto firing, laser guns, and not to mention melee weapons... Good luck getting it all done with an exe that is less than 50 mb. It seems like you want an all in one game.

#67

Quote:Yep, that's my point exactly... people/developers would rather work within a 3D modeling program to make everything from levels to characters... and to define properties from within the editor too. This is streamlining your pipeline for production... you can work faster and focus on what's important.

I see this viewpoint as a valid one, but I don't agree. I actually prefer playing with the game and adjusting things on the fly in-game and define properties in script.. the idea of working entirely in 3dsmax or working with a team that did that would drive me nuts. Different strokes for different folks.. I see how it could be valuable, but having seen it done both with in tool editors and in engine editors, I prefer the in engine way. it is way more efficient from a development standpoint (or at least it is for us).

Much of what the workflow of the TGE is about is about streamlining production. The result of what you get is the result of a bunch of people working toward the goal of a development environment that could be shared across projects and teams for a large development studio.. and the TGE s actually the thrid iteration of that process (tribes and starseige being one, tribes 2 being 2,)

moving the tools to the way you want to work may be better for your pipeline, but not for everyone. If I was tapped to design a pipeline for a studio I would not put forth an idea that had level design as part of the art pipeline using 3rd party high priced apps..

#68

Quote:About gameplay... Coding does not equal gameplay. ie. you do not have to be able to code to define gameplay mechanics or make them work. For example, lets say that in my game I wanted no reloading to make for faster gameplay... well, then I would go to this interface of this engine I'm talking about and I would simply click the "weapon reload" check box to turn in off. See, I didnt change any code, but I have fundamentally changed the core gameplay of this game by doing this. I'm sure you can think of many other possibilities.

I see the value in this as well.. but in this instance, the script change to make this happen is easy. It is a one line change (actually adding a comment in a script file).. from a workflow standpoint, something like this is simpler (for me) and more efficient to do in script. It may not be elegant, but it actually takes less time. As I am doing this all the time (tweaking values in scripts).. I can say that I actually prefer to do this in a text editor than use any built in tools.. when editing things in mission files, I tend to edit the scripts directly (for color values, fog values, and whatnot) as I just find it easier to do.

For our games, much of what we do is custom.. so adding in a 'widget' to make it easier to edit would take extra time.

and then there is where to add it.. seems that both you and adrain would prefer this to be out of the engine. I totally disagree with that philosophy as it relates to game production. This is not to say I don't want a nice in engine particle editor.. or better tools, it is just definfing what is 'better'. Easier to use is relative to who is using it. Many of the tools and conventions that exist in the TGE are the way they are because they were created that way for a particular reason. Some of these reasons were to speed up the production pipeline.

from a personal standpoint, I would love to have a 'tweaker' interface for tweaking game play in game, on the fly.. would I want to take the coders on my team away from what they are presently doing in order to do this? no.. not when they are doing hard work in order for the game to look great and get great framerates on pretty low end hardware.

Will things get better? in time.. yes... but my experience seems to suggest to me that a general purpose interface or set of tools is not going to provide enough control of what the end result will be. In this were to exist, it would be constrained by the built in assumptions the coders who wrote the tools.

I think this is a good discussion, and I think that we have a long way to go in developing better tools. My opinion is that some of what is being put forward in this thread would be a huge step backward.

#69 Coding does not equal gameplay your right. Gameplay is an idea, but to realise it, you often need a talented coder in order to get the right feel.

Gameplay isn't something thats easy to define really. In a car game it might be what enables you to feel the car on the track and know when the tires are sliding.

You don't need a coder to design a game if you understand the technical side of the engine and whats possible. In my experience the best teams have experienced developers that understand their tools and how to get the best out of them. When a good art lead and engine coder get together, they should be able to figure out and streamline the mechanisms behind their engine to get the best possible result. this is one of my problems with torque, the core of the engine and how you go about using it was pretty much decided for you a long time ago. If you dont like it you either have to put up with it or shut up, OR change the source. Which even for a simple game is going to be a lot of work.

For me at least blitz3d is that abstraction layer that Will is talking about, its simpler than C++ but well realised, streamlined towards manipulating 3D geometry and translating it the way you want to, quickly and efficiently. It's not as simple to learn that you can create something outstanding within days of picking it up. But you can do a lot more with a lot less lines of code, its easy to read and intuitive because the language was created with games in mind.

It's biggest failing is the lack of OOP, you have simplified classes called types. Functions, and arrays. its a bit more like C# than old school basic, and anyone with knowledge of C# can pick it up pretty quickly. It's ideal for casual games and not overly ambitious projects. Even one of the guys at Epic working on the unreal 3 engine uses it for fun and released a shareware game with it last year.

And for me as an 3DS Max artist with quite a lot of industry experience, it has the art path equivalent to the commercial engines I used fairly recently.Torque seems to be more of a legacy old school BSP FPS engine with (In TSE's case more modern additions bolted on).

With the tools I use now, I can sit down and design how the media fits together, discuss concepts like AI with my coder, prototype ideas very quickly, and not be restricted by an exporter like torque has. Currently I can export anything I want directly from within max. If I want to make cutscenes rendered in realtime inside the engine, I can export animated camera transforms with FOV, animated lights with animated colour, range, faloff, targets using max keyframe editor and spline function curves. the same with animated Brushes, Animated UV's that can be scaled, scrolled, rotated etc in using all my native max tools. Define collision primitives, create a arbitrary collision mesh for scenery within the same scene as the scenery. AI spline paths, us max instances and Xrefs to build levels, or populated them with static objects.

For texturing, I have several blendmodes that I can multitexture with more than 1 UV, and do multipass rendering for more sophisticated terrains with bitmap masks.

Plus all the usual heirarchical nodes for mounts, pivots, partcles etc.

Setting it up requires a lot of careful discussion with the coder I'm working with, and has to be written from the ground up, but with an experienced coder, and the intuitive entity based language, it doesn't take all that long.

Being a simple, elegant and fairly easy to learn language, there are a lot of inexperienced people using it, most never make anything worthwhile . But in capable hands with experienced coders you can achieve a surprising ammount.

#70 @Adrian:

Dude, you develop in Blitz3D... A plug-n-play game editor. Nothing in that "engine" (if you can call it that) ever appealed to me. As a developer, I don't want everything thought out ahead of time for me. That means less flexibility and less potential to be different. I don't want silly check boxes that turn weapon reloading on and off, I want to code that option. What if I'm making a game that doesn't include weapons?? Isn't that just extra bloat in my code to have weapon reloading on/off checkboxes?

The real point here is that Torque is anything you friggin' well want it to be. Out of the box it is a group of scripts, some art assets to play with, and an executable. When you really want that power you open up the C++ code and add some things to the engine. If you don't like the portal system, you rip it out and plug in a different method. In Blitz3D, you do nothing of the sort -- you have what you have and you're stuck with it.

See, people get TGE thinking that they'll just drag and drop a few components and have a game. Well, it is that simple, and it's also not that simple. Whoa.. I just said something completely contradictory, but that's my point. TGE, with its amazing script interface is powerful and can be modified simply. But if you want to put in more flexible vehicle dynamics, you build it with the C++ code. That's where people start to get lost. They want the scripting language to do it all, but it can't.

You see, engines that try to oversimplify game development are ruining the environment. We get these people who think that checking boxes, fliping options, editing some text, and re-releasing something makes a whole new game. Modders who want to keep modding are best suited to be working with Blitz3D. When they graduate to coding the engine, then they are better suited for TGE (since Blitz3D doesn't allow that). I just went to the site, and realized that all coding is done in BASIC (Beginner's All-purpose Symbolic Instruction Code) and am horrified that you think that it comes anywhere NEAR the cabilities that TGE does.

I have to stop right here... I'm not going to waste my time arguing with someone who believes that BASIC will EVER be better than C++.

- Brett

PS: BASIC is usually an interpreted language. Now Blitz3D seems to offer the ability to compile the BASIC (yeah, like VB which makes bytecode) to run a little faster. But, BASIC was designed to be a learning language. It doesn't offer simple pointer manipulation and memory instructions. Maybe Blitz gives you a little bit of this, but nothing in line with the C++ can do.

#71 Brett,

Quote: Dude, you develop in Blitz3D... A plug-n-play game editor. Nothing in that "engine" (if you can call it that) ever appealed to me. As a developer, I don't want everything thought out ahead of time for me. That means less flexibility and less potential to be different.

Er I'm sorry mate, it's obvious you never even looked at Blitz3d. there is no engine, its a programming language. THere are no check boxes. There is no plug and play. You havd to build a framework from scratch. You can still code in C++ if you want via DLL's and use blitz3D as a front end for higher level access.

thats how it was relatively easy to get libraries like ODE and Tokomak integrated.

It has no editor, you have to make your own, or use something like 3dsMax as your editor. Cartography shop was written in blitzplus and is an alternative if you want it, as is Giles which is starting to get some extra editing functionality.

I suggest you really try it and get an idea of what your talking about.
In blitz too, you can make your game any way you want it to be. It can actualy be more work, and require more knowledge to develop an engine in blitz3D than what your average torque user has.

I can't think of a single torque game that can't be done fairly easily in blitz.

Torques strength isn't the engine itself, but garage games strong ties with the industry that makes it easier for them to negotiate with the big boys and have some credibility. Strong marketing and a good comunity are others. The engine is good enough to make decent games, but it's going to be a while before it can compete with a real AAA engine. I'm not saying blitz is the best thing since sliced bread, both engines have advantages and disadvantags depending on what your trying to do.

It also has better compatibility and speed on lower spec hardware being DX7, but also supports more graphical features than TGE does despite being such an old API. Some things that even TSE doesn't do like multiple UV's

#72 Maybe Will only dont have a math thinking.. this is why programmig languages are a dificult learning process for him.
I with my bad english language knowledge, programming using Will's utopic language will be as hard an actual programming language is for him.

But go on, this is the funiest topic ever ;)

#73 "I can't thikn of a single Torque game that cant be done fairly easily in Blitz"

You are deluded if you think writing ANY game (Torque or not) would be easy in any language, or editor, or geam makr...

That statement shows that your knowledge of game making is extremely limited... No offence, but making a game that is made in Torque is not easy, in Blitz3D or otherwise...

#74

Quote:The engine is good enough to make decent games, but it's going to be a while before it can compete with a real AAA engine.

Hmm... that seems like a very false statement... unless Tribes and Tribes 2 aren't real games.

Quote:You can still code in C++ if you want via DLL

not even close to the power of utilizing a C++ engine directly in the source ;)

Quote:I can't think of a single torque game that can't be done fairly easily in blitz.

-Tribes
-Tribes 2
-Dark Horizons Lore
-Minions of Mirth
-Nemesis Vortex

there are more and if you truly still stick by that quote while evaluating every aspect (and yes networking is obviously an aspect of a multiplayer game) then please post more detail since you haven't seemed to yet ?

I haven't seen a single Blitz 3D project that seems as ambitious as any of those

#75 The tribes games were AAA about 5 years ago. Things moved on since then. And I don't count those as AAA games any longer.

I'll check out those other games you mentioned. I've played dark horizons lore and wasn't that impressed with the game itself, but liked all the background stuff that went into developing the universe.

I'll have to look at minions of mirth and nemesis vortex

but most people are making games like think tanks, marble blast, tennis critters, orbz and the bowling game. Which don't require much of an engine behind them.

#76 Your quote:

Quote:there is no engine, its a programming language. THere are no check boxes. There is no plug and play. You havd to build a framework from scratch.

Blitz 3D's quote:

Quote:
Blitz3D provides a simple yet powerful environment for game creation - simple, because its based around the popular and easy to use BASIC programming language; and powerful, thanks to a highly optimized underlying 2D/3D engine.

note the
thanks to a highly optimized underlying 2D/3D engine.

Your quote:

Quote:I can't think of a single torque game that can't be done fairly easily in blitz

Blitz 3D's quote:

Quote:In fact, many shareware authors are moving to Blitz from languages such as C++ due to the faster development time.

note they advertise a shareware target... a lot of TGE products aren't meant for shareware

Your quote:

Quote:It has no editor, you have to make your own

Blitz 3D's quote:

Quote:Features: Blitz3D compiler, IDE, debugger, example code, tutorials and documentation.

hmm compiler, IDE, and debugger...
yup I guess thats from scratch ? no editors ?

Your quote:

Quote:
It can actualy be more work, and require more knowledge to develop an engine in blitz3D than what your average torque user has.

Blitz 3D's quote:

Quote:
If you've been yearning to create games but have been frustrated by the complexity of programming languages such as C++ or Java, you've come to the right place!

hmm who should I beleive, you or the creators of Blitz 3D... lol wishfull thinking won't make what say true

#77 Praire Games - Minions of Mirth

A MMORPG and MSRPG (Massively Single Player RPG) in Torque... dynamic zone loading, quest creation... etc etc etc... all in Alpha stage... yes it is actually up and running quite smoothly... I've played it, amazingly impressive... I highly doubt anything close to this could be done in Blitz 3D ;)

btw you are mentioning how old Tribes and Tribes 2 are... while Blitz 3D is based off of DX 7... ?

#78 From the page www.blitzbasic.com/Products/blitz3d.php:

Quote:
Blitz3D provides a simple yet powerful environment for game creation - simple, because its based around the popular and easy to use BASIC programming language; and powerful, thanks to a highly optimized underlying 2D/3D engine.

Sorry mate but maybe you should get an idea of what you're talking about.

I can think of many games that Blitz couldn't do that TGE could. But this is neither the thread nor the place for it. I appreciate you wanting to stick up for Blitz, much as I do TGE. But this is the forums for TGE, not Blitz3D -- they have their own forums.

- Brett

#79 Not wanting to hijack Will's thread, but...

and


and this doesn't really strike me as anything like Think Tanks, Marble Blast, or Tennis Critters. Each one has their own appeal and own look and feel. They are all fun games and high sellers on the GG site. As is Lore and many of the others you appear to be slamming.

Man, you are just smokin' the Blitz crackpipe.

- Brett

#80 Josh Ritter's 'Minions of Mirth' looks very promising, but it's not really released yet.

At least I did preorder it, and I encourage everyone counting it in as a future AAA to do so also.

[edit] if you want to get it on the road, so to speak (get it?). Oops.