Before I get started....

I wanted to ask some of ya'lls opinion before I dove into unity. First, like most folks, I have never really finished a project. Just started a few here and there, prototypes, then I get bored. However, I've worked with 3rd party 3d engines before. For whatever reason I end up hitting limitations, performance issues, lack of updates, or all sorts of things that basically mean every time I go 3rd party I end up hitting a wall at some point.

So a while back, I wrote a 2d/3d engine with directX in vb.net. It worked great, I had a slick interface that I could script creation of and interact with, and could load up models. That was it though, and I think it was with DX9 (DLLs look to be 2005, and I remember it being a PITA to make it run in Win10). So I have a decent start for what I need.

However, it appears microsoft and their glorious wisdom (which left with Bill Gates for some reason, they've gone downhill since) have pretty much stopped supporting DirectX and Visual Studio development. XNA was there for a while, but it was horrible and created for a single type of game.

So my question is, before I dive too much into unity (which I have seen far more horrible projects than good ones, but times change) is it going to be suitable for what I need, or will I just hit the same walls I hit before.

I am making a 2D, top down game. Graphics are nothing fancy, just sprites, *maybe* animated, with some simple weapon effects (beam, missile, projectile, explosion, smoke, fire, and maybe a few environmental things). I need to be able to display/manipulate a few thousand sprites (probably 256px and smaller, but unique) and enough particles/smaller sprites to support all the weapons fire and terrain. One of the key things is I'll allow combat over an entire planet, accurate down to the units which only shoot maybe 1km (with a max render range of 5km x 5km). This will be real time, and extremely fast paced. So I'll need a paging terrain system, not distinct little chunks of area. If you are flying, you may travel 6km per sec, but slower foot infantry may only travel 10m/sec. The terrain will all be unique over each area, and even change over time, so no reuse.

So my main questions about unity, and if it can handle it based on what I've seen, are:
- Paging planet sized terrain (hundreds of millions of square miles, yes this can be done, and even with many planets)
- A lot of sprites on the screen
- Complex interface (radars, chat windows, status for self/enemy, etc)
- Ability to code everything without using a 3rd party "editor" (mouse use is for slow typers)
- Vb.net exclusively. I can't stand trying to read code that is case sensitive and with {}, so I refuse to use Java/C#/C+, and so far it has never failed me in capabilities. May suck for help when I need it tho.
- Even with 250 units on the screen shooting at each other, still easily achieve 30fps with a mediocre video card. BitBlt with WinXP could do this 10 years ago, so surely its easy today!

I have played with unity a few times, probably no more than an hour so my knowledge is nil, and it just seems like an editor you could write mario brothers with, or anything that is "level based", but what I am doing needs to be completely seamless and I wasn't sure it'd do it, nor was I sure about its scalability.

If unity can indeed do everything I need, I'm totally good with learning it and moving that way, but if not I may just expand my DX engine and accept there will probably be a lot of issues making it work with newer operating systems.

 

It's completely scalable (KSP is written in it, fer crying out loud), so it'll do everything on your need, except let you continue to use VB. That you should abandon. Sorry, I know C-derived syntax sucks in many ways, but on the other hand, C# is the best of the C-derived languages, and so sucks somewhat less than any of the others. And it really is the way the cookie has universally crumbled.

And I'll just point out that if you continue with your DX engine, even if it works on newer versions of Windows for a while, it will never work on my Mac. Or on my iPhone/iPad. Or on my Wii U, or PS3. Unity will do all those and more. And even if you don't care about those platforms now, you might care about them in the future, so I would advise picking an approach that doesn't forever close the door to them.

Good luck (and welcome!),
- Joe

 

Plenty of really good games are made with unity as well (e.g I'm saving to go interstate & play Zero Latency, the VR zombie shooter). The reason you probably saw so many that sucked is Unity was free & would build to many platforms when others weren't & wouldnt, that meant lots of people were able to make stuff cheaply & push it out using unity.

 

If anything I would argue they've continued to make strides towards "democratizing development" as Unity would most likely phrase it. We've gone from having Visual Studio costing thousands in the early years to having a free release of Visual Studio Professional (ie Community edition) for small teams.

Concerning using DirectX to build your own engine... I can only think of two reasons - a) you want to build it for learning purposes or b) you aren't aware of or tried modern engines. At one time I may have included a third possibility but modern engines like Unity cover so many possibilities now that the need for a custom engine to build an unusual project just isn't there any longer.

