Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Oct 2010
Offline Last Active Jan 12 2013 11:13 PM

#4991341 Can i become a professional gamedeveloper learning at home?

Posted by on 17 October 2012 - 11:16 PM

I'm a 100% self-taught programmer and games/software developer... I've never taken a college course on programming, computer science or game/software development. In fact, I'm a college dropout... I had only 1 year and 1 semester of college before being forced to drop out to care for my grandparents on their deathbeds (mom had to work and lil bro was legally obligated to go to school). Everything I've learned comes from books, the internet, practice and experience; if used correctly, these resources can be every bit (or more) powerful than a classroom.

I got my first real job in the industry years ago without a problem. I was chosen over candidates who had college degrees, due to the extent of my programming knowledge and wide range of experience with writing all sorts of software (and because I knew several languages fluently). All it took was a resume detailing all of my experience and showing them some samples of my work -- even hobby and "academic" projects. It also helped that I had done a considerable amount of "freelance" work writing small bits of software, libraries and classes/components for small businesses and individuals. The point is that if you're the guy who's always willing to go the extra mile -- do things better, learn more stuff, keep up with new developments in the technological world -- then you can beat people with formal training/education.

All programmers are "self-taught" to some extent. If you don't have the passion/motivation to teach yourself to further/better your skills outside of a classroom then you'll never become a good programmer! But all this aside having a college degree is a major advantage. It's essentially "proof" that you've played the game of school and know your stuff. I strongly suggest going to college and getting a degree. I'm 24 now, and doing well without a degree and running my own business, but I plan to go back to college. It's just something one should do in life, if anything for the experience...



#4989645 HLSL (Pixel Shaders) Should I just walk away?

Posted by on 12 October 2012 - 08:10 PM

Not Using Shaders
  • Less work to do
  • Don't have to learn anything
  • Won't have shader errors
  • Your game won't have to slow down to compile them, ever
  • You can't actually get anything on the screen... lol
You have to use shaders... The only other option is a fixed-function pipeline, but the FFP was discontinued after DirectX9... DirectX9 is an ancient dinosaur from the prehistoric age (circa 2002 B.D.X.10. lol), and it would be stupid to go to DirectX9 so you can use the even more ancient FFP... so don't even consider doing that, just let D3D9 die in peace. This being said how did you program games for many years and learn all these other things without ever writing a shader? It seems impossible lol... If you did somehow manage to get that far without shaders I am totally amazed. Even the most basic DirectX tutorial series and books teach basic shaders very early on because it's required knowledge to do just about anything in modern graphics programming (with a few notable exceptions... e.g., Nintendo Wii).

Anyway, shaders are amazing. And once you get familiar with them you will love em. Shaders give you complete control over how things are rendered in several stages. DirectX10, for example, gives you control over the vertex, geometry and pixel processing stages. DirectX11 has all of these and also gives you compute, domain and hull shader stages. You can just use very basic shading techniques if you like, but the capability is there to do beautiful and amazing things that will take your breath away... everything from simulating realistic water surfaces to GPU-accelerated physics to smoke, fire and explosions. What you can do with shaders is limited only by your imagination and the hardware its running on. All of these things you're worried about are complete non-issues... If compiling shaders at runtime is too slow for your game then just pre-compile them... Shaders are NOT an "un-standardized mess"... HLSL is completely "standardized", as is GLSL for OpenGL. Graphics hardware and their capabilities are the only thing that's not "standardized" and uniform across the board, but that's not the fault of shaders or shader languages.

If you want to get anywhere in game developing for any purpose, be it hobby or commercial, then you're going to have to learn shaders. Otherwise I dunno how you plan on getting a single pixel to show up on the screen or doing anything expected of a video game in modern times. ;-)

