Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is using an existing library, actually cheating?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
25 replies to this topic

#1 loxagossnake   Members   -  Reputation: 156

Like
0Likes
Like

Posted 24 December 2013 - 04:44 PM

Alright, I am an aspiring game developer (mostly interested in the field of programming and general design/storywriting) currently learning C++. Actually, I do have a good hold of the language in topics ranging from basic procedural programming with standard output to some novice OOP. I have been learning programming since I was 15, but that was mostly algorithmic stuff and only now at my 21 years have I started a serious self-educational campaign, by buying a book and allocating -that word is growing on me- dedicated study and practice time. I was a gamer probably since when I was back in my mother's womb, but the desire to make something of my own has been eating my insides for a long time now. Oh, and I have some form of OCD-related perfectionism. You might need that information to answer.

 

Anyway, I managed to convey my enthusiasm to a coed at Physics school and good friend of mine, who is also serious about it - and a very talented artist. He too wants to learn programming, but mostly focuses on the digital art aspect of game development. We decided to form a small study group to practice together and learn, by setting small goals and achieving them to gain some experience. Since we both can handle the language well enough for beginners, we decided to try our hands at SDL. I find it a very good beginners' library with a relatively high level of abstraction, but that comes at a psychological cost for me. While I read every line of the tutorials and try to understand what each chuck of code really does, I'm not an expert in C++ and DO end up with questions, but I also use the code to my own devices (I'm currently working on a small graphical Rock-Paper-Scissors game). Long story short, I feel like I'm just dragging and dropping stuff. And that murders the side of me that loves technicalities.

 

I know this is all more of visit to the therapist than a game dev related question, but I do value your opinion very much. So, to distill this to a question instead of a philosophical text: do you think a beginner should first tame the language as best as they can and then even think of making a game, or is the practice of 'just doing it' and understanding along the way a better alternative to actually learning?

Thank you very much for your time.

Peace out, Jim.

 



Sponsor:

#2 exOfde   Members   -  Reputation: 808

Like
6Likes
Like

Posted 24 December 2013 - 05:15 PM

The way you want learn is a good choice but SDL to address as high level of abstraction ... i have to disappoint you. Sdl do only some basic stuff like initialize a Window and do some basic 2d stuff like blitting picture to the screen etc..

The most work still lies by the programmer. Try an look at sfml that e.g. would you call an high level of abstraction of an library.

To answer your question yes you should first master language but you have also master the external libraries you want later use.
Just doing it would be sometimes to be frustrating if you first an beginner in programming and still later too. As quick answer. I think tomorrow I will edit this post with a more detailed answer

#3 Kaptein   Prime Members   -  Reputation: 1949

Like
3Likes
Like

Posted 24 December 2013 - 05:18 PM

"Oh, and I have some form of OCD-related perfectionism."

Me too, but I don't think that matters. I'm perfectly OK in using libraries.It's do or die, really. If you try to create everything yourself you're not going to be making any games.

I have been programming for many years now, and it's just recently that I'm trying to create most of the things I need myself, by learning advanced algebra at the same time.

I'm not making anything, and I know it all too well. It's part of my process, but at least I have made many games and many huge projects before. I always relied on everything I could find.

I'm strongly convinced that the best kind of code is the one you know has been proven and is well tested, and that's it. Creating games is a huge amount of work beyond just programming.

Let's look at the things you may need to do for, say, a zelda game:

1) Layered map format AND map editor, the latter being a major source of frustration the first time around - perhaps an external proven editor will work out

2) A ton of art assets in specific formats, because without them you don't have a (visually pleasing) game

3) A vast amount of interactive and _related_ gameplay mechanics

* Such as hooking into a floating "brick" which you can move away from you by, say, boomeranging it

* Lifting throwing and pushing the same thing

* Common enemies that can be scattered throughout the world

* Scripted (unique) boss battles

* Player states: Idle, jumping, running, jumping and running, flying, falling, swimming, diving, drowning, damaged + any other state (typically just blinking sprite), received item, holding sword, sword spin, attack, use item, frozen, electricuted, .... and the list goes on

