If your PC version can generate the randomised rooms, then why don't you use that to generate a set and save them out for loading by the xbox version?

Not ideal but easier than modelling them all by hand.

That blog post is largely concerned with models going through the content processor. You can create assets for walls to furnishings or whatever and construct rooms procedurally in-game with instancing easily enough. The cavat is that complicated geometry should be processed on your PC, as I'm sure it is now.

But also, there's nothing to stop you creating textured tri-strips and whatnot in game. The Carrion Re-Animating map is completely 2D in the editor and saved file. It doesn't become 3D objects until the game is loaded, where it creates 3D tri-strips and tri-lists, loads all the models and instances them in places the dummy objects in the editor were saved out etc.

Will you be able to save 'Templates'? So at the start of a mission you could pick from previously made designs? Or do you always have to start from scratch?

And will I be able to customise colours / textures / etc? If you hadn't noticed I'm a massive fan of customisation in games and I would spend ages tinkering away making my designs "just so" if I had the functionality. But I'd want to be able to save my designs so I didn't lose all that work.

The prototype is just a simple 2D flash game (originally written for the Gibbage forums "Make Something By April 30th" thingee ), so it's not an option. But thanks for the suggestion




Yep, that's pretty much where my brain went after I found out my original "dynamically modify the mesh" plan turned out to be non-viable. Thanks for confirming and for the Carrion details.




Saved templates are a fab idea, and with the lovely C# XML handling I can't think of a reason not to (unless there are some file saving restrictions on XBox community games that I don't know about ).



Textures maybe not, but I have considered allowing player colour mods for some parts (like the dome and case around the system core). We'll see how it goes

the one saving restriction is that you can only save files as 'saved games' effectively, not directly into the game data. Basically you can open a 'bucket' with a name to save files into. In this bucket you can save what the hell you like. It's rather funky.

If you have, say, 2 or 3 different shaders applied to your various component parts, would it not be possible to edit 2 or 3 RGB sliders which hook into the shaders somehow - like a colour tint?

Also, will there be purely decorative ship components, like little spikes that I can plop over the hull, etc? Bits which serve no purpose insofar as shields / speed / firepower / etc go, and are therefore very cheap to add, but would allow me to create something that I feel is 'mine'?

Especially if there is an on-line component to your game, it would be extremely important to me to feel like I could create something unlike anything else I'm likely to encounter. This goes for single-player for me too, but it becomes more apparent when you're playing against other user-generated content.

I get frustrated by customisable games which turn out to be not terribly customisable. It's like dangling a carrot in front of someone which turns out to be made of marzipan. If your editor is sufficiently powerful and the scope of parts to unlock is reasonably large, then you'd be adding to the longevity and replayability of your game by a factor of loads. Similarly, feeling like there is little to do with the editor would quickly turn me off playing.

Yes, easily done. Right now the Diffuse, Emissive and Specular values for each item are read from an XML file. It's just a matter of exposing those values to user control.



I'M ONLY ONE MAN, BINKY!

We'll see how it goes. I don't want to spend 4 years making this

Yay! Proper geometry on the floor so it's now lit correctly.




Still have to update it so it uses indexed primitives instead of just a brute force triangle list...

Figured it was time to update this thread! I did get my index buffered floors working (I know you've all been wondering ) and started working on the room generation. Then there was TOJam (see my thread about it here if you haven't already)

Here's the latest plan - I'm going to make XNA Pond Scum before continuing with SHUMM. Here's why:

a) I can repurpose much of the SHUMM code for Pond Scum.
b) Pond Scum is much less complex than SHUMM in both code and resources, and can be finished and (hopefully) generating income much sooner.
c) I can repurpose completed Pond Scum code back in to SHUMM.
d) I figure I can milk the fact that the prototype was built at TOJam into some kind of free publicity.

So, that's where it's at. Who knows, if I keep making critical business decisions like this, I just might yet turn myself into some kind of business-talkin'-guy.

First XNA Pond Scum screen!



Still not happy with the look of the bubble, but its a start.

NecroThread

