28 replies to this topic

[Gnarlyman]

So...

In the sea of languages and APIs and whatnots out there, I'm trying to figure out exactly what's the best compromise to make it easier to develop my games for PC and Mac OSes. Being a neophyte to this, I'm not exactly sure how to ask the question. I'd like to find a language and a few APIs by which it is easy to use to produce platform-independent code, or at least code that only require minor tweaks to hop around from OS to OS. I'm willing (and able) to go through a few hoops and code things like custom wrappers to handle it all. Even if I have to code a bit more to make things more adaptable, I'm cool with that.

Thanks!

[TheNut]

Believe it or not, the answer to your question is "most". Whether it's C/C++, Java, C#, Python, Ruby, HTML, etc. These all work on Windows and Mac. It really boils down to what you are willing to work with. Sooner or later, you're going to have to learn them all anyway

[Gnarlyman]

I see. I'm just trying to avoid dealing with too many versions of final code. Really, I'm only familiar with the XNA platform using C#. I've always been curious what all is involved in producing a Windows port of a game and then a Mac; as in, what adjustments, if any, are done, and is so, in what part of the development do whatever differences manifest as issues?

Also, I've come across haXe on here. Did some research on it. Looks pretty good... Can it handle high-end game programming? If so, that looks like a really favorable option.

[Stainless]

haXe is okay at what it does, it's no good for cross platform high end games. Even flash is being dropped in mobile devices, Adobe have stated they are no longer developing for it.

They have moved into HTML 5 development tools.

Doing true cross platform development is a pain, you have there options

1) Compile time generation
2) Interpreted code
3) Translated code

Compile time generation means that when you hit build all, a version is built for each platform supported, so you have one binary for each platform.
You have to rely on whomsoever creates the system to provide libraries and a compiler for each platform.

Interpreted code is the way Java ( puke ) works. You have a virtual machine for each platform but one binary. Generally virtual machines are limited in that they can only support the minimum spec hardware available. Since they have to run on all of the supported platforms, it's tricky to get the VM to support special case hardware.

Translated code is the one I like, you compile to an intermediate bytecode that is translated into native code when you load the binary. You have a single binary that runs on all supported hardware without recompilation. You get the best mix of portability and speed.

Whichever system you plump for you are still going to end up with run time flags to handle missing hardware ( or maybe compile time flags for the 1st option)

Cross platform coding isn't yet a simple task, unless of course you are only worried about a small subset of devices, but with the number of mobile phones still increasing and the number of games machines pretty constant, well it's up to you how far you want to go.

[geon]

I would say, it's not so much a matter of what language you use, as what libraries you use.

If you stay with cross-platform libraries like SDL and OpenGL, your code will work on pretty much any (library-supported) OS.

[alphadog]

Gnarlyman, on 15 January 2012 - 04:53 AM, said:

What's the best cross-platform language?

Everyone's jumped the gun. You want a cross-platform language for what end? It'd be a different answer if you wanted to make a YATC (Yet Another Tetris Clone) versus I want Crysis 15 on everything.

[Gnarlyman]

Hum hum, wow. You know, it was easy cruising around planning my game development around the 360 and XNA! I've recently realized that I really want to go PC, as I'm tracking trends about console gaming, online stuff, and generally, PC and digital purchases being the growing way to go.

Alphadog: no, lol, not a YATC; "real deal" games. I'm fairly content to master something essential like OpenGL and its shader libraries and use that to write cross-platform code. To be honest, out of the confines of console planning, I'm even confused somewhat as to all the levels of code--the various binary codes, compiler functionings, etc. I learned that stuff somewhere in the past, but being a 360er, I'm having to get a little more techie about what I usually just muddled over a bit more in abstractions. All I know is... I'd like to have a website where I let a user download what amounts to the "engine", and then download "gamefiles/game packages" for each game I produce that the engine will intake. I'd like to have it all work on Windows and OS X. Linux, I dunno, I'll start with the biggies. If I can employ a single content type (OpenGL and associated shaders, for instance) and make it all simple for me to hit both platforms, it'd be awesome.

[Stainless]