As for WWII Online, I played that game for several years and was sorely disappointed... I think it's a very poor example to follow if you want to develop, and CRS is a poor example to follow for a company. At the time I was playing the game regularly I could understand the very poor graphics, but it's been years since then and their graphics are STILL bad... almost exactly as bad as they were 4yrs ago... There's little excuse for that, imo... But hey, graphics aren't everything, right? Well, their physics are also terrible...particularly the flight models. As someone who's VERY into aviation (loved flying since I was a kid) and flight simulations it was one of the most disappointing things about the game. One of the worst things about the whole game, imo, is how they try to "balance" the Axis and Allied sides and still call it a "simulation". In war there is no "balance" except the other guy shooting at you, and there should be no notion of "balancing" equipment performance in a simulation. Tank combat is very quirky and full of utter ridiculousness... small Allied guns can sometimes plink a German Tiger a couple times, FRONT ON, and set it ablaze...which is absolute fiction. Infantry combat was always very boring and full of its own problems... the controls are very "static" and old school, you really cant do much more than run/walk/shoot/reload (no dropping weapons, picking up new ones, etc)... they didn't even bother to implement real small arms ballistic physics (they just use range table data and calculate a path, afaik)... About 95% of the time you're playing the game you're bored because you never see enemies. And the reason you never see enemies is because not enough people play. And the reason not enough people play is because A) the graphics suck B) it's not very realistic C) they don't update/fix things in any reasonable amount of time.

One of the main reasons I say CRS is a bad example to follow as a company is all because of their lead programmer (that guy, DOC). He goes on the forums and will actually sit there are argue with players, belittle them and try to make them feel stupid; especially if they suggest changes/upgrades for the game or criticize something that's wrong with it. Those are their CUSTOMERS... a game development company should NEVER try to make a customer feel stupid or try to make them look stupid in front of other people on the forums. If I was the CEO of CRS he would be the first person I fired simply because of that, and I would fire anyone else who did it and also get rid of all their forum moderators who engage in the same behavior. That sort of crap has chased off a good many players from whom the game could have benefited greatly (if anything in numbers lol). The other reason I say they make a bad example is, well... look at how outdated their software is. It has changed very little in, say, a decade... There are much smaller companies and indy developers spitting out vastly superior (complete) products faster than they fix a bug or do a minor update/patch. Don't go on the forums and bring that up though, because you will get attacked by DOC or someone else. They'll make a huge wall-o-text post full of excuses about why the game can't be fixed that makes absolutely no sense. I remember one time, for example, we were discussing the possibility of allowing pilots to bailout of their planes and parachute to safety (I think the game has that feature now but didn't at the time). DOC chimed in and said it was impossible to add that to the game. When asked why he said, to paraphrase, "We thought about doing that but we didnt... so the engine doesn't have that feature, so we cannot do it." I was like wtf, seriously? Bailing out of a plane is a game feature, not an engine feature. I know 12-year-old kids who I could give a 3D model of a plane and a pilot who could code a demo of that feature in all but 30 minutes... That's an example of treating players (paying customers) like they're stupid by assuming they're too stupid to see through your lie... Things like that constantly ticked me off until I just couldn't even stomach the game anymore... If I want to play a real combat flight sim and enjoy some actual realism in physics and aircraft performance I fire up IL-2: Cliffs of Dover. If I want a realistic infantry combat experience I fire up ArmA II...

If you're interested in WWII simulations and the prospect of coding them then shoot me a pm. I could help you greatly. For one thing, I have quite a few 3D models I might not mind sharing... everything from a complete, animated Bf-109F4 to a German infantry helmet. I also used to be a very active IL-2 Sturmovik 1946 modder who coded flight models, and have extensive knowledge of flight physics. I'm also a "gun nut" and I collect historical firearms...have lots of reference images, historical data and personal knowledge of how the real weapons operate. And more... My team is currently working on a new engine, but we have a WWII-themed project planned for the future. We have not started development, but we intend to get to it in the next couple of years. It will be yet another highly ambitious project, lol, but we handle that sort pretty well. :-)



#4989623 what is the best engine to start with?

Posted by on 12 October 2012 - 06:20 PM