4) Resource management that simplifies scripting, so that the level designer can design levels effectively (eg. being able to place NPCs WYSIWYG)

5) Realtime palette, so you can reuse assets, if you want

6) Weather and time of day effects, because its 2013 ;)

7) Binding it all together for redistribution among testers, designers

8) Version control for the codebase, levels and scripts

9) Game design that utilizes the present and future power of the game engine

 

Many of these points are not necessary, of course. But it could be something you have planned for.

The game will never be as good as you originally set out to do, but you may be surprised that it has improved in other areas.

 

So, I think focus needs to be on what doesn't already exist, which is essentially what is unique to the game you want to create.

If i had the choice between programming a level and drag-and-dropping it, assuming the programming happens in a text-editor, I would choose the drag&drop approach.

Being able to instantly see everything even in a very limited editor can be very healthy for morale. You can weigh the pros and cons, I suppose.

 

Try to implement Lua scripting, and create some NPC classes that all behave in unique ways, then do the same for items. That's all you need to get your foot in the door. The rest is just lots of work, and lots of rewritten code. You're never going to create your first game all the way from start to finish without having to do some serious thinking and scrapping both ideas, concepts and code.

How you solve all the problems is entirely up to you, and I think it helps you as a coder not to cheat and have everything in the gameplay laid out before you. Ideally you should get to a point where you take any concept and implement that in some way into a game. That concept almost never survives the design and implementation process, simply because things don't always fit in perfectly as it starts out as an unknown and you can't prepare for everything. Eventually you'll get a better sense of what works and what doesn't.

The bottom line is really simple: Ensure you and your teams motivation stays high by using whatever is proven and works. From there you can do whatever you want, because you can't blame the underlying structure. The rest is up to all of you to just start coding, and no amount of planning survives contact with reality. tongue.png

 

EDIT: As the man above says, SDL is simple, but it's enough for a 2D game, if you keep things within reason. You mention having many years experience with programming, so I think you can just go ahead and make a small framework that renders sprites and sorts them by (an imaginary) Z-value. Create a camera class that follows the player around. Create Tile class and add some functions you can override with derived classes. If you are into that kind of thing. :P


Edited by Kaptein, 24 December 2013 - 05:21 PM.


#4 Paradigm Shifter   Crossbones+   -  Reputation: 5214

Like
3Likes
Like

Posted 24 December 2013 - 05:20 PM

Be like water, my friend. Like water.


Edited by Paradigm Shifter, 24 December 2013 - 05:20 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#5 shadowisadog   Crossbones+   -  Reputation: 2369

Like
5Likes
Like

Posted 24 December 2013 - 05:35 PM

Alright, I am an aspiring game developer (mostly interested in the field of programming and general design/storywriting) currently learning C++. Actually, I do have a good hold of the language in topics ranging from basic procedural programming with standard output to some novice OOP. I have been learning programming since I was 15, but that was mostly algorithmic stuff and only now at my 21 years have I started a serious self-educational campaign, by buying a book and allocating -that word is growing on me- dedicated study and practice time. I was a gamer probably since when I was back in my mother's womb, but the desire to make something of my own has been eating my insides for a long time now. Oh, and I have some form of OCD-related perfectionism. You might need that information to answer.

 

