next »

[Krux]

Would you like to know, those of you who use tools like Unity, Unreal Engine, Gamemaker or Construct, why you use these tools. With "these tools" I mean tools that take over the main loop of your game, and are usually not able to combine with other tools of the same category. If you use any of them, I would really like to know which one of them you use. But most important for me is, why you decided to use/learn that specific tool. What were your hopes when you started using it? Did those hopes turn out to be true? Do you use them for other reasons now? Do you still use them now? You don't really need to go into detail, but I am very curious about it.

[DireLogomachist]

I use Unity, just because it's the point of least resistance to getting into 3D game dev

[Krux]

What is your goal with unity? Are you just doodling around, or are you using it for an important project? And does Unity do what you want it to do?

[DireLogomachist]

Small projects and large both. Does it do what I want? Really depends. I think its more than powerful enough for anything I personally would want it to do. Its just a matter of learning how to make it do those things. Like editor scripting - extremely powerful, but I'm still working out how to make that work.

[Krux]

So you learned modelling and building levels first, before learning how to program? Or is it just do just don't know yet how to do the scripting in Unity?

[Thaumaturge]

I use Panda3D; it's perhaps a little more programming-oriented than engines such as Unity (in particular, I believe that there's no dedicated editor--at least as of the last time that I looked).

I honestly don't recall why I originally chose Panda specifically, except that I think that I considered it to be the best fit for my desires at the time. (One of those desires was the creation of a particular game--which I didn't get far with--as I recall). The fact that it's entirely free (save for some optional third-party dependencies, I believe) was likely a significant factor. I recall that I looked at a number of the engines available at the time before settling on Panda.

As to why I use an engine at all, to steal a few words from GameDev.net: I want to make games, not engines. Having a third-party engine allows me to focus more on the game itself, and less on technical details.