None, in my honest opinion... I think it's more important to learn how graphics programming works before you start using an engine that abstracts everything away. Your skills will be completely portable, whereas if you just learn to use an engine you are helpless without that particular engine... So I recommend you learn to do your 2D stuff with DirectX or OpenGL... alternatively the XNA Framework is a simpler way to get your feet wet. And if you're afraid of C++ you can always use a good C# wrapper like SlimDX or SharpDX to get at the DirectX API directly, or Tao or OpenTK for OpenGL...

#4989281 Looking for Coder/Programmer

Posted by on 11 October 2012 - 04:12 PM

I'm looking for some helpful users of this site to help me out with a giant project I am working on, If you have the skill to code/program then please reply or private message me by filling out the following,

Your Name - Doesn't have to be your full name ;D
Your Skill - Whatever your best at (Coding, Graphics... etc)
Your Current or Old projects - Whatever Projects you have worked on.
A short Paragraph on why I should add you on the team.
Anyway I can contact you - Skype is the best way (You wont need a microphone or a camera)

You're probably not going to find any help here by this post...

A short Paragraph on why I should add you on the team.

You didn't even give us a short paragraph on what you're doing or why we should want to work for you! So chances are no one will want to respond or help lol! Posted Image

You need to tell us (at minimum) the following things:
  • What your "giant" project is... and since it is a "giant" project tell us how/why it's viable/feasible?
  • YOUR skills/experience...
  • YOUR name, company (if any) and contact information
  • Why we should work for you... e.g., how much are you paying and/or what use/benefit does it have for us?

If you answer these questions perhaps you will find programmers willing to work with you. ;-)

EDIT: Also, this is the wrong forum section (I believe) for recruitment posts... This section is for game programming discussions.

#4988040 starting game engine

Posted by on 08 October 2012 - 11:09 AM

I don't think anyone here stated that you should never write an engine, but coming onto a forum asking how to write one generally shows that you lack the fundamental understanding of game development required to actually build a usable engine.

It has been said in a few threads around here, and there are quite a few articles out there on the internet where people scoff at the concept of an engine entirely. But I wasn't accusing anyone here in this thread of such radical views.

I partially agree with your last statement, but I wouldn't consider it a good practice to drive engine development purely on samples. If you don't have a fully defined goal/game in mind to drive your engine then you'll probably end up with that relatively useless engine you mentioned, and I don't consider tech demos or samples proper goals.

Of course not... if you're trying to drive development purely on tech demos and samples you're making exactly that useless engine... I'm just saying that tech demos and samples are a good starting place for getting your engine working, figuring things out and getting a good foundation for your engine. But then you have to switch gears and start writing some games and practical applications... that is, after all, what the objective of an engine is: to write games and apps. Failing to do so is like training an army shoot guns well but never teaching them how to actually fight and win in combat. You'll have an army of good marksmen, yes... perhaps the best shooters in the world... but they'll be totally scattered and routed by a well-organized and trained army with far less-capable marksmen and equipment.

#4987588 Best way to manage render targets, buffers, etc...?

Posted by on 06 October 2012 - 11:21 PM

Up late, doing some more work on the engine. And I just started questioning the way I've done things in the past... wondering if there is not a better way than the approach I currently take. I'm wanting to know the best way for the engine to manage its render targets, depth stencils, viewports, etc...

FYI: The engine is completely written in C#, and is built upon a data-driven architecture. It is also fully platform-agnostic and API-agnostic, so I must take care to ensure what I do works across DirectX 10 - 11 and OpenGL (as well as custom software renderers and 3rd party back-ends).

Attached to my post is an example diagram which shows how a platform-specific implementation of the "Renderer" interface (in this case the D3D10 implementation) "plugs in" to the engine. I added this to give you an idea of how the code is structured. Now tell me, if you please, how I need to be managing my render targets, depth stencils and all such things...

EDIT: Note that in the diagram the "Engine" and "Application" parts are NOT actually classes... they are simply representative of how things sort of fit together.

Attached Thumbnails

  • Renderer Hierarchy.png

#4985251 Passing shader parameters from a scene node to the renderer

Posted by on 29 September 2012 - 09:58 PM