Anyway, I managed to convey my enthusiasm to a coed at Physics school and good friend of mine, who is also serious about it - and a very talented artist. He too wants to learn programming, but mostly focuses on the digital art aspect of game development. We decided to form a small study group to practice together and learn, by setting small goals and achieving them to gain some experience. Since we both can handle the language well enough for beginners, we decided to try our hands at SDL. I find it a very good beginners' library with a relatively high level of abstraction, but that comes at a psychological cost for me. While I read every line of the tutorials and try to understand what each chuck of code really does, I'm not an expert in C++ and DO end up with questions, but I also use the code to my own devices (I'm currently working on a small graphical Rock-Paper-Scissors game). Long story short, I feel like I'm just dragging and dropping stuff. And that murders the side of me that loves technicalities.

 

I know this is all more of visit to the therapist than a game dev related question, but I do value your opinion very much. So, to distill this to a question instead of a philosophical text: do you think a beginner should first tame the language as best as they can and then even think of making a game, or is the practice of 'just doing it' and understanding along the way a better alternative to actually learning?

Thank you very much for your time.

Peace out, Jim.

 

 

Both are valid options. The key is to gain experience. You can gain experience in a number of different ways but it all depends on your goals.

 

If you want to make a game then use the highest level library that you can get away with.

 

If you want to understand every little detail of how the game works (but maybe not actually create a game) then do that.

 

Using existing libraries, high level programming languages, and even game creation software is not cheating. It is being practical.

 

Time is finite and so we must use our time in the best possible manner. Recreating the wheel while an interesting thought exercise is not necessary in every circumstance.

 

So use SDL, use SFML, use Python, use Game Maker...  Make your game with the knowledge that the fleeting technologies you use today are not what matters, but what you learn along the way.


Edited by shadowisadog, 24 December 2013 - 05:38 PM.


#6 Starnick   Members   -  Reputation: 1165

Like
0Likes
Like

Posted 24 December 2013 - 06:00 PM

Be like water, my friend. Like water.

 

Damn. We have a guy at work who plays ping pong like Bruce Lee.



#7 Servant of the Lord   Crossbones+   -  Reputation: 17976

Like
4Likes
Like

Posted 24 December 2013 - 06:40 PM

Using GameMaker is not cheating.

Using SDL is definitely not cheating. SDL is much 'lower' (closer to the metal) than GameMaker is.
I prefer SFML over SDL, personally, but they both serve as a similar level of abstraction, just as C++ is an abstraction from pure assembly.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                            [Need web hosting? I personally like A Small Orange]
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#8 SeanMiddleditch   Members   -  Reputation: 4677

Like
2Likes
Like

Posted 25 December 2013 - 01:36 AM

AAA games are cobbled together with many existing libraries and middleware packages.  Many big game houses even use whole premade engines.

 

Building your own tech just to build your own tech is in many respects just intellectual masturbation: fun but unproductive.

 

Nobody is well-equipped to making their own core game tech until they have experience with using similar tech in a real game.  You could make a physics engine, for instance, but if you've never made a physics game you'll have close to no idea what your features your physics engine should have, which pieces need the most performance, what the API should look like, what weird corner cases need specialized solutions and which can be ignored, etc.

 

Even if your goal is to learn, learn by making a game.  Don't worry about the questions that come up; just finish the game.  Then make another game, working with lower-level tech, answering those old questions and coming up with new ones.  Then make another game.  Point being, *make games*.  You'll figure out the other stuff as you go.



#9 SymLinked   Members   -  Reputation: 834

Like
2Likes
Like

Posted 25 December 2013 - 02:39 AM

I never understood the reasoning. You'll always use something others made. If it's not libraries, it's the platform API or something else.



#10 ISDCaptain01   Members   -  Reputation: 1349

Like
3Likes
Like

Posted 25 December 2013 - 03:41 AM

Dude, just learn one library and use it for the next 5 years and keep pushing out games. Don't worry about using other peoples stuff, just keep pushing as many games out as you can and improve your game programming logic instead. Tech keeps on changing, worrying about these things will get you nowhere.



#11 lightxbulb   Members   -  Reputation: 659

Like
3Likes
Like

Posted 25 December 2013 - 04:28 AM

It is not "cheating"(actually it really depends on your perception of cheating, so for you it may be cheating depending on your goals). I would advise learning C++ "in depth", http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list , pick a good book and finish it (most important pick a book that you like the style of writing and way of explaining). If you feel so bad about using SDL or whatever you can always try DX or OpenGL, while you would probably need a lot of time to learn it, I believe it is worth it, especially if you like the technical side of things. It's gonna be harder and take a lot more time and effort than using some engine to make a game though. However, if that doesn't seem that bad to you, and you like the journey as much as the goal, you can always opt to go for DX or OpenGL - it's pretty interesting and you learn a ton of things along the way. There are plenty of tutorials on the net (along with the DX SDK there are beginner tutorials in the documentation too):

http://rastertek.com/tutindex.html

http://www.braynzarsoft.net/index.php?p=DX11Lessons

http://www.opengl-tutorial.org/

http://www.arcsynthesis.org/gltut/

 

And plenty of good books:

http://www.opengl.org/documentation/books/

http://www.amazon.com/Practical-Rendering-Computation-Direct3D-11/dp/1568817207/ref=sr_1_1?ie=UTF8&qid=1387966970&sr=8-1&keywords=direct3d+11

http://www.amazon.com/Introduction-3D-Game-Programming-DirectX/dp/1936420228/ref=sr_1_2?ie=UTF8&qid=1387966970&sr=8-2&keywords=direct3d+11

 

A word of warning though - you should learn C++ well before doing that, otherwise I believe it will be too hard learning both DX/OpenGL while learning C++. You'll probably also need some basic knowledge of math (and hopefully working with DX/OpenGL you'll start liking math even more) - for example matrix transformations, vector operations etc., and if you decide to delve even deeper sooner or later you'll need some calculus, tensors, spherical harmonics etc.(basically you'll need some math that is needed in physics).