Almost a year since that last post! So... I didn't stick with Pond Scum for long and it's staying on the back burner. My Creator's Club expired, and I didn't have the cash to renew it. So, I ported SHUMM as is over to Windows:
[img]http://notsoftmedia.com/screens/SHUMM/SHUMMBuilder.jpg[/img]
[img]http://notsoftmedia.com/screens/SHUMM/SHUMMShot1.jpg[/img]

I had 2 compile errors in the .fx file that I had frankensteined together that I had to overcome in the PC port. For one of them, I just had to reduce the size of the texture used for the shadows (which is why they look more jagged in the latest screen). The other was weirder than that! I don't remember the actual error message, but the gist of it was "there are too many calculations going on in this function"

I selectively commented out two lines from the shader (which is why the glowy bits look a little less colourful in the latest screen) and was able to compile

I hacked in some keyboard and mouse movement code so I could move about, only to find that the game stutters like hell at most resolutions (playably smooth at 320 x 240 ).

Anyway, I've gone back to my Design Docs and am fleshing out the elements and scope of the game. I love this bit

Pro-tip, next time DBP is announced sign up and you get a 12 month Creators Club trial even if you don't submit anything. You can deploy to 360 but you can't submit games to sell.

Actually, if you ask nice on the XNA forums someone might have a spare one.

I'll buy a CC membership again when the time comes. I just excited to make this game - I'm still at the giddy heights of planning where everything is possible

Hi there!.
I'm really interested in how are you using XML to manipulate meshes, textures, I assume the SHUMM ship builder also, and exposing it to the user?
I can't help but notice that the SHUMM ship builder was already up and running with GUI and all by the second page of this thread...

I feel I'm doing things the hard way because of lack of experience (XNA and C# being the first and only true programming roads I have taken). And things like de-coupling, Dependency Injections, data driven XML descriptions eludes me big time!.

Could you point me to some tutorial or a basic startup implementation?.
Or perhaps this topic could deserve a sweet spot along the sides of the neat and awesome Factories, Timers, Patterns, Listeners, etc. threads in the tutorials page.

Hi amertinez1660!

When I saw your handle I assumed it was a spambot crapping in my thread, and was pleasantly surprised to see that's not the case

I'm not actually using XML to "manipulate" meshes and textures. Instead I have two .xml files, one defines each "game object", including what mesh and texture it should be using, it's scale/rotation, mass, colours, etc.. The second defines composite objects, which are made up of the game objects. I'll include a snippet of each one to better illustrate:

Here's a section from my codex.xml which defines all game objects (but only showing a single item here):


Basically I've got a gameObject class to which I can pass a XML node to, which will parse it, extract the data and initialize itself.

Here's a snippet from my catalog.xml, which defines composite objects:



In the same way that my gameObject parses an XML node and initializes itself, my compositeGameObject class does the same type of thing, but on a higher level (it basically passes each Item ID to another class which returns an instance of a gameObject). It also defines the hierarchy, as you can see some Items have child items.

My menu system works more or less the same way - I pass in an XML node defining the structure, which it parses and initializes:



Sorry it's not a detailed tutorial that you were probably hoping for, but hopefully this gives you the idea. If you've got any further questions, feel free to post them.

I'm glad i'm not a spambot also . Would be sad isn' it? Or very far in the future... "I 4M NOT 4 SP4M BOT, I H4V3 F33LINGS".
Well, actually asking for a complete tutorial was kind of rough from me, specially in a forum thread...

I find it amazing. You define objects, and composites of objects, then the menu the unselected/selected colors, positions, texts, even the assets paths...

I have to do some learning/research!

Do you have some kind of editor for generating the xml? or do you do it directly in the files.

So anyways, thanks for your reply!

It's actually not that hard. I find it's easiest if you get it up and running first without the XML (ie: hardcode the default variable values), then it's just a matter of writing a few methods to parse the xml and replace those default values with the ones from the XML file. And the C# methods for working with XML makes it quite easy:



To start with I've just been building the XML files by hand using notepad, but generally once it becomes too unwieldy or time consuming it's time to make a tool. That was the approach I ended up taking with Wytches Brew - I built a WYSIWYG editor to produce the game's XML files which ended up saving a lot of time and frustration.

It can be even easier if you hook things up with the content pipeline, I'll have to do a tutorial on that soon.