[source lang="cpp"]// Pseudo-code to give you the idea; not use verbatimclass Material{ Shader* pShader;};abstract class IMesh{public: void* pMeshData;};class Model{public: IMesh* pMeshes; Material* pMat; RenderOp* GenRenderOp();};class RenderOp{public: IMesh* Mesh; Material* Material; Matrix WorldTransform; };class Renderer{public: void Draw( RenderOp* op );};[/source]

This is the essence of the data-driven design/architecture. But you can make your implementation far more robust than this pseudo-code-ish example goes; in fact, you must if you want to get the most out of the design. But you should have the general idea. There are a lot of great threads around here about this, including some of mine. I'm sure swiftcoder or Radikalizm can chime in with much better examples and information if they have time. If you need to work out any specifics from this just ask!

I think that even if you intend to use only DirectX 10, 11, one version of OpenGL, whatever (or program for only one platform, e.g., Windows) you should still try to design things to be platform and API -angnostic from the start. Use virtual/abstract interfaces to define all of these things and inherit from them to implement platform-specific bits of your engine/game. Then you can dynamically switch rendering back-ends at runtime and easily port your games to other platforms by only making a few changes in the engine. Keep your designs loosely coupled and each component focused only on the interface of the engine; nothing platform-specific.

#4983873 Intro and a few questions

Posted by on 25 September 2012 - 10:09 PM

I recommend Autodesk Maya over 3DS. Maya is, imho, superior software. It's much more intuitive and has much better designed interfaces. You can do complex things in Maya at astounding speed. I'm not that great of a 3D modeler but I have a friend who is a true expert; he learned it over several years of college courses. He can spit out complex models with outlandish speed and accuracy. The same operation in 3DS Max can be slow and clunky at best. The movie industry is way ahead of the game industry in that regard, as they embraced Maya years ago. For some reason, many game dev studios are still clutching to 3DS Max because it's the "traditional" thing and they teach Max in a lot of game dev courses for artists in colleges. The first time you open up Maya it can be daunting. There are hundreds and hundreds of buttons and gizmos. But over time you will learn what each of them are and what they do. And when you get to that point you will really appreciate how great and intuitive the software is. It's just layed out in a way that is conducive to high quality work at high speeds, with less fumbling around with menus and UI elements. And there's simply no comparing Blender to Maya.

#4983793 Intro and a few questions

Posted by on 25 September 2012 - 05:14 PM

I agree with ATC on the curly-brace family languages, like C, C++, Java, etc. I, too, would turn away from programming if I would've started with Pascal(not that Pascal is bad, it's just that the syntax is not to my likeness).

