Configuration editor
I have been working on the configuration editor for a few days. It's a simple little tool for creating levels/formations/enemies/bullet patterns/etc... With it I can quickly test various configurations for my game. For example I can write a bullet pattern and then see it running live with just a button push. I can also write a whole level, and then drag the timeline back and forth (while the game is running) to jump directly to a certain frame.
For now I don't want to create a too advanced editor. This is a simple one, but very usable. No more in and out from Visual Studio when I want to test some patterns or enemy paths. I'll give this one more work, but right now it serves it's purpose: to speed up level creation for the game.
For now I don't want to create a too advanced editor. This is a simple one, but very usable. No more in and out from Visual Studio when I want to test some patterns or enemy paths. I'll give this one more work, but right now it serves it's purpose: to speed up level creation for the game.
posted by Kobingo at
10:47 PM
10 Comments:
Finally! Someone who also uses XML to create ENTITIES ... I was starting to feel alone here ...
I like the way you define waypoints and behaviors. Clever ...
So, for what I can see the XML file is not preprocessed, isn't it? You just use the content pipeline to import your models and such and in turn you can dynamically build/call/change levels and behaviors by reading the XML on the fly ... I guess ... please correct me if I'm wrong ...
BTW, sorry for the late post but I've just happened to find your blog today.
By
Ultrahead, at 4:31 PM
XML is really nice for this kind of stuff.
No, the XML file is not preprocessed, it just goes through my own "parser" (not XML parser of course) and creating the objects and adding behaviors as needed.
I think it's just fun someone leaves a comment :-)
By
Kobingo, at 8:27 AM
"I think it's just fun someone leaves a comment :-) "
Plus it keeps the blogger's motivation high. I deem it kinda rude when no-one posts a comment on something that brings quality/support to the XNA community ...
... it's like a "cycle of virtue", for this case, the more feedback/support the more synergy/benefits in the end ...
BTW, did the following link help (http://amapplease.blogspot.com/2007/01/oob-intersection-test-using-xna-as-we.html)?
By
Ultrahead, at 12:54 PM
I left the whole idea of using AABB/OOBB and instead ended up using just a sphere for intersection tests, it works very well. Thanks anyway!
By
Kobingo, at 3:30 PM
ok, ... :)
By
Ultrahead, at 4:36 PM
"... No more in and out from Visual Studio when I want to test some patterns or enemy paths. ..."
So you're saying that you just build the assembly, open your editor change the timeline and by pressing the green play icon you: (a) generate the level for a particular chosen timeframe, and (b) execute the assembly (which will dynamically read that file and build the level on the fly), right?
Or you can change the level while the game is playing without the need of re-executing it?
By
Ultrahead, at 11:03 PM
Yes, when I click the green play button the game will execute that stage (level) at the current timeline frame. I can then drag the timeline back and forth to jump directly to a specific frame. I only have to build the assembly once.
By
Kobingo, at 3:31 PM
"I can then drag the timeline back and forth to jump directly to a specific frame."
With or without re-execution? If without, how does the game knows "on-the-fly" at playtime that you'd changed the time in the external editor?
By
Ultrahead, at 6:24 PM
Without re-execution. My editor runs within the game and can change properties/behavior while the game runs.
By
Kobingo, at 2:55 PM
would it be possible to get my hands on this? I've been messing around with the graphical design for the game, and feel it has a lot more capacity then it has built in. email me @ applesmycat at aol.
By
Anonymous, at 10:31 PM
Post a Comment
<< Home