By the way DirectX is still being developed. You may not have found the SDKs because they're no longer being provided separately from the Windows platform SDKs. Information on this change is linked below.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx

 

So my two cents on this. The good and the bad

- There are two and a half platforms out there at the moment (assuming we ignore the pure API's like Ogre3D) that will get you over the goal line as a small developer. 1 is Unity, the other is Unreal Engine 4, and the 1/2 being the Torque engine. (that's pure personal opinion) Unless you are a solid C++ dev, Unity's UI and workflow blow the doors off the other two. (again, my opinion)

- Unity is a PITA to transition to for a traditional .Net developer, but it is very powerful. I am a Senior IT Executive that manages a pure c# dev team as my day job to pay the bills. Shifting from traditional OOP in .Net languages, to using them in a Component based solution as a scripting language will make your head hurt. Once you get used to the differences and learn to think about your design in the component based model Unity has implemented, it is a breeze to work in.

- Due to the use of Mono .Net, the latest and greatest features in Microsoft .Net just don't exist yet. It takes some getting used to, but it's a trade off that is worth the loss. I have a game in progress at the moment running on PC, IPhone, and Android with less then 100 lines of code #defined out for the different platforms. That is pretty amazing IMO.

- Unity has the best art pipeline integration I have found by far. I switch between Blender, Maya, Photoshop, and Substance designer/painter constantly and Unity just soaks it all up and turns it into nice looking art assets. You have to learn the little nuances of each pipeline, but once you do, the tweaks are consistent each time you import new assets.

- Writing custom shaders is extremely easy to get used to if you have written HLSL or GLSL before.

- If you are a solo/small team developer, you will find several good developers on the asset store that provide nice functionality you can plug into your projects for fairly cheap. Caveat: You have to do your homework before you purchase because there are a lot of sub-par assets on the store. If you take your time and do your research, there are a lot of good assets out there that will meet specific needs, with very little coding to integrate them into your project. These are huge time savers for just a few bucks when you are looking to do something with a small team (bonus: most of them deliver the entire code base when you purchase their asset if you want to tweak it).

- The PBR model Unity has implemented is confusing but it works nicely. Most of the problem is around naming conventions(or lack of) and the way Unity's model interprets values compared to other tools. I am honestly not 100% certain this is actually their fault, but rather just different implementation models between tools due to loose/non-existent standards. Regardless, getting PBR assets out of other tools tweaked correctly can be a challenge. Once you figure out a specific tweak required for a tool chains however, the necessary changes are usually very consistant asset to asset.

- Finally, the community is insanely active. I rarely run into a problem that I can't, at minimum, find others that are working on the same problem.

Unity is not perfect, there will be days that you want to erase it from your machine as you learn it. But it is a very solid tool if you take the time to understand the quirks that come with the trade-offs they have had to make in order to support so many platforms out of the box.

J

 

Wow, thanks a lot for all the input!

I really hate to go to C#/Java/C. While the languages aren't really any harder, especially if I stick to lowercase, they are just atrocious to use. Yeah yeah, I'm no programmer, I just don't "get" the {} over "end sub/end function/next/etc", but what kind of person really prefers those {}? The code is SO much less readable. And case sensitive, ugh, an accidental press of shift and all the sudden you have a bug that becomes extremely hard to track down. VB.NET may be on the "way out" so to speak, but with my 20 years of IT experience behind me it is a lot easier for me to hop in and write some service that does X than it'd ever be in C#/C+/Java. I can use the online converters to go between C#/VB easily enough, which irks me to no end that "nobody supports VB" when its just a prettier version of C#, but as ya'll said, that is the future.