Have a look at Scrumm (may be Scrumm VM) , it was an engine for point and click adventures that has been re-engineered.

Now I don't think you could use it as is, but it might give you some ideas about how you want to design your engine.

[Reedbeta]

It's ScummVM I think you're thinking of, not Scrumm. Anyway, I haven't looked at the source code, but realize that this engine is basically a reverse-engineered emulator for a proprietary engine that's almost 25 years old now...so it may not have the best design or coding practices

[Gnarlyman]

I'll have a look at anyways, scope it out, see if there's anything I can adapt in any way. Like I've said before, I'm just looking for the most straight-forward solution to allow PC and Mac gamers to download my engine and what game packages they would like and have it running in a jiff without hardware or code errors or checks. I'd just like to find a language (doing C++ and C# right now), a few basic APIs (OpenGL seems great), and code 'er, get 'er done, and have a nice package that's fits most places. It's hard to navigate the right solution to finding a home for my designed and protoyped code (away from that nice XNA world, that is... ), especially with all sorts of things like binary codes builds, compilers, what that all means on different platforms. Sort of totally confused about all that right now. I'd stick to XNA, but I really truly need to target the other format.

[geon]

More games besides Scumm-based ones have used a VM with a minimal executable. A great example is Another World. It was relatively simple to port to a lot of platforms since all that needed porting was the VM, not the game code.

http://fabiensanglar...eview/index.php

[Stainless]

The way we started was by creating macros for everything.

So you wrote the game in our own macro code, then just included a header file for the z80 or the 6502 or the 68000.

While that technique is way, way, out of date, the principle is still valid.

How about you take the source code of one of the many scripting languages and port it to the targets you want to support. Extend the basic language with a native rendering library, and code everything for that.

Or if you are only targeting PC and MAC, stick with the XNA you know and get involved in the mono port of XNA.

Don't have time to look for the link, but I did look at it some time ago and there was quite a bit of progress on the project last I looked

[alphadog]

Gnarlyman, on 16 January 2012 - 10:45 PM, said:

I'd like to have a website where I let a user download what amounts to the "engine", and then download "gamefiles/game packages" for each game I produce that the engine will intake.

In that case, any engine will do. Any engine loads a game world, or elements thereof. The fact that the download source is online vs local is a minor distinction.

Look for a few modern, cross-platform engines with source to learn from them. SFML, Irrlicht, etc. These all target the main OSes, but not many have desktop + mobile targets *and* available source. Then, to learn, get on forums to talk to the devs and ask why they made some of the decisions they made.

BTW, the upcoming Win8 platform screws up the cross-platform scene. And, depending on the extent of "cross-platform", if you go with C#/Mono, you can add engines like Axiom and Horde3D. It's not so much that the engine is cross-platform, as it runs on a layer that is itself cross-platform.

There's also OpenTK to look at for cross-platformy ideas in the game dev realm.

[geon]

Gnarlyman, on 16 January 2012 - 10:45 PM, said:

I'd like to have a website where I let a user download what amounts to the "engine", and then download "gamefiles/game packages" for each game I produce that the engine will intake.

That's exactly what Unity does. Since you already code in C#, you should feel right at home.

[alphadog]

What Geon said. I re-read your email, and realized you want to make cross-platform games. Somehow I thought you wanted to make a cross-platform engine...

[Gnarlyman]

Great stuff, thanks. Great forum here, by far the best one I've been on.

So, it looks like something like Unity would do the trick. However, I wanna make sure I'll be able to add my own "extensions" to the engine. That's the reason I was developing my own prototype engine code in the first place, as I want to implement my own algorithms, shaders, and flat-out engine design pieces at certain places. Whether or not to take an existing engine and add-on or modify or to just build my own is the issue. I have several different approaches to matrices, lighting, and polygon manipulation that I've developed, and I'm figuring, what with help on this forum, that I'll actually be able to use an existing 3D engine/platform and modify/add rather than cook my own deal up from scratch. The main thing is, I'd like to jump on board to an existing engine/API that can handle window functions, already has a math set, has interfaces with which to talk to the GPU, and...all that low to mid-level hard-core tech stuff that cooking up from scratch would be fairly bonkers to do.

