|
How viable is C# for game development? I imagine XNA plays a big part in this. I just started a full time job where I develop C# and Silverlight stuff, so I'd hope I get good enough at this stuff to be able to make games with it. (Awesome, new page with a stupid question)
|
#
?
Aug 15, 2011 21:50
|
|
|
|
| # ? May 12, 2024 15:25 |
|
|
C# is very viable. XNA is great but also you can do vid card stuff like you could with directX (I think) without having to worry about stupid memory management.
|
|
#
?
Aug 15, 2011 22:11
|
|
|
Doh004 posted:How viable is C# for game development? I imagine XNA plays a big part in this. I just started a full time job where I develop C# and Silverlight stuff, so I'd hope I get good enough at this stuff to be able to make games with it. It's perfectly viable, XNA is pretty powerful. It's also pretty easy to get up and running, especially for 2D stuff.
|
|
#
?
Aug 15, 2011 22:12
|
|
|
roomforthetuna posted:That's a good point and a question I probably should have gone with first - is there a system that's not overly complicated that's significantly better than octrees for my particular purpose? What I have is a 3D space into which many immobile convex shapes are added (rarely removed, but more added on-the-fly) and a small number of moving objects that can collide with the immobile shapes. For moving object to moving object collision I'm just going to do a flat "all against all" comparison because there won't be more than 16 of those. Some (many?) of the immobile shapes will be long and thin, which may not suit octrees very well. There's a modification you can make to the octree algorithm to alleviate the problem: 1) Only ever add objects to the leaves of the tree, never to the other nodes. 2) In situations where objects cross node/leaf boundaries, add your object to multiple leaves. 3) Each object needs to have a "Checked" flag that's initialized to false 4) When scanning the tree, set the Checked flag of objects to true as you do tests with them, if the flag is already set to true, then don't retest the object 5) As you scan, maintain a list of all objects that have been checked. When the scan ends, go through the list and set the flags back to false for the next scan. You'll avoid a lot of unnecessary checks for borderline objects, in exchange for the cost of maintaining/clearing all the checked flags. I have to admit, I've never actually tried this, it was just an idea I had when I was working on a similar problem once. I'm pretty sure it'll work, though if you have very few border line objects I'd imagine it would be slightly slower than a regular octree. Also, depending on how many things you have in your octree, it may not actually be as much of a problem as you imagine. If it really is "some" (i.e. 10-20%) of the objects that don't make it as far as the leaves, it probably won't be too bad, especially if you put AABBs around your convex hulls for a pre-test before doing the more complex checks. Gerblyn fucked around with this message at 22:41 on Aug 15, 2011 |
|
#
?
Aug 15, 2011 22:16
|
|
|
Doh004 posted:How viable is C# for game development? I imagine XNA plays a big part in this. I just started a full time job where I develop C# and Silverlight stuff, so I'd hope I get good enough at this stuff to be able to make games with it. Very viable. XNA by itself is fantastic, but there are also a bunch of higher-level engines. Unity in particular is great. I'm doing some pretty processor intensive stuff on the Xbox 360 with it right now, and it's been just criminally easy getting it up and running. The performance is good, too.
|
|
#
?
Aug 15, 2011 22:16
|
|
|
Gerblyn posted:There's a modification you can make to the octree algorithm to alleviate the problem: quote:Also, depending on how many things you have in your octree, it may not actually be as much of a problem as you imagine. If it really is "some" (i.e. 10-20%) of the objects that don't make it as far as the leaves, it probably won't be too bad, especially if you put AABBs around your convex hulls for a pre-test before doing the more complex checks. But even so it'd still only be 16*n, not the usual n*n that makes optimization really important. roomforthetuna fucked around with this message at 22:33 on Aug 15, 2011 |
|
#
?
Aug 15, 2011 22:30
|
|
|
Well, the octree still helps you to quickly identify which sections in the grid you need to look in, but with a lot of applications I guess you may be right. I think in your situation, I would go for a vanilla octree regardless. It's pretty much guaranteed to be faster than a brute-force-everything approach, and will give you a bit of peace of mind if you suddenly start wondering what would happen if you dropped 5,000 extra collision blocks into the world.
|
|
#
?
Aug 15, 2011 22:47
|
|
|
This Post Sucks posted:I'm an Actionscript coder but have mostly only done Flex apps and the like. I've done very little work in Flash itself. What would be the best route to start in to game development? Flixel owns, but the flash IDE sucks for it so either use Flexbuilder (very not free) or FlashDevelop (very free). It's very easy to get started with, even if you're a non-coder (which you aren't). It's the same thing Stencyl uses, but I vastly prefer to work in FlashDevelop then with Stencyl.
|
|
#
?
Aug 15, 2011 23:10
|
|
|
roomforthetuna posted:I could probably even just about get away with always checking against everything. It's only the fact that the number of immobile objects can get almost arbitrarily large that makes me concerned enough to octree it. If you don't know that you'll need an octree or some other fancy structure, I'd suggest just coming up with some generic collision system interface and implementing the code behind the interface using the simplest possible thing you can think of. If you find that the simple solution isn't fast enough you can re-work it without affecting the rest of your code so long as the interface stays the same. Off the top of my head the interface might include AddObject, RemoveObject, RemoveAllObjects and CheckCollision methods. Start the implementation with a simple list of stuff the mobile parts can collide into and if that's not fast enough then start looking at octrees or whatever. You might be overthinking a problem that doesn't exist, and I can sympathize with that because I do it too. I've found that the 'just design the interface for now' trick along with some kind of on-screen performance monitor is usually enough to quiet my inner sperg and keep me from wasting days searching for the magical perfect algorithm that will cut my CPU usage from 3.54% down to 3.50%.  Doh004 posted:How viable is C# for game development? I imagine XNA plays a big part in this. I just started a full time job where I develop C# and Silverlight stuff, so I'd hope I get good enough at this stuff to be able to make games with it. C# works very well for games, and as others have mentioned XNA is a pretty nice system to work with too. If for whatever reason XNA isn't your cup of tea you can also use SlimDX to talk directly to DirectX.
|
|
#
?
Aug 15, 2011 23:25
|
|
|
roomforthetuna posted:That's a good point and a question I probably should have gone with first - is there a system that's not overly complicated that's significantly better than octrees for my particular purpose? What I have is a 3D space into which many immobile convex shapes are added (rarely removed, but more added on-the-fly) and a small number of moving objects that can collide with the immobile shapes. For moving object to moving object collision I'm just going to do a flat "all against all" comparison because there won't be more than 16 of those. Some (many?) of the immobile shapes will be long and thin, which may not suit octrees very well. Bounding Volume Hierarchy -- think of it like an octree (or a KD tree) where you arbitrarily choose which dimension to split on and where to place the partition based on what's in the parent node.
|
|
#
?
Aug 15, 2011 23:31
|
|
|
ambushsabre posted:Flixel owns, but the flash IDE sucks for it so either use Flexbuilder (very not free) or FlashDevelop (very free). It's very easy to get started with, even if you're a non-coder (which you aren't). It's the same thing Stencyl uses, but I vastly prefer to work in FlashDevelop then with Stencyl. Cool, good to know. I've got a copy of Flash Builder 4.5 (what Flex Builder is called now), so I've got a nice IDE to work in. Working through some docs and examples now! Edit: Oh, hey, I guess this would be as good as place as any to post this, and it may be helpful to some folks in here. Stanford University is offering a free Artificial Intelligence class online. You can sign up here: http://www.ai-class.com/ It's actually what got me to start thinking about game development again. This Post Sucks fucked around with this message at 23:57 on Aug 15, 2011 |
|
#
?
Aug 15, 2011 23:52
|
|
|
PDP-1 posted:Off the top of my head the interface might include AddObject, RemoveObject, RemoveAllObjects and CheckCollision methods. Start the implementation with a simple list of stuff the mobile parts can collide into and if that's not fast enough then start looking at octrees or whatever. So if I wanted to change it from an octree now it would be pretty simple to switch that out for a different structure (other than the whole "implementing a different structure" part). Would probably be even easier to switch out if it was an actual iterator. quote:You might be overthinking a problem that doesn't exist, and I can sympathize with that because I do it too. I've found that the 'just design the interface for now' trick along with some kind of on-screen performance monitor is usually enough to quiet my inner sperg and keep me from wasting days searching for the magical perfect algorithm that will cut my CPU usage from 3.54% down to 3.50%.
|
|
#
?
Aug 16, 2011 01:59
|
|
|
The main drawback with C# for game development is that you can't count on your source code being secure. It's pretty easy (much more so than other languages) to reverse-compile the files. There's some obfuscators but that just makes it a tiny bit more involved. If that doesn't bother you too much it's a great language.
|
|
#
?
Aug 16, 2011 18:43
|
|
|
The Saddest Robot posted:The main drawback with C# for game development is that you can't count on your source code being secure. It's pretty easy (much more so than other languages) to reverse-compile the files. There's some obfuscators but that just makes it a tiny bit more involved. Isn't that also an issue with java? And any other language that uses "virtualized" machine code? (i'm not 100% certain i'm using the correct words, or even understanding the technology)
|
|
#
?
Aug 16, 2011 20:46
|
|
|
The Fool posted:Isn't that also an issue with java? And any other language that uses "virtualized" machine code? You are correct.
|
|
#
?
Aug 16, 2011 21:08
|
|
|
It's also probably not a major issue for anyone looking to get into hobby game development. I think as developers we have too much fear over people stealing our ideas or code. Look at Notch and Minecraft -- Java application, somewhat obfuscated. People get into the code, and generally use that to build mods and suggest improvements.
|
|
#
?
Aug 16, 2011 22:58
|
|
|
Yep. Like piracy, it's one of those problems that are nice to have. If people care about your game to try reverse engineering it then congratulations, you've already won.
|
|
#
?
Aug 16, 2011 23:02
|
|
|
Wolfsbane posted:Yep. Like piracy, it's one of those problems that are nice to have. If people care about your game to try reverse engineering it then congratulations, you've already won.
|
|
#
?
Aug 17, 2011 03:22
|
|
|
The Saddest Robot posted:The main drawback with C# for game development is that you can't count on your source code being secure. It's pretty easy (much more so than other languages) to reverse-compile the files. There's some obfuscators but that just makes it a tiny bit more involved. That isn't even close to the main issue with C# for game development. Lack of platform support, no fine control over memory management, lack of middleware, frame rate stuttering during garbage collection - those are real issues. Nobody cares about reverse engineering except for maybe the drm module.
|
|
#
?
Aug 17, 2011 04:43
|
|
|
Paniolo posted:That isn't even close to the main issue with C# for game development. Lack of platform support, no fine control over memory management, lack of middleware, frame rate stuttering during garbage collection - those are real issues. Nobody cares about reverse engineering except for maybe the drm module. As long as you know what the garbage collector is doing, or want to learn a bit of interop (which is easy), you can easily do whatever you want with memory in areas that have problems if garbage collection is used naively, by allocating object pools and managing those yourself, or just using windows memory allocation via interop. Both are far easier than managing C++ memory. It's certainly no more work than managing memory with C++, and profoundly less error prone. Platform support is a true issue, however. If you're happy with windows only (and maybe mono if you do some work), C# is a really excellent language, and for a skilled programmer can be multiples more productive than writing the exact same code in C++. Far less time is spent writing infrastructure and running down crashes, and can instead be spent writing actual game code. Many pieces of middleware now have C# interop layers, or have DLLs that you can interop with yourself, however your selection is more limited than if you use C++. I'm not a professional game developer, though, so my experience with game middleware is limited. Unormal fucked around with this message at 05:06 on Aug 17, 2011 |
|
#
?
Aug 17, 2011 04:56
|
|
|
Oh, I'd agree that C# is perfectly viable for basically anyone posting in this thread. The issues I listed are more reasons why C# hasn't taken off for AAA game development especially on consoles. I could be wrong but I believe C# is actually an option for XBLA games (not XBLIG where it is mandatory) but most are still written in C++ for some of the reasons I mentioned. Paniolo fucked around with this message at 06:07 on Aug 17, 2011 |
|
#
?
Aug 17, 2011 06:02
|
|
|
Pfhreak posted:It's also probably not a major issue for anyone looking to get into hobby game development. I think as developers we have too much fear over people stealing our ideas or code. Look at Notch and Minecraft -- Java application, somewhat obfuscated. People get into the code, and generally use that to build mods and suggest improvements. There are really only two threats from easily-reversible source code: Multiplayer hacks and piracy.
|
|
#
?
Aug 17, 2011 07:03
|
|
|
Paniolo posted:Oh, I'd agree that C# is perfectly viable for basically anyone posting in this thread. The issues I listed are more reasons why C# hasn't taken off for AAA game development especially on consoles. Basically Microsoft don't wanna gently caress around with anyone who isn't going to sell thousands of units. XBLA is for serious poo poo.
|
|
#
?
Aug 17, 2011 17:11
|
|
|
I haven't really looked into it, but I thought XBLA had an indy section where it was fairly easy to publish games?
|
|
#
?
Aug 17, 2011 17:35
|
|
|
Newbie question:  I'm going through "Starting out with C++" (2004 Edition, was cheap on amazon) so far I understand everything I've learned without a mild amount of effort. I'm currently at the first chapter on arrays (past functions/loops) but I have one concern. I usually look over the code before I attempt to copy/compile it and try to understand how it works. This gets a bit tricky with loops and it takes some effort (sometimes a few diagrams) to understand the flow. I'm wondering if there comes a point where it becomes second nature to understand the flow of a loop. Will it eventually become second nature to come up with the logic to code my own loops when I start making my own programs? Also, I've found arrays to be the most interesting chapter I've encountered so far. I remembered that the graphics within an NES game were just 8 x 8 blocks or arrays of color. I'm assuming that a game with such hardware limitations would have to recycle a few arrays (if you consider hundreds a few) all the time. Am I on the right track with that assumption? If so do modern (ex: Mega Man 9/10) 2D games still do that? Or would they simply load the graphics from a file? Sephiroth_IRA fucked around with this message at 17:54 on Aug 17, 2011 |
|
#
?
Aug 17, 2011 17:38
|
|
|
Orange Lazarus: Loops are only the beginning, but yes, in time they will become second nature. I recommend reading This.
|
|
#
?
Aug 17, 2011 17:44
|
|
|
Gerblyn posted:I haven't really looked into it, but I thought XBLA had an indy section where it was fairly easy to publish games? By contrast, you really don't want to use C#/XNA for XBLA, though I believe there are a few games that have done so. If your target is XBLA as an indie, you're better off either doing C/C++ or picking an engine with a known portability vector to Xbox 360 (like UE3/UDK, etc).
|
|
#
?
Aug 17, 2011 17:59
|
|
|
Ah, sorry. I skipped half the conversation.
|
|
#
?
Aug 17, 2011 18:03
|
|
|
Shalinor posted:By contrast, you really don't want to use C#/XNA for XBLA, though I believe there are a few games that have done so. If your target is XBLA as an indie, you're better off either doing C/C++ or picking an engine with a known portability vector to Xbox 360 (like UE3/UDK, etc).
|
|
#
?
Aug 17, 2011 19:59
|
|
|
OneEightHundred posted:I keep thinking that there has to be a market for a low-cost engine bolt-on for XNA. I'd be all over making one if I wasn't busy with a C++ project that is of course completely unportable to it.
|
|
#
?
Aug 17, 2011 20:26
|
|
|
OneEightHundred posted:I keep thinking that there has to be a market for a low-cost engine bolt-on for XNA. I'd be all over making one if I wasn't busy with a C++ project that is of course completely unportable to it. I'm waiting for a killer Javascript engine to come out that can run either in a web browser or in a specialized native environment on a mobile or console, with a completely unified interface. I've already seen something similar that can run on iOS and Android, but the first company who can produce a killer engine with great documentation and tools which runs on any conceivable platform is going to be in a great position.
|
|
#
?
Aug 18, 2011 04:15
|
|
|
Paniolo posted:I'm waiting for a killer Javascript engine to come out that can run either in a web browser or in a specialized native environment on a mobile or console, with a completely unified interface. I've already seen something similar that can run on iOS and Android, but the first company who can produce a killer engine with great documentation and tools which runs on any conceivable platform is going to be in a great position. Unity is pretty close, isn't it?
|
|
#
?
Aug 18, 2011 06:32
|
|
|
Paniolo posted:I'm waiting for a killer Javascript engine to come out that can run either in a web browser or in a specialized native environment on a mobile or console, with a completely unified interface. I've already seen something similar that can run on iOS and Android, but the first company who can produce a killer engine with great documentation and tools which runs on any conceivable platform is going to be in a great position. Shalinor posted:I don't know - I'm kind of thinking that stuff like the Flixel support for XNA/Xbox Indie is really the right way to go, there.
|
|
#
?
Aug 18, 2011 16:12
|
|
|
Orange_Lazarus posted:Also, I've found arrays to be the most interesting chapter I've encountered so far. I remembered that the graphics within an NES game were just 8 x 8 blocks or arrays of color. I'm assuming that a game with such hardware limitations would have to recycle a few arrays (if you consider hundreds a few) all the time. Am I on the right track with that assumption? If so do modern (ex: Mega Man 9/10) 2D games still do that? Or would they simply load the graphics from a file? You'll be using graphics libraries for that kind of stuff, rather than creating your own data structures. At the lowest level, bitmap data is still always going to be held in some kind of (possibly compressed/encoded) array-like format, but you're going to be accessing it through functions that do things like loading an image from a file, or copying pixels from a specified rectangle in a source image and putting them into another image at a specified point. You're not going to be manually setting the color of every god drat pixel individually, if that's what you're worried about (though you certainly can set the color of individual pixels if that's what you want to do).
|
|
#
?
Aug 18, 2011 18:24
|
|
|
OneEightHundred posted:I think there are still practical issues, mainly with input and sound. The asset pipeline does leave a lot to be desired, but for physics, BEPU isn't bad.
|
|
#
?
Aug 18, 2011 22:27
|
|
|
OneEightHundred posted:Well, I mean if you wanted to scale XNA up to the quality of game on XBLA there really isn't anything about XNA that's stopping you. A big source of inspiration would be Bastion, which I've recently found out from the PC demo that it uses XNA/.NET. I didn't expect that but it makes sense given their rapid development time from just two programmers.
|
|
#
?
Aug 20, 2011 05:25
|
|
|
ShinAli posted:A big source of inspiration would be Bastion, which I've recently found out from the PC demo that it uses XNA/.NET. I didn't expect that but it makes sense given their rapid development time from just two programmers. You mean 7 people over two years? http://supergiantgames.com/?page_id=2 However, the use of XNA is pretty incredible, also, it's apparently all 2d and painted. Gorgeous looking game. Edit: re-reading your post, I realize that you're not implying that the entire team is 2 people, just that there are two programmers, sorry The Fool fucked around with this message at 18:11 on Aug 20, 2011 |
|
#
?
Aug 20, 2011 17:57
|
|
|
The Fool posted:You mean 7 people over two years? Of which two are listed as engineers.
|
|
#
?
Aug 20, 2011 18:05
|
|
|
I have another potentially stupid question: How is Silverlight for game development?
|
|
#
?
Aug 23, 2011 21:56
|
|
|
|
| # ? May 12, 2024 15:25 |
|
|
Doh004 posted:I have another potentially stupid question: How is Silverlight for game development?
|
|
#
?
Aug 23, 2011 23:08
|
|