(((((You) know)(what)((language I)(absolutely))(couldn't (bear))to(((((use)))))? lol... LISP... :-) It's one of those "love it or hate it" languages, and I hated it from first sight due to all the parenthesis and the syntax in general. Not saying it's a bad language, it's just the complete opposite of my taste.

I also hate the BASIC/VB syntax... It just seems very verbose and ugly to me. Whereas you can use a '}' in a C-family language, you have to type out an entire word to close in a BASIC-like language such as Visual BASIC. Variable declarations are also rather ugly and verbose to me...

Keep in mind this is just me ranting, expressing my own personal opinion and biases. I'm not saying any language, including VB, sucks. I'm just saying that I hate the syntax and think it's ugly/verbose. :-)

I think the OP will like programming a lot better when he tries a language like C# or C++ and sees how easily you can transfer between these languages; not to mention how incredibly powerful and practical they are!

#4983709 Intro and a few questions

Posted by on 25 September 2012 - 02:11 PM

CodeBlocks is good, but I prefer Visual Studio above any and all other IDEs. And the free Visual Studio Express editions are pretty damn good. You're unlikely to lack for any feature using an Express edition until you get into very advanced programming (likely at least one to several years down the road).

I love Visual Studio because I think (warning: personal opinion) that it is the biggest, baddest and most robust IDE you could ask for on Windows. I've developed everything from console applications, 3D applications, mobile device software and Windows applications to operating systems, compilers, assemblers and linkers with it. You can configure (and even extend) Visual Studio to do anything you want. It's just a bad *** IDE.

Therefore I recommend you at least give it and C# a look-over. I think you will love C#. It's a beautiful language; every bit as "powerful" as C and C++ and almost every bit as fast (sometimes faster). C# is just a very fluid and elegant way to turn ideas in your head into machine language, and make it run fast, efficient and stable.

#4983630 Draw a Textured Quad

Posted by on 25 September 2012 - 10:27 AM

Thanks for your reply ATC.

I actually wanted to learn DirectX11, but I havn't managed to find any good tutorials about textured quads. The only tutorial I found was really overkill, using shaders etc. I would really like to learn DirectX11, but could you help me to find any totorial that just picks the absolutely neccessary to draw a textured quad?

Shaders are absolutely necessary to getting anything on the screen nowadays. The days of the FFP (fixed-function pipeline) are dead. This is even true in XNA, though they provide the BasicEffect class which may have hidden that fact from you. There's certainly nothing overkill about using shaders. Shaders are simple, easy to use and very powerful. I will certainly be happy to help you write a very basic shader and understand how it works.

I'm already familiar with encapsulization and separating into classes as I have 5 years experience of C# and XNA. I just felt that I wanted to move on with something more advanced than XNA, and therefore decided to learn C++ and DirectX. I know that the code should be splitted into classes, but before I do that, I just want everything in one place so I can overveiw it easy. The only purpose of the current project is so I learn the simpliest basics. When I've learn these, I'll move along with a new project where I'll split the code into classes and learn more complicated things.

I think it's more complicated to mix a bunch of DirectX code in with Win32 code. That's a LOT of code lol. It's just a pain to read, imo. It's so easy to split it into two files/classes that I just think you're doing yourself a disservice to keep it all jumbled up. We could create you a C++ template you can use anytime you start a new project that will automatically set your code up properly if you like.

Also, if you're good with C# and have XNA experience perhaps you jumped to the wrong platform. Were you aware of SlimDX (and even SharpDX)? These are both very good C# wrappers for DirectX, and SlimDX (not sure about SharpDX) covers the entirety of DirectX 9, 10 and 11 (even 10.1 and 11.1). Basically, SlimDX is just DirectX for C#. It's almost a 1:1 wrapper, so there's really nothing you can do with native DirectX that can't be done with SlimDX. It's more than powerful enough for professional software development. I'm using it for the DirectX back-end of my engine. And if I was going to write a DirectX-based PC game I would definitely choose SlimDX.

That being said there's nothing wrong with learning native DirectX and C++. It will actually be a valuable learning experience, and there's no reason you can't learn both at the same time. Also, since they're almost exactly the same, language differences aside, knowledge from one translates to the other. So if you were to learn either one the other would make perfect sense.

Could you please help me find a good tutorial with only the absolutely neccessary steps to render a textured quad in DirectX11?
Or, if you want to be very kind, would you like to spend like 10-15 minutes and write a short tutorial with the absolutely neccessary steps?

Yes. Here is a great place to start.

But I will help you too if you need me. If you like, we can start a new C++ project and I'll show you how to draw a textured quad and explain the shader part of things so you'll see how easy and powerful it is. Hit me up with a pm. We could also do the same thing with C# and SlimDX.

#4983625 No knowledge of programming, wish to create an android game without aforement...

Posted by on 25 September 2012 - 10:12 AM

I just checked To the Moon's system requirments on GoG: "3D graphics card compatible with DirectX 7 (compatible with DirectX 9 recommended)". Of course that is no surprise. Making a game with a "programming language" or a different authoring tool like Game Maker has no impact on what the system requirements will be.

That was exactly my point... Somewhere along the line programming was involved, as this is the world of software. :-)

I could say more but I will just withdraw. I had already conceded defeat to jbadams who knows far more about the subject than I do, but I'm still getting assaulted with downvotes. And I don't want to continue throwing my thoughts into the mix if it's annoying people that much. After all, it's about helping the OP; not trying to "win".

All I will say beyond that is that I still hold to my opinion that anyone wanting to create a video game should embrace programming. It's not only for making your own video games but it's a skill that could land you a job in a variety of industries. For instance, if you're a good DirectX/OpenGL programmer you might land a job at a large investment company writing real-time trading and charting software. A good physics programmer might end up with a job at Lockheed-Martin. If you use Game Maker you might make a good game but you're going to miss out on a lot, and it's not a skill anyone is likely to hire you for.

That is all... sorry if anything I said conveyed bad information or upset anyone, since I honestly didn't know as much about this topic as jbadams and some of you.

#4983613 Intro and a few questions

Posted by on 25 September 2012 - 09:47 AM

Actually, I was just about to recommend 3D Game Studio. It's NOT a completely templated game engine, though it does come with a bunch of template content you can use to play with/learn. If you're afraid of programming you can get an introduction to the C-family of languages through their scripting language, Lite-C. It's actually not bad. For the price and the fact that you can also get a free version 3DGS is a great learning tool. Technically, if you know C or C++ you could squeeze a commercial game out of it.

But as someone else said, trying Apple Basic and Pascal might be the reason you're turned off to programming. Try C# or C++... even C is good, though it's not object-oriented. For some reason, and I'm not alone, I just hate the syntax of languages that aren't in the curly-brace family (e.g., C, C++, C#, Java). You might be one of those people too, so you need to try a "better" language more suitable to your brain. :-)

#4983480 No knowledge of programming, wish to create an android game without aforement...

Posted by on 25 September 2012 - 12:29 AM


Though you're not going to convince me that Game Maker or RPG Maker competes with what can be accomplished with DirectX11 or Unreal, for example... When you walk in a store, say Walmart of Gamestop, just pick up any random game off the shelf and look on the back of the box: "Requires DirectX10" or "Requires OpenGL" or something similar will be there. There's really just no substitute for the power of programming. That is, after all, why all of the professionals and big companies in the industry hire programmers. And it was in fact a programmer who wrote Game Maker and RPG Maker in the first place. :)

While you're absolutely right and have proven your point that you can in theory (and sometimes in practice, as your examples show) create a good game with some "game-maker" software, the chances are slim to none. And if the OP is interested in developing a game I think he/she is starting off on the wrong foot by looking for ways to avoid programming or learning anything about software and development processes.

Also, I looked at the three games you mentioned: LoF, TtM and Saira... While I don't doubt these are pretty good games they're far from being AAA-grade titles. I hadn't even heard of these games until just now. There was definitely no line 200m+ long outside Gamestop at 12am when these games were released. I'm not knocking on the games, I'm just saying they are very technically limited. Most gamers these days would consider the graphics to be below sub-standard and wouldn't buy these games for that reason alone (I know, graphics aren't everything but that's the mentality of gamers). That's the problem with "game-maker" software. The technical reality is that you simply don't have the freedom or raw "power" that simply using a programming language would give you. I would also venture to say I could implement those same games a lot easier and faster by programming them than struggling with click-together game-maker software.

So while I must concede that you're correct, I still think the fact stands that the OP better embrace programming if he/she wants to make a game anyone will want to play. And in the end they will be happy they did; if not, he/she will miss out on what could be one of the coolest things they ever do in their life.

#4983426 Draw a Textured Quad

Posted by on 24 September 2012 - 08:09 PM

If you don't mind me asking, why are you learning DirectX9...an "ancient" DirectX API from circa 2002? Why not start learning DirectX10 and/or 11? I actually think 10 and 11 are a lot easier to work with as they don't suffer from 9's technical flaws and bugs. They also share the common DXGI layer which encapsulates and simplifies dealing with graphics hardware.

It would also help you a LOT if you separated your game/scene code from the Windows app code. In other words, write a new class called "Game" or "Scene" and let it handle the initialization of DirectX and the drawing of your 3D scene. It will make editing and debugging your code 10,000% easier because things will be logically separated and much neater. Besides, you need to learn good software engineering practices such as encapsulization and decoupling.