So, in a way, I'm trying to have both cross-platform games AND a cross-platform engine. If XNA and that mono port deal could do the trick, or if I could structure my own C# code around Unity, then I'm good. But what's this about Win8? Do I need to be planning around that? If so, does that screw up either or both of the XNA and Unity schemes?

[Stainless]

Win8 is a big argument at the moment.

It is organised in two layers. The new front end is based on HTML 5 and does not support any legacy code (no XNA, no Unity, etc.)

However Win8 intel based machines can still run legacy code, they just cannot use the new front end.

(Note this does not apply to risc based Win8 machines, even C# apps will not be supported on them which I find stupid)

Well at least that's the state of play as I know it. There are a lot of arguments about what Win8 really is, and mixed messages coming out of Microsoft are not helping.

Just look at http://forums.create...ms/t/91616.aspx and you will see what I mean.

[geon]

Gnarlyman, on 19 January 2012 - 05:12 PM, said:

Great stuff, thanks. Great forum here, by far the best one I've been on.

I know! always competent, helpful people around. I've been on this forum since Flipcode closed, and there since '99.

Gnarlyman, on 19 January 2012 - 05:12 PM, said:

I want to implement my own algorithms, shaders, and flat-out engine design pieces at certain places.

Algorithms - no problem.
Shaders - no problem
Engine design - might be a problem. It depends on what you want to do. If you buy the most expensive license (very, very expensive), you get access to the source, I think.

[alphadog]

Gnarlyman, on 19 January 2012 - 05:12 PM, said:

But what's this about Win8? Do I need to be planning around that? If so, does that screw up either or both of the XNA and Unity schemes?

Windows 8 will create a dichotomous platform:

• Metro/WinRT which currently is somewhat restrictive, where Unity may or may not go (and currently, the web player will not work there)
  
• Desktop, where the current Unity will keep on being available. What this means is that, until some sort of "Unity For Metro" comes out, you will not be selling Unity games for Metro through the Windows Store. (Although, the store, I think, will have links to outside sites, but that means you have to run a store yourself.)

Anyways, Win8 is a long way out (release is maybe mid next year?), and will have a long adoption and transitional period after that...

[Gnarlyman]

Thanks all, good input. Now, my turn...

Wowzers, I totally wasn't up to speed on Win8. (I've been slowly migrating in body and consciousness towards Mac, and now other things are forcing me to get realz with Win and all.) I find that all quite odd... Is there a particular and strong reason why MS is flipping over so much of the apple cart for the new OS? I do understand, and applaud, much newness and more streamlined/simple techs when redoing an OS, but it doesn't seem like backwards integration is huge there. I would wish that such things like XNA wouldn't be "legacy" things that require a bit of shapeshifting to work, but something that can take a seamless step into the new environment. Darn... Crossplatform stuff was hard enough, nevermind crossing a platform within a platform...

Several peeps on that forum mentioned D3D11. Would using D3D within a simple .NET environment right now be the best way for me perhaps? I suppose I'd just have to wing it more on my own with the engine components. Not crazy about D3D being only Win though... Perhaps just OpenGL is my way to go. ...Is that going to fly on Win8? Also, I couldn't tell exactly the gist about C++ and C#'s future there...

Also, on Unity: I downloaded it yesterday, played around with it, learning about it. It seems it's more of a "game creation" environment more than an actual code-oriented software (although I know that's there judging from online tutorials). I need to be able to programmatically mess around with nuts and bolts polygon and vertex info, lighting junk, blah blah, basically a bunch of custom shader and algorithm stuff that needs to fit in the pipeline in its heart. I'm trying to ascertain how much of the raw pipeline Unity shields you from, which is something I'm trying to avoid. Deal is, as mentioned above, I have my own set of polygon and lighting algorithms which are unorthodox in some ways, and I'm trying to find an engine, platform, API set, etc., which allows me to use the root, raw basic graphics functions (like displaying a window and handling polygon and world matrices...simple simple) and then program the rest on my own. Unity looks awesome; I just need to be able to get down 'n dirty with the code.