#12 Servant of the Lord   Crossbones+   -  Reputation: 17976

Like
3Likes
Like

Posted 25 December 2013 - 08:56 AM

I never understood the reasoning. You'll always use something others made. If it's not libraries, it's the platform API or something else.

 

You're not allowed to be a programmer unless you program on a circuit board and CPU you carved out of bamboo and a bar of soap. laugh.png


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                            [Need web hosting? I personally like A Small Orange]
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#13 frob   Moderators   -  Reputation: 19635

Like
11Likes
Like

Posted 25 December 2013 - 03:58 PM

 

I never understood the reasoning. You'll always use something others made. If it's not libraries, it's the platform API or something else.

 

You're not allowed to be a programmer unless you program on a circuit board and CPU you carved out of bamboo and a bar of soap. laugh.png

 

 

My thoughts exactly.

 

Is it cheating to use DirectX or OpenGL rather than attempting to program directly to every possible configuration of video card? That is what games in the 1980's and early 1990's needed to do, writing directly to hardware memory and switching memory banks, until standards like VESA drivers came around to unify the graphics models.

 

Is it cheating to use the Windows API rather than writing your own multithreading library? That is something the original DOOM engine needed to do, and several other games followed the example, to get improved performance and interactivity.

 

Is it cheating to use internet socket libraries rather than writing your own code that manages dialup or assorted network cards? It was common in the 1980's and 90's for individual games to require support for several common modem command sets, including Hayes and USR dialects, in addition to a wide range of network card dialects.

 

Is it cheating to use libraries for joystick or other controller input rather than polling the hardware yourself and sampling the hardware directly, as was common in the past? Each game needed to manage their own dead spots, calibration, and mapping of input streams to axis or button values.... And the values could change based on how much computing you did between polls, so you needed a solid interrupt frequency for it to work.

 

Is it cheating to use libraries for audio, rather than coding directly for each of the many types of sound cards out there? In the bad old days you had to choose from a long list of audio systems, including several SoundBlaster and TurtleBeach and assorted other brands of cards. Audio card autodetect was spotty at best, and sometimes picking the wrong card could crash your computer.

 

 

 

 

The answer to all of these, of course, is a resounding NO!  It is not "cheating" to use other technologies that enable you to do greater work. Just as it is not "cheating" to use a backhoe to dig a trench, or a dump truck to haul gravel, or a vehicle to travel long distances, or the postal service to deliver mail rather than hand-delivering it yourself.

 

If your goal is to write a game, then do so; don't waste your time re-inventing level loaders, asset management, animation loops, audio systems, rendering systems, input systems, and all the rest. Failing to do that (for any reason other than education or genuine business need) is foolish if your goal is to create a game.


Check out my personal indie blog at bryanwagstaff.com.

#14 Paradigm Shifter   Crossbones+   -  Reputation: 5214

Like
0Likes
Like

Posted 25 December 2013 - 07:39 PM

Exactly, be like water, assume the form of what will get things done.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#15 3Ddreamer   Crossbones+   -  Reputation: 3067

