Official Amazing Gagets thread

Topics: User Forum
Mar 24, 2009 at 5:59 AM
Today i did a little cleaning up of my code and thought "i should send a copy to you guys so that you can test it". So here it is: http://cid-2708ee56cfe3b96b.skydrive.live.com/self.aspx/.Public/AmazingGadgetsDemo.zip
Controls are:
A/B/X: place rods/circles (depending on mode, sim must be stopped)
Y: Start/Stop Simulation
Right Shoulder Button: switch between placing circles and rods
Left shoulder button: switch between the move, delete, and place tools
Left stick: move cursor
Left stick button: reset cursor position
Right stick: move camera
Right stick button: reset camera
DPad up/down: zoom in/out
DPad left: track nearby body (may cross this feature off the list at some point)
Back: display debug info
Back + Start: exit game

Anyway, just try it and see if you can find any bugs or anything.
Mar 24, 2009 at 7:09 AM
Overall,
I thought it was great,
ran smooth and all the physics functioned correctly,
UI could be a little more appealing and obvious but it was good haha.

I did notice a few things.
When placing a rod between wheels it would snap to a node and i could not take it away,
it was impossible for me to connect the centers of two wheels(i was using the blue ones if thats relevant)

Also, i could not switch between rods and circles unless i was in move mode.
Just might be more convenient to be able to switch between them on the others as well.

Those are really the only things i had trouble with or any problems with,
aside from that i thought it was a great tech demo
Mar 24, 2009 at 7:16 AM
Edited Mar 24, 2009 at 7:30 AM
Yeap all the rod placing problems will be fixed soon (that is, as soon as i feel well enough to get working on it again). The UI is a temp placeholder thing till i can come up with something better. However; you should have been able to switch between rods and circles in any mode. Thanks for the feedback! Fun fact: the hardest code in fact to write was the actual logic for allowing placing of rods and circles! this ate a couple of weeks or so of time
Apr 13, 2009 at 7:58 AM
Edited Apr 13, 2009 at 8:06 AM
Sorry to pop this thread back up but i figured its better than making a new thread ^_^... Anyway, i've finally persuaded myself to get working more on my game, and i've gotten most of that feature rebuilding done. I hope to release another demo in the next couple of months. One other thing i worked on is the placing logic, the cursor now does not auto-snap with the rod so its easier to place connecting rods. I'd like your opinions though: Should i stick with the current art style (clean and simple) or should i do some custom artwork?
Apr 13, 2009 at 9:03 AM
Id say simple is better but detail isnt bad,
if that makes sense,
I would like to see some nice details on the terrain and objects,
but not to the point where the screen is so busy that you cant distinguish where the important objects are.
Apr 13, 2009 at 11:18 AM
Well it would be nothing too busy, just some nice abstract type look to it with maybe some clouds, rain, and lightning effects if i have the time to add it. The problem with this is it means i have to dump the current method of creating terrain (simple rectangles and circles, can be completely made via programming), and adopt some custom method of generating geometry. What do you think, is it a good idea?
Apr 13, 2009 at 4:09 PM
Dumping methods, no
Particle Engine, YES!
It would be quite a waste to destroy your current methods, why not attatch textures to the current terrain being generated.
Or expanding it to fill the terrain with tiles.
Apr 14, 2009 at 12:44 AM
Well i suppose i could rig up something so that my terrain takes custom textures. That actually might work! The problem is i have a fairly ugly (code wise) method of representing my terrain (i use 3 classes for *everything* in the game, terrain rods circles etc.) so it would be a bit tough to get that working right. Yeah im thking a particle generated clouds and some nice foggy rain effect with an occasional lightning bolt (dynamically generated of course) to spice things up (at least on the rainy levels).
Apr 14, 2009 at 2:44 AM
Edited Apr 14, 2009 at 2:45 AM
I would assume your aware of them
http://mpe.codeplex.com/
considering genbox is working on it,
but i definatley suggest it if you dont
The latest version's particle editor is quite incredible and streamlines alot of the process.
I really enjoy particle effects so that would be all welcome by me
Apr 14, 2009 at 3:53 AM
Yep ive seen that but it was a while ago (before the new release) and i couldnt get it working. Ill take another shot at it when im ready to start work on those (but i so like making things! i guess the old adage that programmers should learn to not reinvent the wheel constantly or something like that applies here).
Apr 15, 2009 at 1:53 PM
I am pleased to report progress on my reimplementation. When last we heard about my progress, i had implemented (read: wrote out some of the code for) the new class i needed, but hadn't actually made use of it yet. I now have reworked my game classes to use the new class, and i have it partially working! the things that are still broken are: Delete and possibly move tool, and the method i use for making pin joints is a bit screwed up. In case you're wondering why i'm reporting in such detail, this is one of the last major things i have to work out on the gameplay side (i might add a couple more types of object to interact with, but i think thats about it).
Apr 15, 2009 at 2:12 PM
Edited Apr 15, 2009 at 2:15 PM
I actually added deleting to my editor last night, what problems are you having?
I setup an ToolState called delete,
and under it i had

