Does this engine require programming knowledge?
Yes. Sure beats coding everything from scratch in C++ though.
–Eric
Ofc. it does. It’s an ENGINE, not a game maker after all.
^ Actually Game Maker requires programming knowledge as well.
Welcome aboard! 
Yes, but let’s be clear in that it’s more “scripting” knowledge than “programming” knowledge. I make that differentiation as Unity lets you use C#/JavaScript/Boo which are scripting languages and those have a far shallower learning curve than C/C++ which are more proper “programming” languages.
But yes, you’ll need to have some of that knowledge on hand but Unity is great in that it lets you step in and get productive quickly, so jump on in and give it a try!
Interesting that you’d consider C/C++ a proper language as apposed to C# being a scripting language. They are all programming languages. Scripting usually insinuates that the code is not compiled and is interpreted on the fly. There are a few game engines that use C/C++ syntax as a scripting language.
I’m not trying to argue semantics when it comes to scripting vs programming. I’m just saying that a newbie to programming/scripting/coding, will in fact need to learn to do some programming.
I suppose it is a bit arbitrary but I just see a rift between what I listed as scripting languages versus programming languages. C/C++ just seem (subjective gut feel, YMMV) a bit more rigorous to me, but that may just come from my relative lack of C# experience (dabbled, nothing extensive though).
Either way, it is true, you will need to do some “programming” in Unity, but a noted above it’s a productivity focused tool so come on in, the water’s fine.
Look at it this way… programming for it only adds to the fun of creating your game ideas. :lol:
It may seem like a bit much at first, but as long as you take the time to properly plan out your game idea in detail and keep notes on it all, you’ll eventually get the hang of it.
Basically, you need to know the following:
- What are the rules of my game?
- What items do I need in the game to make it work?
- What is my game going to look and sound like when it’s finished?
- How is my game going to be controlled by the user?
- What message (if any) do I want my game to convey to the player?
Try to be as detailed as possible, but leave yourself enough room to re-work your answers as you become more familiar with your game and any new ideas or flaws you may discover in it along the way.
Finally, don’t get discouraged if you don’t get things completely right the first time around. Game development is partly a labor of love and takes time and practice to become good at it. (It’s mostly just a matter of finding a style of game development that works best for you.)
I played with Amos Pro before I was 10, and tried to make a text adventure with it. And a mario clone.
Back then, living in a rural area without internet, there wasn’t much else to do.
Subsequently, I can write thousands of lines of poorly optimized spaghetti Amos Basic code… And sadly, whenever I learn something new in Java/C# etc, rather than learn that as ‘new’, it gets listed as a ‘difference’ in my mind, due to the time spent as a kid playing around
The summary is, I think anyone can figure out unity’s scripting.
Btw, did anyone else as a child have no luck attempting to convince their parents that finally getting a scrolling screen to hit 50fps (remember, Amiga was an interlaced format, and I’m in PAL land) was the most epic achievement in your life?
… Unfortunatly, the mario clone eventually ended up crawling around 25ish fps and below once i put a ‘Mario’ stick figure in, because I wanted him bigger than 16x16 so I had to use Bobs rather than Sprites, which apparently, was a big deal
Interlaced is 25fps in PAL; 50 is non-interlaced. Amiga only used interlaced screens if you used an interlaced mode (like 640x512), nearly all games were 320x256 non-interlaced (or 320x200 for NTSC versions).
Anyway, no, I never tried to convince my parents of such a thing. :roll:
–Eric
Well, the end result is always 25fps interlaced, or 50i, as its known in the ‘new school’. What the amiga did internally is ultimately irrelevant, there was no such thing as progressive scan screens back then. Inevitably it was rasterised (that terminology is slightly redudant in this context) down/up to a standard pal signal, and thus would always be rock solid 768x576 (not 720, that came with the invention of digital formats), otherwise a tv/monitor would lose sync and roll. You could simulate this effect by upping the voltage and blasting the whites too bright so the tv would incorrectly lose sync
The purpose of the slow scan interlace methods (the higher resolutions) was so you could work on things that were higher res, which ultimatly, just meant you could work with both scanlines at once, hence the half-scan speed. Once again, end result was Pal (or ntsc if you were so inclined).
Er, no. Look it up. You seem to be conflating the Amiga’s non-VGA analog video output with “interlacing”. It’s easy to tell the difference: progressive displays don’t flicker (for most people), interlaced displays do.
Just wrong. Where do you get this stuff? 
Look this up too. Progressive scan was the original format for TVs; interlacing was only introduced because TVs back then could only handle 200ish lines at once. As long as you stick to 200 lines or so, progressive scanning is no problem, and was almost always used by video games.
–Eric