Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / What makes one code stronger thAn another code?

Author
Message
Slayer267
14
Years of Service
User Offline
Joined: 6th Sep 2010
Location: Non of your beez wax
Posted: 9th Feb 2012 04:21
Okay so alot of people are telling me that C++ is stronger then DarkBasic and that it lags less. How? Is it because C++ knows more about the situation therefore being more complex? Please! I want to learn!

THE CARNAGE PRODUCTIONS WEBSITE IS NOW UP!

www.Carnageproduct.webs.com
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 9th Feb 2012 08:08
The not-as-laggy aspect comes from the fact that the debugging utilities are as bare-bones as you want them to be, and from the fact that nothing is assumed about memory (so no time needs to be spent on garbage collection).

Maintainability is something that comes with Object Oriented Programming. The ability to create objects and say "foo.thisAction()" really helps compartmentalize everything. My rule of thumb is that in good C++ code, you're writing lots of small methods ("methods" are functions belonging to a class) that can be easily tested. The more cross-dependencies and the bigger the methods, the shakier the code.

Also: transitioning from procedural to object oriented code is hard. There's the syntax gap as well as a mental reasoning gap. I'd recommend starting with Java, because... well if I told you you might not understand (you can only have a pointer to an abstract class. abstract classes are important for polymorphism and inheritance. Pointers are hard to work with, so there's a problem.)

The Wilderbeast
19
Years of Service
User Offline
Joined: 14th Nov 2005
Location: UK
Posted: 9th Feb 2012 08:56
I would agree with what Neuro just said - it's also incredibly difficult when you come back to a procedural language from an object-orientated one, you spend an awful lot of time trying to figure out how to do some relatively simple things!

Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 9th Feb 2012 10:28
C++ is more efficient, and faster than most other languages, due to the increased power of PC's. Back in the day, games were written in assembler, which is very far removed from C++, in fact C++ is a stroll in the park compared to assembler. Thing is though, it's also more time consuming to program in lower level languages, development time is inversely proportional to language complexity. You might knock out a game in DBPro in a week, that same game would take a month in C++, and 6 months in assembler. Who's to say though, that as hardware improves, we won't just use a procedural game centric language for game creation in the future. That's pretty much what the Unreal engine is, imagine if Unreal had a basic syntax like DBPro, that would mean some really professional results in very little time.

The problem is that a lot of C++ programmers can be obtuse, can exagerate how complex C++ actually is. Really, C++ is as complex as you need or want it to be. You can take your lazier coding practices over to C++. I spent years in the assumption that it would take years to learn C++, so long that there's no real point in trying to learn it. Then I started writing a game in C++, turned out that most of the complexity is just common sense - as you develop programming skills, you start to work at lower and lower levels, even in DBPro. Although DBPro is BASIC, it makes sense to adopt C++ style code organisation as much as you can.

I think that a lot of people would be surprised just how straightforward C++ can be - grab a sprite example and experiment with it, that's what I did, and my iOS game is almost done. Perhaps it helps that I don't care too much about convention, I mean a hardore C++ coder would tear my code to shreds, but it does what I want it to do. Game programming is a seperate thing from application programming, it's more organic, and sometimes that's for the best. I like a language that allows organic creativity, and C++ can work like that if you want it to.

Health, Ammo, and bacon and eggs!
Seppuku Arts
Moderator
20
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 9th Feb 2012 11:48 Edited at: 9th Feb 2012 15:34
And of course there's Dark GDK, which is a library for C++ and it's a good way to ease DBP users into C++ as Dark GDK is basically DBP running from within C++.

But I think when you're making a game you make your choices based on what works best for you as a developer. C++ may be more efficient and faster and not as complex as some like to make out, but as Van B suggested, anything done in C++ will take longer. So do you sacrifice development speed for efficiency or do your sacrifice efficiency for development speed? When you're a bedroom coder coding on your own, software like DBP is quite attractive or even if you're a small team. There's also tools like Unity and Unreal that can be thrown out there for choices in game development, heck there's a whole array of choices out there - some requiring the use of C++ as well.

I think one of the main advantages to C++ as far as game development goes is that you can load different libraries to make up your engine so you have a choice based on your development. You could go Irrlicht(graphics) + ODE(physics) + a Sound engine (can't name any off the top of my head) and develop for PC, Mac and even Linux as Irrlicht can use OpenGL and develop multi-platform. You could use XNA and develop for Windows and XBox 360. You could use AppGameKit inside of C++ and develop for multiple mobile platforms. You could use an already made game engine like Torque and edit the source code in C++ to add features specific to your game. You could use Dark GDK and exploit the same features as Dark Basic Pro, but get a better performance.

There's a whole world of choice out there when it comes to using C++, however, it doesn't necessarily mean it's the best choice for you. I had no trouble getting to grips with C++, but I still use Dark Basic Pro, because it's straight forward, easy to use and therefore I can get what I want done, quickly. Saying that, I might be tempted to start up Dark GDK.

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Feb 2012 14:07
C++ compiles more efficiently than DBP.

Quote: "and 6 months in assembler."


LOL, a game in assembler... Imagine the spaghetti

TheComet

Slayer267
14
Years of Service
User Offline
Joined: 6th Sep 2010
Location: Non of your beez wax
Posted: 10th Feb 2012 02:33
Basically its the compiling process that makes it bad? Why not improve the compiling process -.-

THE CARNAGE PRODUCTIONS WEBSITE IS NOW UP!

www.Carnageproduct.webs.com
Diggsey
19
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 10th Feb 2012 12:06
Because writing an optimising compiler such as the one in VC++ is seriously hard.

[b]
Nomad Soul
Moderator
18
Years of Service
User Offline
Joined: 9th Jan 2007
Location: United Kingdom
Posted: 10th Feb 2012 16:30
Why is assembler so hard?

Zotoaster
20
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 10th Feb 2012 17:15
Because it's a list of very simple raw commands. There are rarely any built-in ways to organise your code. If statements, for-loops, functions, nevermind classes. Assembler is what machines run on. It's only slightly easier than binary.

"everyone forgets a semi-colon sometimes." - Phaelax
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 10th Feb 2012 17:40
Also assembly is platform specific, whereas a higher level language such as C can be compiled to spit out x86, ARM etc. binaries

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
old_School
15
Years of Service
User Offline
Joined: 29th Aug 2009
Location:
Posted: 10th Feb 2012 18:51


LMAO ahh no. Every language has its good points and bad points. Every language as well is good for some things and bad for tothrs. C++ is not a cure all language. To qoute my friend Steve who has worked with C++ for over 15 years, he said "wow, I can make this program in VB in 20 vs. 6 months in C++". Now here is the downside. VB, Java and others can not do certain things C++ can and in reverse. So every language has its uses. However, object based is always best. Comman based is stuff fromt he 70's and I like to think we progressed just a tad software wise since moving a dot on the screen.
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 10th Feb 2012 19:49 Edited at: 10th Feb 2012 19:56
As it happens, C++ is more efficient (and thus faster) than most other languages because it's lower level than the likes of C#, Java, and so on.

Quote: "To qoute my friend Steve who has worked with C++ for over 15 years, he said "wow, I can make this program in VB in 20 vs. 6 months in C++". "


He's a very poor programmer then. He's not part of your 'company' is he?

Quote: "Comman based is stuff fromt he 70's and I like to think we progressed just a tad software wise since moving a dot on the screen."


What does that even mean? You have absolutely no idea what you are talking about.



Support a charitable indie game project!
Mnemonix
22
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: Skaro
Posted: 10th Feb 2012 20:33
Quote: "LOL, a game in assembler... Imagine the spaghetti "


Roller Coaster Tycoon code is 99% x86 assembler with a small c++ controller.

As for the whole C++ thing, have a look at some tutorials and grab visual studio express (its free) and experiment it with it for yourself.

Join us at www.devhat.net and in #lobby at irc.devhat.net
Slayer267
14
Years of Service
User Offline
Joined: 6th Sep 2010
Location: Non of your beez wax
Posted: 10th Feb 2012 20:35
THEN WHAT THE HECK MAKES C++ FASTER!!!!! That is my question!

THE CARNAGE PRODUCTIONS WEBSITE IS NOW UP!

www.Carnageproduct.webs.com
RalphY
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: 404 (UK)
Posted: 10th Feb 2012 21:29
Quote: "object based is always best"


Apart from when functional is better .

Don't be fooled into thinking that just because your using C++ your applications going to be faster. It's entirely possible to write a slow application in C++ if you don't know what your doing (for example, is your understanding of what your memory management requirements are going to be better than Lee's?). Arguably one of the biggest advantages of a language like C++ is that it does very little for you. This leaves you in control to optimise for your specific scenario. A language like DBPro, that does a lot of the work for you, has to generalise.

Go banana! | Super Nintendo Chalmers! | When I grow up I'm going to Bovine University!
Diggsey
19
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 11th Feb 2012 00:09 Edited at: 11th Feb 2012 00:10
If you assume that the code is perfect for each language, then:
- Assembly will be the fastest, because it directly translates to machine code, and everything must at some point translate to machine code.
- C/C++ will be very close behind because they are still fairly low level, and compilers are now clever enough to be able translate perfect C/C++ into (almost) perfect assembly.
- DBPro code will be significantly slower, because even perfect DBPro code translates into lots of redundant assembly code, since it doesn't have an optimising compiler.
- Java, C#, VB.net are probably similar in speed to DBPro. They have clever compilers, but the languages are higher level, so they don't translate as easily into assembly, and because they all compile to some form of bytecode (java bytecode or .net IL) some compilation is done at runtime.
- Scripting languages are generally much slower, because they depend on high level concepts such as string lookups which are inherently slow for their core features, and they are usually interpretted or at least compiled when loaded.

Obviously in reality code is not perfect, but then it becomes impossible to make a comparison, because you can write slow code in any language.

[b]
CoffeeGrunt
17
Years of Service
User Offline
Joined: 5th Oct 2007
Location: England
Posted: 11th Feb 2012 01:29
The real reason is that to code in DBP, you need book. C++ doesn't need book, and therefore isn't stupid.
Dark Java Dude 64
Community Leader
14
Years of Service
User Offline
Joined: 21st Sep 2010
Location: Neither here nor there nor anywhere
Posted: 11th Feb 2012 02:33
Yes. Wiz ze dee bee pro, you needz tha book with all da codez.

Copyrightz © 2012 dbd79
Slayer267
14
Years of Service
User Offline
Joined: 6th Sep 2010
Location: Non of your beez wax
Posted: 11th Feb 2012 03:06
TGC should write a book on how to code. Would be extremely helpful to newcomers, and even experts!

THE CARNAGE PRODUCTIONS WEBSITE IS NOW UP!

www.Carnageproduct.webs.com
Vent
FPSC Master
16
Years of Service
User Offline
Joined: 3rd Apr 2009
Location: BC
RUCCUS
20
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Feb 2012 07:18
I suppose the simplest way to explain what makes one language faster than the other would be to think of our own everyday language we use.

Imagine (for arguments sake) that our entire world only spoke English. We - as earthlings - all know English and therefor can get our point across to each other very fast.

Now imagine that an alien visited earth, and the alien did not understand English. There would be no way for him to communicate with us verbally.

However, imagine that the alien has an alien friend with him that speaks both English and the alien language.

The alien can speak to his bilingual friend, and have his bilingual friend communicate with us, and vice versa. However, a human-to-human conversation would go a lot faster than an alien-to-friend-to-human conversation, due to the translation necessary inbetween.

Furthermore, conversations between the humans and the alien would also be a lot simpler due to the fact that his bilingual friend might not know EVERY English phrase, causing the bilingual alien to only be able to translate certain things.

Now equate humans to C++, the alien to Dark Basic, and his bilingual friend to BASIC, and you have a basic analogy of why using a lower-level programming language (IE a language with fewer translations required to get to English in our example)gives you more speed (in that no translation is required) and more power (in that more phrases from the English language are known).

On another note, @VanB I was in the exact situation that you described several months ago. I had never touched C++, I was always scared of it, but I had come up with an app I wanted to develop for the iPad. I finally bought some books on C++, Cocoa and Objective C, took a deep breath and prepared for what I assumed was going to be a painful learning experience, only to find out it really wasn't that hard at all. Fast forward a few months and I now have several investors funding my app and its well on it's way to completion and submission to the app store within another 3 months or so.
Pincho Paxton
22
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 11th Feb 2012 16:55
I have tried all languages including Assembler, and pure binary. The problem is the translation to my brain. My brain cannot think in assembler, or Binary. I wrote just a joystick controller in assembler, and it took me days to make loops for the 8 directions so that they all interconnected with one another. I had to write the program on paper first just to follow it with arrows drawn from one point to the next. So I had a drawing of a bunch of nested loops with arrows to each end of nest to make sure that all of the nests were efficient.

I decided in the end that I wanted a language that I can think in. Then I don't have to make drawings of pseudo code. Because some of the Blitz Basic code is right to left, and uses strange numerics where I expect words I can't think in Blitz Basic either, or C++.

I can think in Amos, and Dark Basic. So I can code in my head, and even run a program in my head.

Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 11th Feb 2012 18:01
Quote: "LMAO ahh no."


Whatever old school, you know best... at least in your own mind. I can't even argue with you, it'd be like trying to reason with a sponge pudding.

Health, Ammo, and bacon and eggs!
CoffeeGrunt
17
Years of Service
User Offline
Joined: 5th Oct 2007
Location: England
Posted: 11th Feb 2012 18:57
I still honestly believe, that old school is actually a very persistent troll, and little else...
Pincho Paxton
22
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 11th Feb 2012 19:06
He seems to target Van B. Van B is one of the most helpful people on the site.

RUCCUS
20
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Feb 2012 21:03
Just ignore him, trolls are part of every forum, ignore them enough and they'll move on to something else.

Lets keep the discussion on track.
KariSigurd
14
Years of Service
User Offline
Joined: 17th Mar 2011
Location:
Posted: 11th Feb 2012 21:19
No one programming language is the absolute best. C++ might compile fast and efficient programs but sometimes there's a whole lot of code that has to go into doing even the simplest things. C# isn't as efficient but if i ever have to write Windows based applications I'd pick C# over C++ and save a lot of time in the process.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 12th Feb 2012 01:37 Edited at: 12th Feb 2012 01:45
It's difficult to talk about languages without talking about the API's and the access to the interfaces of said API's. The API took even a bigger chunk of the center stage especially around DirectX7 (Yes in some cases earlier <IIRC DX 1.x, wasn't well received... 2.x started generating a buzz.... DX 4.0 started seeing universal adpotion,, by DX 7 it was End-GamE>,, but DX along with Video-Card Mfrs. ended the need as well as the reward in directly coding to the video hardware (mainly via assembly)). It also replaced DOS as the most popular platform for game programmers. Software emulation just couldn't any longer achieve what was being done via hardware embedded chips dedicated to DX, OpenGl; especially when considering 3d Hardware aAcceleration.