if(tool == toolstate.Delete)
{
    foreach(Structure a in Map.ToArray())
    {
    if(mouseState.LeftButton == ButtonState.Released && PrevmouseState.LeftButton == ButtonState.Pressed)
        if(a.geom.Collide(new Vector2(mouseState.X, mouseState.Y))
        {
            a.body.Dispose();
            a.geom.Dispose();
            Map.Remove(a);
        }
    }
}
The problem for me was removing it from the list,
so i just created an array which would be a "reference" to the list so i could modify the list under a foreach for my array.
Some people dislike this method I think but its easy quick and causes no problems for me.
I will look more into it but for now its perfect,
Ive drawn over a hundred bodies, static and non-static objects, and deleted just as many and no problems(except when the number of active bodies is high, my compute doesnt like work)
But of course this may be irrelevant as i dont even know your problem haha


edit:
I cant find the article I remember talking about this, i though tit was something Nick Gravelyn was saying,
if anyone know please tell me.
Apr 16, 2009 at 2:05 AM
I know that i can do deleting/moving, i just haven't gotten around to fixing the method i use yet. I wanna fix those screwed up joints first.
Apr 21, 2009 at 8:14 AM
I have a couple rules that must be satisfied in order to place a gadget on the field:
1. the gadget must lay completely inside a single special area (my area code has a Contains method that checks to see if the requested item is contained within it)
2. the gadget must not be placed on top of an existing gadget (something to do a simple check for 2 geoms colliding without actually running the sim would be useful here)
Any ideas? i can provide a fair bit of detail about my code structure if necessary.
Apr 21, 2009 at 7:59 PM
Edited Apr 21, 2009 at 7:59 PM
you could do something where it creates the geometry and body but collision response is desabled,
you could do it where if the current isdown and previous is up to make the part,
then on release see if it collides with any other parts, if so delete the part, if not set it to a normal parts parameters
Seems like it would work well
Apr 21, 2009 at 10:06 PM
The problem is that requires me to step the engine forward and i really dont want to do that. I could rig something up maybe, but it would take a lot of work...
Apr 25, 2009 at 4:25 AM
Could you check out my editor and give me your opinions?
sorry i know this is your thread but I would like some feedback on the toolset and if i should pursue my style of editor versus a traditional tile engine.
What type of editor are you using?
Hopefully one similar to mine as I am not sure if i should be worried about going down the wrong path,
i really like te tools ive made and the way it works but if it turns out alot of people tried this before and it ended up kicking their ass, I would consider giving it up for a tile engine.
Apr 25, 2009 at 5:39 AM
Impressive... those polys tat you were making looked rather high quality... any plans to change that? BTW dont chnge to a tile engine the work you did there was amazing! I havent actually got around to an editor yet (still working on finishing gameplay implementation and art and gotta restructure the way i have some of my game objects made), but i plan to write an external winforms xna hybrid editor. That way i can have any tool i need for making levels.
Apr 25, 2009 at 6:58 AM
Thanks!
I was also thinking about winforms a while back, after seeing what MPE did with their particle editor i was very interested.
But i went ahead with the classic farseerian screen management techniques just because winforms were bothering me.
I saw many different techniques for them and everyone says the other person is wrong,
and me being me I got the hell outta there.
There are many things in winforms i wouldve loved for controlling paramaters, but i kinda like the challenge of making them in standard form
and im a bit to lazy to break into winforms haha, if you find a good tutorial that you find works pass it on over.
I have trouble making final decisions on my own so if youve got an opinion please share(im not saying im the person who believes whatever he is told, i just cant decide until i get another persons perspective).
And by change the high quality you meen? If you are reffering to the level of subdivision i went to then yeah thats a sort of overload for the polygon tools, haha XD
I was using subdivide(2) for the super fine polygons and subdivide(5) for the normal ones.
I do not plan on using the fine point except for detailed sprites.
Right now im wrestling with getting my damn xml file(.sav?) into my game, it cannot autodetect the importer.
I havent done any deserializing in a long time so this is gonna be the real challenge.
Apr 25, 2009 at 7:46 PM
Edited Apr 25, 2009 at 8:01 PM
Actually, i think there's a tutorial on Codeproject for using Winforms with XNA. I'll also see if i can find you a basic tutorial on using plain winforms...Edit: heres the link for that xna winforms tutorial, ignore the stuff about getting xna to work with VS2008 (we have XNA 3 yay) http://www.codeproject.com/KB/game/XNA_And_Beyond.aspx Edit 2: you can find windows froms tutorials here: http://windowsclient.net/getstarted/
Coordinator
Apr 25, 2009 at 10:00 PM
@tlegion: The Mercury Particle Editor does indeed use winforms in the editor. It's actually a simple XNA game windows where a winform usercontrol is added. It has some problems, but it's easier to do it that way, instead of using a third-party GUI library.

I also used to use this technique in my Polygon Mapper. But as mentioned, it has some problems. First of all, the mouse-clicks is registered in the whole window. If you have a controlpanel like the MPE particle editor, you have to check the location of the mouse on each click.
You also have no way of checking if the window is the currently active window. When you close a dialog box, you also click in the game.
I actually filed a bug on the last issue, I have no idea what happened to it. Someone from the XNA team told me that it would be fixed in future versions (the bug report was back in the XNA 1.0 days). Maybe I should take a closer look at the issue again.
Apr 26, 2009 at 12:36 AM
Yeah i noticed that problem, its not to annoying though,
I also saw how people were adding the xna window to the winforms window, that what caused alot of controversy,
some kid was saying that his ay was easy and not to bad,
then a bunch of official xa people like shawn seegraves(sp?) said that it was prone to error and lots of stuff.
I think i will stick with to this normal style for level editing, although it seems like winforms has better support for saving/loading,
how did you gp about doing your saving? I see you have a content pipeline so you can have the .em files in another project but how would i go about doing that? Do i need to make my own xml reader/writer or is there a better way? I shaved down my structs to use only ints strings and other basic stuff so is there an easier way?
Coordinator
Apr 26, 2009 at 12:43 AM
.net has its own XML serializer called XmlSerializer. It's not good at serializing matrices and list of vectors tho. This is where the XNA XML serializer comes in (called IntermediateSerializer). That is the one we use in the MPE particle editor project.

You just give it the object that needs to be serialized, and it will handle the writing to disk, formatting of XML etc.
You can put ignore attributes on properties and fields if you don't want to have them saved. You can also define the XML structure by using attributes, but it's not nessecary.
Apr 26, 2009 at 2:00 AM
Well I am not worried with the serialization of the item(although i looked at the xna serializaer and it will be helpful) im having trouble importing them in a seperate project, and using the content pipeline to detect how to import the xml should fix that problem.
Apr 26, 2009 at 3:06 AM
Edited Apr 26, 2009 at 3:08 AM
im using structs
http://www.ziggyware.com/codepaste.php?pasteID=1341
I have these structs in a pause menu which controls my level editor(_caller)
I use these so i can shave it down to basic stuff and use xmlserializer to save it to a storage device/storage container.
But when i try to load them in through the content pipeline in my other project it cant autodetect the importer. How would i solve this.
(sorry rogue i dont meen to flood your thread, and this isnt even related to farserr, sorry everyone!)
May 4, 2009 at 6:07 AM
(sorry i missed this...) Thats fine i dont mind. I do need a solution to my problem though. I'm thinkin that a static collision checking method would be nice!