Like
0Likes
Like

Posted 25 December 2013 - 08:18 PM

Hi,

 

Cheating is in effect only if one acts in violation of license or has not permission to do so.

 

Using, with license, an already existing library or libraries is extremely common.  Some game developers might be surprised how much of the game engine source code or game source code for a popular AAA game comes from libraries created previous by other parties or the same game development company. 


Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#16 Satharis   Members   -  Reputation: 949

Like
1Likes
Like

Posted 26 December 2013 - 02:50 AM

I understand the thought process behind feeling like you're maybe somehow cheating or not being as good a programmer by using a bunch of libraries, but you aren't, really. If anything as you learn more and more you'll begin to figure out where those libraries don't suit your needs and where starting from scratch may be better both for you and the productivity of your project.

 

I like to think of libraries as code that some other person or people put a bunch of work into, like you wouldn't make a car from scratch you'd at least buy the metal and some of the parts, the wheels from somewhere. If anything you should prefer to use library code where it would not be more work to implement it than roll your own.

 

With the exception of things like direct3d or opengl you might be a bit surprised how often you actually will just prefer to write your own stuff due to it being less restrictive and faster to implement, but of course that varies a lot depending on the thing.

 

Instead, reverse your thinking. If anything you should be considering all these other libraries to be tools, if you can't find the right tool, well that just means you make one, if you can, or if you find a tool that may fit the job, see if you can make use of it. After all, those people spent all that time writing that code, why let their work go to waste if it can suit your needs?


Edited by Satharis, 26 December 2013 - 02:54 AM.


#17 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 26 December 2013 - 05:18 AM

... like you wouldn't make a car from scratch you'd at least buy the metal and some of the parts, the wheels from somewhere.


You'll certainly not buy your metal (carbon fibre, aluminium) from 'somewhere' if you're a car company ... but i get what you're saying.

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#18 Karsten_   Members   -  Reputation: 1546

Like
0Likes
Like

Posted 26 December 2013 - 07:02 AM

I guess just choose libraries and technologies that you would be proud of using and would look better on your CV.

 

For example, I imagine a programmer would rather have a game written in OpenGL and C++ rather than RPGMaker2000.

Whereas an artist or game designer would have no problem with using the less "technical" option because their skill lies on the actual content of the game instead rather than the implementation.

 

Plus, after a while, a lot of libraries that you will use, you will start to understand how you could re-implement them. You will also realize that your time is better spent on other things ;)

 

I only suggest reimplementing something if you can either make it better, or if you cannot agree with the license it is originally under. For example, one of my side projects is to reimplement the core Unity 3D engine because although I like the API, I cannot accept the online-activation requirements of the original product and feel I can also make it better by providing a native C++ API instead of C#/UnityScript.


Edited by Karsten_, 26 December 2013 - 07:02 AM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#19 loxagossnake   Members   -  Reputation: 156

Like
1Likes
Like

Posted 27 December 2013 - 01:42 PM

Some great insight here. Everyone who answered here actually got what my concerns are. I want to be technically skilled in the point that I can tackle any problem and be self-sufficient. I don't intend to program the low-level stuff every time I make a game, I just want to have an idea about how it's done, and that's the point where I get frustrated with myself. I am going to use libraries, engines, and just focus on the game, but I would like to make my own mini-engine (not as powerful Unreal Engine) because i find joy in programming and would love to be recruited in a professional company. Reinventing the wheel might be counter-intuitive, but it might also be necessary learning progress, the same way a doctor will study anatomy hands-on instead of just using read material.

But as you said, I guess this is not cheating, it's just making my life easier! Thank you!



#20 SymLinked   Members   -  Reputation: 834

Like
0Likes
Like

Posted 27 December 2013 - 04:05 PM

Reinventing the wheel might be counter-intuitive, but it might also be necessary learning progress, the same way a doctor will study anatomy hands-on instead of just using read material.

But the doctor needs to know anatomy to be able to practice his profession at all. That's not the same with programming. You don't have to know the internals of all the libraries you use, although it can be helpful.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS