level editor - best as a separate program?
Blitz3D Forums/Blitz3D Programming/level editor - best as a separate program?
| ||
| Hi all I'm planning a skirmish level editor for Tank Universal. This will allow users to create simple drag and drop skirmish maps from pre-fab tilesets. http://www.tankuniversal.com/forum/viewtopic.php?f=10&t=101 I'm thinking there'd be some advantages to setting it up as a separate exe to the game exe, but there might be some issues too. What's the current thinking on level editors - separate proggy or not? |
| ||
| ..i would go with separate proggy..and make game.exe to simply parse all data according to saved info came from an editor with all properities you can set/tweak in editor... |
| ||
| NA make game.exe to simply parse all data according to saved info came from an editor Yes - I'm leaning towards that as well - seems a bit more elegant rather than having everything lumped in with the game code and having to keep everything separate. Any issues with having two B3d progs running at the same time? I'd probably set the editor to windowed by default. |
| ||
| For in-house I would write a standalone editor; For a fairly simple release I would make the editor part of the main program; For a more complex release I would ship the standalone editor instead. Do players of simple shareware/indie games want to faff about with multiple exes? Probably not; Would players of complex games appreciate a separate editor? Probably. That's my rationale. |
| ||
| Sledge Would players of complex games appreciate a separate editor? Probably. That's my rationale. I see what you're saying. Although TU's an indie, it is aimed at the more 'hard core' gamer though, and they're likely to have used mods/custom maps before - so an external editor perhaps wouldn't be too daunting for them. Also, as the maps will be based on prefab tiles, I'm toying with the idea of generating an 'id string' for a map which could be copied/pasted/emailed. This could avoid having the user to find files and copy them into correct directories etc... |
| ||
| ..I see no problem with separated proggies...one is editor you have with builted in same structure as a 'game.exe', so practically you can preview game in editor, and then once completed, simply save out file what will be parsed when next time game runs (game.exe) .. and share that file what shouldnt be that big for network share.. |
| ||
| Any issues with having two B3d progs running at the same time? Well they will both try to chew up 100% CPU time. You'll either need to find a way to force them to run on different cores ( not sure if this is possible, and even then it will only work on multi-core CPU's ) or you'll need to at least give some time back to the system in both programs when they're not active to allow them to play nice. |
| ||
| Gabriel Well they will both try to chew up 100% CPU time Unfortunate feature of B3d progs eh? I haven't tested, but the Delay(XX) command might be a solution here? With some sort of detection for when the editor has focus? Or is it possible to open another blitz prog by commandline, shut down the currently running prog and then reopen it when exiting the 2nd prog? What would you recommend? |
| ||
| I used to have two instances of Kick Shot Pool on the same computer playing each other through the networked game just using Delay. Kick Shot Pool had some pretty unoptimized maths routines, so if it worked ok for that, I would think the chances were good for it working for TU and the editor. It's been a (long) while since I used Blitz3D. Does it have functions to detect when it loses and gains focus? If so, I think those in conjunction with a Delay sounds promising. |
| ||
| Gabriel As you suggest, having the two progs running might simply not be an issue, particularly if the editor doesn't take many cycles - I'll see what happens. I don't believe B3d doesn't has any native commands for checking windows focus, but there might be some external lib options. I'll check it out. Thanks for the suggestions. |
| ||
| ..Madjack..why you have to run 2 EXE's at same time, if you can do preview within Editor? |
| ||
| NA That would just be a static preview - just to see how everything looks in place. The editor would hand over to the game to run the level proper. I think there'd be a few advantages to this - being able to test/distribute the editor independantly of the game.exe being one. |
| ||
| I got a general question about game editors and general game info. What format do you guys use to save this (Example: Animations, Mount-points, Item types, Abilities)? Textfiles? I am working on a project where I've been modelling an SQLite database, and then i got lots of data-objects (Types) and Crud-code to manage the I/O from the DB. Is this approach overkill for an RPG-type game? |
| ||
| Me myself is coding tiberion client as editor. to place rats and code NPC.. its fun to Spawn theses realtime. |
| ||
| If the level editor is a windowed app then you could use the new new windowed graphics modes 6 and 7 in the 1.99 update. The application auto-suspends when it loses activation. You can then have an option to launch the game and test the level. |
| ||
| In regards to cpu usage, what I usually do with Blitz3D event based apps, is have a G_do_update global that I set to true if an action has occurred that requires a graphics redraw; and false otherwise. If a graphics redraw is not required, then I do a Delay( 20 ) instead. Twenty milliseconds seems to be the standard threading timeslice. This results in the Task Manager showing 0% usage of the cpu when the app is idle, which allows it to play nice with other programs. |
| ||
| Ricky/Bill Excellent! Thanks for the tech tips - I'll be using both those no doubt. Mahan Not suggesting you're thread hijacking, but you may get better result if you ask your question in a new thread. |
   |