C++'s power comes from the fact that it's a mid-level language (this is somewhat debatable),, and that through it... you have a more direct interface to the DirectX API. C++ in and of itself, does not have graphics commands (at least not a part of the ANSI Standard) rather, these are provided by libraries or Graphical API's like DX, OpenGL, SDML etc... There is also power in the depth of it's user-base, endless resources, sophisticated compilers, ability to incorporate in-line assembly, it's structure (mainly through it's Classes as opposed to C's Structs),, and it's portability (outside of the API), extendability, code-reuse/maintainability....etc

~ZENassem
TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 12th Feb 2012 11:07
Quote: "Why is assembler so hard?"




Here's some code I wrote in assembler for a C8051F020 micro controller. It writes the input port to the output port.

Now make a game.

TheComet

Seppuku Arts
Moderator
20
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 12th Feb 2012 11:34
"call Watchdog init"

Sounds like a Chav recognising a criminal. Assembly looks awfully confusing, I think I'll stick to stuff designed for thick people. :p

Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 12th Feb 2012 23:00 Edited at: 12th Feb 2012 23:02
Quote: "The real reason is that to code in DBP, you need book. C++ doesn't need book, and therefore isn't stupid."


I laughed; thank you for this

-------------

For me, when I set out to make a game from scratch, I tend to use the language I either know most about, or want to learn more about. I tend to not write in C because I don't want to have to worry about crazy memory management. To put it bluntly, most of us will probably never write a game that taxes a language like C#, Java or even DBP, so we shouldn't worry that C# doesn't handle optimization as well as C++. Most of us will never be faced with an issue that requires us to write inline assembly.

Right now I've decided to write my next iPhone game using AppGameKit Tier 2. I've already written a game in Objective-C, but I am interested in learning more about AGK. Sure, I could shave off CPU time and save memory here and there if I programmed it in straight Objective-C, but I'm not making an insane taxing complex game.

I would rather enjoy writing games for a hobby than struggle over inane restrictions.


Senior Developer - CBS Interactive Music Group
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 13th Feb 2012 00:33
Seppuku Arts,

Quote: "Assembly looks awfully confusing"


Well.. If you looking at 8bit / 16bit examples that are hitting hardware all over the place, then yeah.. it can be very difficult to follow exactly what's going on. Since we've no way of knowing what some odd looking addressing mode or what setting a particular value into memory does. The latter is important as other chips in the system, map themselves into or over the cpu's address space. So setting up the graphics hardware for example, is just a matter of writing the required values to wherever the graphics hardware expects them. Which is perfectly fine in a world where the hardware configuration never changes, but not so much today. If you're bored and feeling nostalgic, then track down some old C64 (8bit) / Amiga 16/32bit
demo/game assembly source codes.

Today things are vastly different, not only have assemblers grown up a lot, but the 'dirty' low level hardware hitting stuff has been replaced with the familiar API programming that high level desk top programmers enjoy. So you often end up with something that's a bit more approachable, in particular if you're familiar with the api in question, if not, then your still stuffed