Sounds like its a HUGE learning curve, and maybe it is worth it in the long run. Most of the advantages ya'll listed wouldn't be a huge benefit to me (shaders, resources, yet another scripting language), and the few that would may not be worth the learning curve of yet another 3d engine.

Doesn't sound like sticking with DX will be worthwhile. Though what I wrote runs great in DX9, that is like 10+ years old now (not that its still very common usage really matters), and I can't for the life of me find a way to use DX12 in VB.NET for some reason. Maybe I can try out SharpDX, or figure out a way to talk directly to the hardware. After all, with a fast modern version of bitblt I'd have everything I need, it isn't like my requirements are that intense.

Thank you for all ya'lls input thought. I will still give Unity another try. Maybe it'll "click" for me or something, maybe not, but I will look into it again with a bit more motivation to see if I can somehow make it do what I want. Heck, people said VB.NET couldn't do a lot of the things I've made it do over the years, including a DX engine, so maybe there is a bit of hope.

Course, I'd rather win the powerball and go hire Blizzard to do it, but that probably ain't happenin

 

You might want to consider alternatives such as GameMaker. It's a great development tool (for 2D games) with an easier-than-C#-but-still-like-C# language, which might serve as a nice stepping stone to eventually learning C# (or not).

Check out this intro to GML (Game Maker Language) and see what you think.

In general though, programming in C# really isn't any different to programming in VB.NET. Everything you've mentioned - the case sensitivity, braces, etc - will be things you'll get used to within a day or two, and you won't even think about them anymore. Honestly, those things are the LEAST of your worries when it comes to game coding

 

Visual scripting languages have been gaining steam lately. CryTek and Unreal both have integrated solutions whereas Unity has chosen to rely on third parties. I've linked one of the more popular ones below.

https://www.assetstore.unity3d.com/en/#!/content/368

I started with Microsoft's BASIC languages (QuickBASIC then Visual BASIC) yet I prefer the approach taken by C-style languages now simply because it's far easier to read and type a single symbol than a collection of symbols.

 

I actually still prefer VB-style syntax (I was the lead engineer at REALbasic, now called Xojo, for a number of years). So I get where you're coming from. But life is what it is, and at the end of the day, the syntax of the language really doesn't matter that much.

In fact I think you're ahead of many people who start out in Unity, because you're already familiar with the .NET framework. That framework of course is exactly the same (though we're using a somewhat older version of it, it hasn't changed all that much). You already know how to read/write files, do networking, deal with text encoding, handle regular expressions, serialize data, and much more that typically trips up a new Unity dev. All that is exactly the same in C#; the syntax is different, but the framework is the same.

Learning new syntax takes a couple of days. Learning your way around the .NET framework takes years. So, I say, focus on the positive — you're well ahead there. You just need to swallow C# syntax, and learn the Unity game framework.

 

The gamemaker thing is yet another engine that has proprietary implementations, and I'll spend 95% of my time working with its code rather than the code of the game I'm writing (which will have a LOT of code).

I type about 90 wpm, and OFTEN end up doing things like "THe" or "FIrst" or whatever. When I code I code at that speed, and having to continually correct my code is simply a huge pain. Granted, I can just remove all shift key usage and probably do ok, but when I'm spending hundreds or thousands of hours in an IDE, the last thing I want is something hard to read. I'm amazed that people went for C# over VB.NET, when they are both so similar. i think it was a lot more of perception of a language over actual capabilities.

All of these new scripting languages, things like LUA, they require a real time parser. The end result is your code ends up spending a LOT of time working with the 3rd party libraries. I need to have 200 players on a screen at a time, with a LOT of math going on in the background. The last thing I need are all these libraries making every 10 lines of code I write run like 25. I simply can't have the kind of overhead a lot of engines require with their scripting languages and libraries. I mean, lets face it, all any engine is is a wrapper for some functions, which are a wrapper for some other functions, eventually talking straight to hardware. The more of those levels I have to deal with, the more likely the code will not perform as necessary. Heck, WPF looked great until I did 1000 things at once, then it simply couldn't handle it on my top of the line machine.

