What's all this, now?
The
prior thread died of old age, so I'll take up the mantle of threadkeeper. This thread is about using XNA and C# to make your own games.
Oh, yeah, Xbox Live Indie Games. I've been meaning to check those out.
No! This thread isn't for info on new releases or reviews or discussion of the existing catalog. I'm sure another thread will be along shortly. Be honest - do you want to wade through five pages of discussion on content pipelines and compiler errors and streamwriters to find out if someone liked
Shoot 1Up as much as you did?
No, not really.
Good.
Okay.
Alright.
So... what's up?
Huh?
I still don't know what this thread is about.
Oh, yeah. Sorry. This thread is for PA community members to discuss their works in progress, whore out their latest releases, and to get help with various technical issues regarding game development.
So is this a new thing?
No! XNA has been around for over 2 years now. Version 4.0 comes out pretty soon here. In fact, several forumers here have been developing games ever since it came out, myself included!
Oh yeah?
Yeah.
Like who?
RainbowDespair and Slash000 are working on a 2d sprite based JRPG called Breath of Death, a spoof of Dragon Quest featuring a largely undead cast. Savooiperd has a stylish 2d platformer with customizable weapons. Trumpets has a pretty rad looking platformer as well. AlejandroDaJ has a geography game called Around the World that seems close to playtest stage. These are just from looking at a random page in the last thread. For more details, watch the thread.
Man, I wish I knew how to program.
Well, if you can't you're SOL.
Ha ha ha!
I'm serious. This isn't like RPG Maker 2000. You'll have to build everything yourself. XNA just takes care of stuff like loading assets, drawing objects, playing sounds. All the game logic is up to you.
What do I need, assuming I have some programming skils?
First, you'll want Visual Studio C#. Express 2008 is a free download.
http://www.microsoft.com/express/Windows/
Second, you'll want XNA itself. Get it here:
http://creators.xna.com/en-US/
If you want to test/release games on Xbox Live, you'll need a Creator's Club account, which runs $99 per year. It also gets you playtest access to upcoming titles. I'm on the fumes of a trial membership, so I can't say too much about full fledged Creator's Club. Maybe I'll update this when it runs out on the 24th.
I know some programming, but I don't know much about game programming specifically, or XNA
Well, the most amazing resource is Ziggyware. Sike! It got infested with malware and Ziggy didn't want to deal with it or something. There isn't really a site that matches it yet, but you can check out
http://rbwhitaker.wikidot.com/xna-tutorials or
http://www.riemers.net/eng/Tutorials/xnacsharp.php. Also, Shawn Hargreaves runs a pretty rad blog, which is pretty technical, but useful:
http://blogs.msdn.com/shawnhar/default.aspx
To get the thread jump started, I hope people with current projects will repost their current or latest info, because I don't really want to cull 100 pages of thread.
Old hands at XNA may with to PM me with additional info they think should be in the OP, and I'll modify it accordingly.
Edit:
RELEASED!
Download it now! Show support for PA devs!
http://marketplace.xbox.com/en-US/games/media/66acd000-77fe-1000-9115-d802585504bd/
motivatedbattle programmerRegistered User regular
Posts
Animal Crossing: New Leaf
3DS - 3797-6074-8327
Because this game is the game you wish your game could smell like.
Invite me: XBox Live | PS3 | Steam
Link to me: Number Sorter | Achievement Generator
Microsoft has a contest for XNA games called Dream Build Play, and the last iteration of it had an additional contest sponsored by Old Spice. Now that the results are in the people that didn't win are submitting their games to XBLIG because hey, why not?
Look at your game. Now look at mine. Look at yours, back to mine. Your game couldn't be mine. But it could smell like mine.
I'm on a horse
Invite me: XBox Live | PS3 | Steam
Link to me: Number Sorter | Achievement Generator
I'm still a little flummoxed though by how to properly organize things. When I get home (if I remember), I'll dig up my sources and see if I can identify some specific questions I had to pose to all you more practiced programmers.
Changing the orientation of the diagonal based on the vertex heights can produce smoother looking terrain. Personally I use a grid of equilateral triangles instead of squares, because this further reduces visual artefacts. Neither of these are really necessary for an RPG style game that isn't going for graphical realism.
GET OUT SCUM
But srsly, we all love games here. While OGRE 3D may be off-topic a bit, I don't think anyone will flame you so long as you do not completely derail the thread in a non-fun, non-intuitive way.
My own plan is to maybe make something using XNA, then build Steamworks into it and put it up on Steam. Steam generally seems to be the better distribution portal, offering neat promotions, even for indie titles.
Close - it's not about smoothness, but uniformity. Imagine a square laying flat on the ground. If you raise a single corner, one of two things will happen - if the corner touches the shared hypotenuse of the triangles that make up the square, you'll have a downward facing "fold". Otherwise, you'll have an upwards facing "fold" (in this case, you still have a whole triangle flat on the ground.
Is that clear at all?
Edit:
ah. that makes sense.
I'm thinking about scrapping my project (again) because of how much I seem to be developing a genuine hatred of 3d animation, and the horrible cycle of the only way you can get better at it is to keep doing it to get better at it but it's just evil. I imagine I will repeat this cycle again a few more times before I get to the point of putting a game out there, or just go "screw it" and charge forward, horrible animations and all.
Just go "screw it" dude. Have you seen some of the available games? Some of them are terrible, terrible abominations, even for 80 points. Plus, rough animation and graphics isn't a death sentence; games like Johnny Platform's Biscuit Romp are still pretty good even if they look like they're done with MS Paint.
Anyway, one of my big complaints with using C# for game development (and mind you, I love, love, love C#), is the lack of multiple inheritance, which makes doing a truly component based game architecture difficult, without jumping through some odd hips. This is one of those edge cases where true multiple inheritance is a god send.
This is one of the primary reasons I've shied away from XNA. If you look at my C++ engine that uses OGRE, my game objects are built as composites from many smaller, specialized, working parts.
So every object in the game sub-classes from Object, which provides some basic things all objects need (tags, id's, etc). But beyond Object, the game objects composite themselves. For instance, my Actor class is a sub-class of Object, but also mixes in (via multiple inheritance) the MeshRenderable and Scriptable components. What they do is pretty self evident by their names.
You could do this in C# using interfaces and some hackney eyed default-implementation scheme. You could also try and do it with a single inheritance tree, but you'd end up with a ton of bases classes that were only base classes because you needed that particular combination of mixin components in the inheritance chain.
How are you guys handling this in your XNA engines? Or are you not even trying to architect your game engines at that level? I write commercial software for a living, so I don't tend to "hack" anything together, I tend to design things right "the first time" and leave myself a maintainable, extensible, code base for later.
Honestly, I've never run into a situation where I felt I needed multiple inheritance. Most of the examples I've seen appeared contrived to me. Then again, I haven't used C++ in a while and have completely internalized the design perspective of C#. A friend of mine who codes mostly in C/C++ also seemed troubled that C# didn't have multiple inheritance, and seemed to dislike how if you attempt the same thing using interfaces, you end up with a lot of code duplication. But in actual use, I don't think it's come up.
I can only compare it to when I switch from Java to C# and vice versa. When I'm writing Java, it goes just fine. But Java does not support passing by reference, where as C# does. So what I find happening is that I will do lots of it in C#, but the thought never even occurs to me in Java. It's only when I try to translate one codebase to another that I even realized the difference in my coding habits with respect to the language I'm in.
I kind of dread going back there. I could do that shit in, say, PHP (not an especially concise language) in one line. In C#, it's like, four functions spread out amongst three classes and WTF I AM JUST TRYING TO LOAD A TREE BASED ON AN INI FILE.
What I wrote wasn't a 'rant', and my example is not contrived at all. Notice how I am building object in a composite fashion. This is hard to do without multiple inheritance. I also noted that it's an edge case, and in many cases multiple inheritance isn't needed (I don't find myself ever wanting it at work, where I write C# for a living).
But, this isn't a programming zealotry thread. I was simply asking how people were architecting their game engines with XNA, using how I use multiple inheritance in C++ as a backdrop for the discussion.
Nein sir. It supports multiple interface implementation, it does not support true multiple implementation inheritance.
A C# class can implement multiple interfaces, but cannot inherit multiple classes.
e: Bah.
Sorry, I didn't mean to insult by calling it a rant, I just didn't want to quote a large post.
Mostly I just don't think in terms of class heirarchies which converge instead of branch. It not being an option, I haven't even thought of what to do instead, because I never do that in the first place.
I do know that I have multiple subsystems in my game class library already. Anything that collides with something else needs to support ICollidable so my collision event service can do what it needs to do. Anything that accepts user input needs to support IControllable so that my control hub knows how to route controls around. My model animation system has IMeshAnimation interfaces and so on (since I have keyframe animation systems and procedural animation systems).
In theory, I could make all those interfaces classes, and then multiple inheritance things together when a class needs all of them. But frankly, almost every time I implement one of those classes, I do it in a radically different way, save for getting and setter functions on my various ICamera implementation (Ortho, Perspective, etc). And if a class needs them all, I've done something wrong. Because once upon a time, I did that, and it was a horrible debugging clusterfuck of a disaster.
Seriously, it was horrible, and the reason my first game never got close to finished.
I don't have the code here, so I can't post the header for any of my components, but basically if you look at Scriptable it contains all the pieces you need to wire up scripting for an object: storage for the script context, script context initialization, generic methods to call script functions, generic ways to load a script in to the context. These are operations that should, if things are designed correctly, be absolutely 100% the same for everyone object. If you do need to overload the default behavior, everything is marked virtual (except getters and setters, makes them too slow).
The inheriting component object can then use those generic facilities to wire up scripting in an object specific way.
I'm curious as to what tutorials/samples people have folded into their game. I know I have the Skinned animation sample, particles sample, and deferred shading tutorial (from Catalin Zima). What other stuff? I think I saw the "safe area" component being used in someone's video (Delzhand's?).
Well, the reason I'm using interfaces instead of inheritance is because they are vastly different implementations. There is zero commonality between how a keyframe animation system calculates its animation matrix and how a procedural one does.
I think in all my years of programming I've run into a situation where I needed multiple inheritance once. And it only came up because I had to create an extension to an existing class hierarchy that I couldn't change.
It sounds like you're designing much more monolithic classes than would work in C# and XNA. My design is split into more interchangeable parts.
I make heavy use of utility classes and methods. So while your class might look like:
public class Entity : Object, Scriptable { public void RunScript() { this.ExecuteScriptAction(); } }Mine looks like:
public class Entity : Object implements IScriptable { public void RunScript() { this.ScriptAction.Execute(); } }So they work fundamentally the same way, but mine is less tied to a specific implementation of scripting, since I could always just instantiate a different class.
Edit: To be fair, yours has the advantage of saving a few lines of code in the Deserialization method.
The problem here is that you have to re-implement IScriptable every time you want to create a scriptable object. You don't get any advantages of having the most mundane, completely generic, parts of scripting be drop-and-drop mixable.
I have several places this makes a lot of sense to me. For instance, my Actor class is Scriptable, so is my CombatEngine class. They share no other similarities, except they both need a place to store a scripting context, and both need a way to call methods inside that context. My Static class and my Actor class are both Scriptable, and both game Objects, but one is a AnimatedRenderable, the other is a MeshRenderable...because static object's don't need to render an animated mesh. Yes, I could have had an IAnimatedRenderable and an IMeshRenderable, but again, I would be stuck reimplementing the same interface twice on two separate objects.
I could have an IScriptable interface, but then Actor and CombatEngine would both need to implement IScriptable (or would need to aggregate an object that does, which is by no means any cleaner). I need to do neither, I just need to publically inherit Scriptable. The illusion that using interface implementation and aggregation gives you the magic bullet so that you can easily change scripting engines is just that, an illusion. It's no easier, or more difficult, than for me to simply change the Scriptable base class implementation.
Object composites are that edge case where multiple inheritance clearly outshines interface implementation and aggregation. This is why there are several C# engines out there trying to provide object composites that don't look horrible in the framework of interface implementation and aggregation.
e: Also, by the very definition of my system, my classes are not monolithic even in the slightest. Scriptable does scripting, that's it. It does it very well, and in a completely sub-class agnostic way. I can hang Scriptable off of anything, not just game objects sub-classing from Object. And I do, given by my CombatEngine v. Actor example. Both are Scriptable, but share zero similarities beyond that. That's is the exact definition of extensible and reusable (aka not monolithic).
edit: Yes, this is a bit more of a pain in the neck to implement: you need a scripting context getter, and interfaces to support accessing contexts, and it makes it more awkward if you want to access two conceptual entities at the same time. On the other hand, it protects you from the reasons why multiple inheritance was considered dangerous in the first place: if you do something in ScriptContext which conflicts with AnimationContext - give two fields the same name, for example - then that's not a problem, because they're entirely separate entities.
You answered your own question in your edit. If I was doing this in C#, I would have no choice but to do what you suggest (which is composition through aggregation, btw). The "danger" of multiple inheritance is not lessened in C#. I can still have two interface that have a conflicting method, or property, signatures. I just have to implement one of the interfaces explicitly (IInterface.ConflictingMethod), rather than implicitly. In some ways, this is more dangerous than the multiple inheritance case. At least one tells me at compile time I have an ambiguous symbol, the other lets me work around it and then basically hide the conflicting method, rather than correctly design my interfaces.
Also, if you keep your fields 'private' in C++ (which you should be doing, sub-classes don't need to access fields, they should have protected/public getters/setters if they need access), then you can have 15 base classes all with the private field '_name' and not conflict.
But this is devolving into a "No, MY coding practices are the best" type argument.
XNA and C# is a poor fit for you. Thats ok. You asked how things can be done in XNA, you've been told, and you've said quite profoundly "BUT I DON'T WANNA!".
Moving on, I'm hoping to steal away some time this weekend to work on my game stuff. Lazy sunday hopefully.
Object -> Scriptable -> CombatEngine
Object -> Scriptable -> Renderable -> AnimatedRenderable -> Actor
Object -> Scriptable -> Rendarable -> MeshRenderable -> Actor
Why aren't all your meshes inheriting from Scriptable? Alternatively, if they need a Script Context, why don't you have a ScriptContext object?
And the definition of a monolithic class I've always heard is a class that tries to do too much on its own. You're pasting all these objects together into something enormous, when you could be creating other objects to handle their own tasks.
I'm relatively new to C#, from a Java background, and I'm unconvinced about the usefulness of that device, and at my current level of experience with the language I'd agree that explicit interface implementation seems unnecessary and a crutch for poor interface design: I'll freely admit I may be missing contexts where it's particularly useful.
And yes, by properly designing the code from day 1 you can avoid the dangers of multiple inheritance: it's much more of an issue in larger projects where different people are maintaining and extending other people's classes, where work on one class could break other classes that extend it due to unexpected interactions. Y'know, the sort of projects C# was designed for.
So the argument against composition by aggregation is: it's a little more verbose to implement, right?
That's the main argument yes, it can be way, way more verbose to implement as your interfaces grow in size. It can also lead to a lot of cut-and-paste boiler plate code, rather than sticking very cleanly to DRY.
Because CombatEngine doesn't need to be an Object, it needs to be a Scriptable. Yes, I could create one gigantic single inheritance tree to get what I wanted. It would be a mess. Not every Renderable needs to be Scriptable, not every Scriptable needs to be an Object. Not every Object needs to be Scriptable. So I would end up with wacky base classes like "ScriptableRenderableObject", just to enforce the proper inheritance chain.
And your definition of a monolithic class is very wrong. A monolithic class would be if I tried to implement the ideas behind Scriptable, MeshRenderable and Object as one gigantic class. A monolithic class is not one that is composed of smaller, non monolithic components, to create one larger logic object. That's good OO design. Classes should do one thing, and do them very well. That doesn't preclude that class from needing do the exact things it's composite bases provide. If I tried to rig up Actor, CombatEngine and Trigger all to be Scriptable, without a common base (or at the very least an aggregate interface implementation), that would be monolithic. Having those three classes all inherit Scriptable, which does it for them, is not monolithic. It's extensible, reusable and follows DRY.
Hell, in my SRPG, it's even simpler. Unit is extended by UnitPC and UnitAI.
Uhh, actually, it's just an interesting discussion about game engine design, in a thread that prior to me asking the question had almost no movement or discussion. I know how to achieve what I am doing in C++ reasonably well in C#, I write C# for a living after all, and have been using it since .NET 1.0 beta.
I was simply starting a discussion about game engine design, and how the language your using (in my case C++, yours C#) changes (sometimes fundamentally) how you design your engine.
Hehe, it's okay man. Frankly, my engine is probably a tad over designed in places, but god damn if the code doesn't look gorgeous. And that's what matters, right? RIGHT GUYS?!
Which leads to problem #2: Repeating a lot of boiler plate code cut and paste style, because there will end up being a common set of operations you can distill out of those disparate IScriptable implementations.
It's less than a day old, mang. The last XNA thread only managed 100 pages in a year+ of discussion. It tends to be a long-haul thread.
getScriptContext() doesn't contain any logic. It just returns a field. Which means, really, only argument 1 - that it's a bit more work - applies, and in a case where you don't have multiple inheritance at your disposal, you're looking at approaches which will require more effort, and this isn't much more effort for a very similar effect.
Hell, I'd say this is a case of DRY. Maybe not quite so direct as multiple inheritance, but the sort of situations you're describing sound to me like a natural fit for composition by aggregation.
Not dissin the thread mang, just pointing out, I was just starting a discussion, and it's gotten the thread hoppin', I might add.
Anyway, I am making an 'evil' comedy action RPG. Basically everything is reversed. You live in the evil cave, the evil wizards are your beer buddies, and it's your job to go slaughter the inhabitants of every town, temple and castle you find. I'm working the loot angle in to the story, where the constant pursuit of "phat lewt" actually has a story reason, inside your evil brotherhood.
The classes available will be an offering of evil: Demon Lord, Warlock, Succubus and Despotic Warlord.
If the tools you are working with have no multiple inheritance available, then absolutely, composition by aggregation is exactly how you would achieve what I am doing. It would be the only (smart) way to do it.
In the presence of multiple inheritance, that obviously becomes the preferred way to achieve object compositing. Why would I do composition by aggregation in C++ when I can do the less verbose composition by inheritance?