For example,


The following source is from a project I wrote back in 2000/2001 for DB called Kyruss (back when i had free time to do whatever I wanted, whenever i wanted.. ). Basically the environment gives provides a GUI / assembler and simple API. Kyruss CPU emulation uses a 'dumbed' down version of the 68000 cpu instruction set, meaning it's core instructions are similar, but a lot of fat has been trimmed away. The idea was to make Virus war simulation game.. But anyway..




WLGfx
17
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 13th Feb 2012 01:51
Years I spent with the 680x0 and yes, still in those days, 'hardware hitting' was always required. Especially with the blitter, fpu and audio chips. The good thing about those days also is that hardware didn't get updated as fast as they have done with PC's. Even then I used C for the most part and the speed critical portions got pure assembly code. And that's just the same for now. Even on a 2Ghz single core processor, squeezing that last bit of speed can be crucial.

Assembly programming these days does look a little more complex because of the extended macros that are being used and the masses of libraries that can be included in a project. I still haven't gone as far as using the win32api from within assembler. Although I have looked into the background hacks for opengl to see what speed I can squeeze out of it and so far very interesting stuff. (Still take me ages to suss out) Yes, I've taken a temporary leave from GDK to explore the raw openGL programming. And I must say, I'm impressed with the easiness of it.

C/C++ has it's complexities but as far as I'm concerned it can run much smoother and faster than any other language. It's as low as you can get before you need assembler and you can use the nice STL stuff, other libraries and switch to standard ansi C for optimising. You'll always get people criticising C/C++ because they can't do it themselves, so they stick with Basic...

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
old_School
15
Years of Service
User Offline
Joined: 29th Aug 2009
Location:
Posted: 14th Feb 2012 20:16 Edited at: 14th Feb 2012 20:18
Quote: "Don't be fooled into thinking that just because your using C++ your applications going to be faster. It's entirely possible to write a slow application in C++ if you don't know what your doing (for example, is your understanding of what your memory management requirements are going to be better than Lee's?). Arguably one of the biggest advantages of a language like C++ is that it does very little for you. This leaves you in control to optimise for your specific scenario. A language like DBPro, that does a lot of the work for you, has to generalise."