I continue to use it largely because I'm now familiar with it, have some base-code built up, and because I've come to rather like Python (which is Panda's scripting language; I believe that one can also work with Panda in C++, although I don't think that I've tried). It's also proven itself to be a pretty capable engine, I feel.

[DireLogomachist]

So you learned modelling and building levels first, before learning how to program? Or is it just do just don't know yet how to do the scripting in Unity?

I'm a software dev by trade, so all my art comes later in the process for me. I'll start with an idea and make a quick prototype just using the standard white cubes in Unity and writing scripts in C#. As for 3D modeling, I've been playing around in Blender for a number of years - enough to make some not-too-shitty low poly models for my projects.

The editor scripting feature of Unity is one that allows you to create new editor tools and features. They expand upon the Unity editor itself and aren't run in-game. For example, I made a simple one that forces objects in a scene to snap to a grid, making level editing easier.

If I was starting from scratch again, I would absolutely start with learning how to program for Unity. Look up some online tutorials on how to do C# scripting and how those scripts are used and run in Unity. There's so much free info out there its nuts.

This might be a good place to start with learning code in Unity. Start with the beginner scripting posts.
https://unity3d.com/learn/tutorials/topics/scripting

[bateleur]

I use Unity.

To explain why requires a bit of context. I learned game development on a BBC Micro back in the early 80s, then later moved on to Assembler, mostly on the Acorn Archimedes. I've also written games in Java (various libraries), Flash and HTML5/Javascript. The one thing all of these diverse environments had in common was that there's a lot of stuff you have to understand and a lot of annoying support code you have to write before you can get on with any actual game design.

The reason I currently like working with Unity is because most of what you need is built into it. I can spend most of my time working on game-specific code rather than basic prerequisites and I get to do more game design and less tedious debugging.

(It's far from being a perfect system, but since we don't have any perfect systems that doesn't seem like an important objection!)

[Krux]

@bateleur

That's actually quite an interesting story. One question that I still have is, why you went from hardware close programming such as Assembly to more abstract systems such as flash and javascript? And going your way you did, do you think you did learn something that you would not have learned if you had Unity like it is today back in the early 80s? I am not sure if that question is that meaningful since back in the 80s there was no hardware able running Unity, but I would like to give you some room for interpretation.

[Vanethos]

After some searching, I have decided to learn and start developing in GameMaker Studio.

First, I bought the humble bundle with it, being an incentive to start using it. Then, I was fortunate enough to watch Tom Francis (from Gunpoint) tutorials in how to make a game with zero experience and it was my main driving force to start making something.

Having little programming experience (I tried to learn for myself, my background is in construction engineering), it was clear that GameMaker was the best solution, due to its forgiving programming nature. Additionally, I really like the way the engine works, so I kept using it (and I really liked using GM:S2 too!)

My goal with it is to be the first stepping stone in game development. After releasing my first project I hope to be able to start learning Unity or Unreal as my main tool.

[bateleur]

That's actually quite an interesting story. One question that I still have is, why you went from hardware close programming such as Assembly to more abstract systems such as flash and javascript?

Oops, sorry, missed your comment at the time.

To answer your question: development time. Languages like Assembler, C and C++ are very, very slow to develop compared to higher level, garbage collected environments. Any time this gets discussed there's always someone who says "Nooo! I am fast at C!". All I can say is that whenever I've had a chance to confirm such claims face to face it's turned out that the programmer in question thinks this because they've been coding C for a decade or more and never bothered to get past the training wheels stage with anything else.

And going your way you did, do you think you did learn something that you would not have learned if you had Unity like it is today back in the early 80s? I am not sure if that question is that meaningful since back in the 80s there was no hardware able running Unity, but I would like to give you some room for interpretation.

Actually I did have the 80s equivalent back when I was a kid. There was an add-on for the BBC Micro (B) called "Graphics ROM", which made it easier to write games.

My dad always worried it was holding me back as a programmer and thought I should be learning Fortran. Of course, I will never know for sure if he was right, but thirty years later I have a PhD in Computation, work as a programmer and nobody much uses Fortran anymore. :-)

[Krux]

Oops, sorry, missed your comment at the time.

No problem, I still got your answer.

To answer your question: development time. Languages like Assembler, C and C++ are very, very slow to develop compared to higher level, garbage collected environments. Any time this gets discussed there's always someone who says "Nooo! I am fast at C!". All I can say is that whenever I've had a chance to confirm such claims face to face it's turned out that the programmer in question thinks this because they've been coding C for a decade or more and never bothered to get past the training wheels stage with anything else.

I think this is so true. I know several examples. I also think that you can be fast at C, but I also have my 10 years of experience completed. So I am a little bit biased here. But I can also tell you, that when you have the ten years complete, you would not want to go to an enforced garbage collected language, because that would mean that a lot of the experience you gained during these ten years simply can't be applied. I think that is the reason why those people never bothered to get past the training wheels stage, because they get alienated by the fact that they can't use their knowledge to their advantage.

Actually I did have the 80s equivalent back when I was a kid. There was an add-on for the BBC Micro (B) called "Graphics ROM", which made it easier to write games.

Is this what you mean: http://mdfs.net/Docs/Books/Manuals/AcornGXR.txt?

I skimmed it, and it looks interesting, and nicely documented. I can even read the code examples. But I have no idea what language that is. Is it interpreted or compiled.

I was born the end of the 80s, and never started programming before the 2000s. For me it is weird to think that those limited systems from the 80s had space to run any decent compiler or interpreter. I worked on projects in c++ that compiled for half an hour on today's machines, I can't imagine how it would have been back in the 80s. In my head everybody was hacking assembly, and all compilers could afford do on home computers back then is a 1:1 translation of the assembly instructions to the machine code.

My dad always worried it was holding me back as a programmer and thought I should be learning Fortran. Of course, I will never know for sure if he was right, but thirty years later I have a PhD in Computation, work as a programmer and nobody much uses Fortran anymore. :-)

Congratulations there. I never used Fortran, I just saw code examples. I think it is both Ugly and Interesting. I don't know any other language that is both so mathematical with matrices and vectors and at the same time so ugly and low level as Fortran. I like matrices. I don't know if learning it would actually help me or not.

Thank you for your opinion.

[bateleur]

I skimmed it, and it looks interesting, and nicely documented. I can even read the code examples. But I have no idea what language that is. Is it interpreted or compiled.

It's a dialect of BASIC. Interpreted, not compiled.

For me it is weird to think that those limited systems from the 80s had space to run any decent compiler or interpreter. I worked on projects in c++ that compiled for half an hour on today's machines, I can't imagine how it would have been back in the 80s.

Bear in mind that modern compilers do lots of very smart things and modern codebases are much, much larger. Also, you're often compiling and linking things you really don't need.

On the BBC Micro, for example, you had 32K of RAM, but that also had to contain your screen bitmap, so in reality you often needed to fit all your code into 12K. Also, unless you were "compiling" Assembler, you had to fit your compiler and all of its workspace into memory at the same time as your source code and the binary! (As a result of which I stuck with BASIC and Assembler, both of which were in ROM.)