If I go the unity path, based on the way ya'll are describing things, I think what I may end up doing is writing my own interface to the C# code. I can do a few pages of C# code, compile that into a DLL, then write all my VB.NET code around it. Whenever I'm done, I can throw all my VB.NET code back into a big C# library and eliminate those interfaces, if they prove to be too slow.

What stinks is I can go write ALL the back end code without any issue, and finish. Graphics are my stopping point, and that is simply because I need to do a bitblt with hardware acceleration and apparently that was too much to ask for from microsoft

Thanks again for all these feedback though folks, ya'll are giving me great information to make a good decision before I go "down that rabbit hole".

 

Installed VS2015 (its horribly slow and crash heavy, more so than VS2013, I've been avoiding it), installed Unity 5, started a new project..... some error about window layouts, neither deleting them nor reverting to factory default worked. New project crashed. Awesome!

 

So wait, this is a reason you prefer Visual Basic?

 

Yes jhocking, at least partially.

I see VB.NET->DX->OS->Hardware as better than:
VB.NET->Scripting Language->DX->OS->Hardware or
C#->Scripting Language->DX->OS->Hardware

I had to write an app that queried 200,000 objects every minute, and write those to a database. MSSQL and MySQL couldn't handle it without large amounts of caching, and even then it eventually fell behind. Any queries against those databases saw the need for hardware go up by an order of magnitude. However, with VB.NET I was able to do the queries, write the data, query the data, everything with minimal/disk IO on older hardware. The more "layers" you can remove when coding (layer=3rd party anything) the faster your code is, the easier to troubleshoot, and the less likely you are to hit development walls when the 3rd party anything doesn't do what you want, or worse, becomes unsupported and deprecated.

But the main reasons are case sensitivity and code readability ({}; chars suck).

 

Dangit, I had a long response, but then bumped the wrong key and closed the tab.

So, to summarize: your code is LESS readable when it contains stuff like THe and FIrst, so you should embrace a case-sensitive language that doesn't allow that. You should also be using a code editor that automatically corrects such typos for you. I use and strongly recommend Script Inspector 3, which is a great editor that works right within Unity.

You're right about not programming your whole game in something like Lua. .NET/Mono isn't as close to the metal as C/C++, but it's close enough; performance of Unity apps is very good. If you ever need to provide a scripting language to your players, please consider MiniScript.

Yes, I agree that the standardization on C-style syntax is unfortunate, but I got over it. You will too. A good programmer could create awesome software given a stone chisel and an abacus.

You don't need Visual Studio to use Unity (many of us use Unity on Macs, where VS doesn't exist). So put that aside and work through your Unity installation issues one at a time (I suggest a new thread).

 

I strongly believe that people intending to make games that require a strict control over operations performed each second should not be using a third party engine like Unity or Unreal. If you're aware enough of your app's machine needs that you can dictate the languages that could be used, you should just write your own engine in C++ or something equally low-level.

It feels a bit nitpicky to me to say one .NET language is noticeably more performant than another... If you're using .NET at all, you have inherent inefficiencies regardless.

 

eh it's all personal opinion. I'm not a huge fan of curly brackets either, but I dislike verbose "End Function" keywords even more. I prefer Python's approach of no block characters at all, and it's all inferred from indentation. Plus that has the advantage of enforcing correct indentation, which to me is way more important for reading code than what specific block characters are used. I hate reading incorrectly indented code

But then we each have our own preferences, which is my point. I certainly prefer C# to Basic ¯\_(ツ)_/¯

 

I am going to stay out of the holy war about languages (joke), to each their own, but this comment caught my attention. You may have something else going on with your computer. I have 12 machines running VS2013 and VS2015 Premium or Enterprise on an assortment of platforms (Windows 7/8.1/10 and server 2012 R2). Four of those have Unity 5 on them and used actively. We have not experienced issues with performance or app crashing on any of these machines.

You might want to take a closer look at the health of your machine. When we have had this problem in the past it has almost always been something else that wasn't obvious about the machine. The last time it happened to us, it was Skype replacing an assembly it shouldn't have.