I agree ralph all very true but sometimes things that do most of the work for you are poorly written their self. So by taking "shortcut" route you may screw your self. Its best to write everythng or at least most of it your self. Prgramming after all is about learnign something new and bringing an idea to life. Also belive contrary to popular beleif C++ is not a cure all. Different languages will work better for certain things as mentioned above. At the end of the day though, it comes down to the programer and what he/she thinks will be best/work best. Personaly big Visual Studio fan my self. Microsoft offers tons of support and help getting a project completed. Sometimes it helps to have help from skilled engineers with years of exp in the field and people who know the language very well.
Zotoaster
20
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 14th Feb 2012 20:23
Quote: "Its best to write everythng or at least most of it your self."


Quote: "Sometimes it helps to have help from skilled engineers with years of exp in the field and people who know the language very well."


"everyone forgets a semi-colon sometimes." - Phaelax
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 14th Feb 2012 20:27
Quote: "Its best to write everythng or at least most of it your self."


This is a false statement.



Support a charitable indie game project!
Seppuku Arts
Moderator
20
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 14th Feb 2012 21:51 Edited at: 15th Feb 2012 03:13
At the same time, doing most of it yourself can be incredibly time consuming and either limits your creations to something more basic or means you're spending an awful lot of time on those creations.

So where short-cuts can be made you can speed up your development process. Even people in the games industry have shortcuts to speed up development as there's little point reinventing the wheel. The latest from the Elder Scrolls and Fallout series uses Gamebryo, Havok and SpeedTree. A whole plethora of games take advantage of the Unreal Engine and games companies have invested a LOT of money into it - whilst the indie version is free (and cheap when paying royalties) the commercial version of the engine is damn expensive.

The Star Wars Unleashed games use a Physics engine called Euphoria. Some companies do make their own engines and usually have large teams working together on them - like FFXIII/FFXIII:2/FFXIV's Crystal Engine. There are engines that have been made more cheaply and with smaller teams, some of these are accessible for indie developers and even hobbyists.

So there's a whole plethora of people who find it more suitable to do than writing everything or most of it themselves. Generally it's more productive to just get on with it instead of trying to reinvent the wheel.

For somebody without massive teams or massive budgets, somebody coding in C++ could speed-up their indie game process up by:
-Using a Graphics engine like Irrlicht, instead of coding their own...or using the Direct X SDK or the Open GL API.
-Using a Physics engine like PhysX, instead of coding their own
-Using a Network engine like RakNet
-Using a Sound Library like IrrKlang

All free, all have tutorials and all can be used together (even tutorials for integrating them together).

Dark GDK is also free and requires C++. Some of the expansions aren't free, like Dark Physics. Even compared to the above solutions, Dark GDK cuts out a lot of work.

If you're running C# or Visual Basic, you could cut out a lot of work using something like XNA or even Dark GDK.NET. XNA is free to use, but you pay money if you're wishing to distribute your creations for money or on XBox Live.

I've never really felt limited (coding wise) when using Dark Basic Pro and that's been pretty cheap and it's not as stable as some other leading products out there and I've loads done more in the last 2 months than I could have done if 'doing it all myself' in C++, VB or C#. DBP cuts out a lot of the work and still provides decent enough results.

For those not interested in coding from a lower level have Unreal SDK, Torque, NeoAxis, Unity3D and other choices out there - with these you can get away with just scripting and still produce excellent pieces of work.


So all in all, it's not better to rely on doing most of the writing yourself, because you can still come out with the same (if not better) results with a lot less work, meaning you can focus more on other things.

Of course, what's better does depend on your goals. Doing most of the writing yourself might be great as coding challenges and may expand your knowledge in some areas of programming and might be useful for programming certain things. Some people try to learn assembly and no doubt there's real-world applications where knowing assembly is useful and where it's important to know. But what you can do is limiting because you're working on a lower level, so it'd mean you'd need a lot more coding, which is one limitation, the other could be your own knowledge and abilities and you're not going to produce better results than say...if you were using UDK, because to get something like UDK, you're going to need a large team of highly knowledgeable people and a lot of money to invest in it.

So if your goal is to create something that could be easily be created in UDK, then obviously UDK is the best answer. If you're challenging yourself and want to learn something low level or you need to use a lower level language then assembly might be the best for you or native C/C++ if Assembly is too low leve. If you want to create basic games off of Windows' UI (like Gazillionaire Delux) you might use Visual Basic without any third party libraries.

If you're wanting to make money out of making games then there's a lot of options available, you've just got to judge what the best option is for your game. Oh, and have a bit of luck, you can't guarantee what you make will sell well.


greenlig
21
Years of Service
User Offline
Joined: 30th Aug 2003
Location: Melbourne
Posted: 15th Feb 2012 02:09
Not incredibly relevant, but CoffeeGrunt wins everything.

INTERESTINGLY, the company I worked for (www.laigames.com) wrote almost everything in either assembly or c/c++. When I got there and was tasked with re-jigging our video game engine/software, I scrapped the whole thing and implemented Unity3D. Why? The biggest bottleneck I have experienced in game dev is programming. Everything else is useless without that interactivity and structure in place. Using something like Unity means designers can come on board at a very early stage. Similarly, I used DarkBASIC to prototype a host of new games, as it gave me a very quick method of testing stuff. I guess this is in direct response to Old_School's assertion that doing it yourself is better. I think it's just longer.

Horses for courses.

Greenlig

Your signature has been erased by a mod as it is far too big.

Login to post a reply

Server time is: 2025-05-19 17:59:26
Your offset time is: 2025-05-19 17:59:26