Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Pros/cons for writing tools as Eclipse plugins?  (Read 3510 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2006-06-27 21:28:01 »

I have a few tools I've created over time which run as separate LWJGL apps - the biggest two the level editor for Quix, and a 2d skeleton creator/animator. These are written to be as WYSIWYG as possible, which is why they use a LWJGL display and tend to share lots of the actual low-level classes and rendering with the games they were made for. Due to using a LWJGL diplay I chose to use Cas' Spaghetti gui system (the one from 'flux), which has since then been extended and tweeked in various ways. A nice side effect of this is that I can actually display sprites/textures in the GUI without any problems as they're using the same texture loader classes/backend. Images here and here to give you some idea of what the UI looks like.

Now spaghetti has served it's purpose admirably, but it's not exactly designed for this kind of work, and has numerous quirks when used in this way which make it less than ideal. Basically I'd like to switch over to a 'proper' GUI system. Which basically gives me the choice of Swing or SWT, and if I choose SWT the additional choice of whether to do a standalone tool or an Eclipse plugin.

Snags:
- I need a LWJGL display. I have no idea if Swing or SWT would be prefered for this.
- I'd like to share as much code as possible so that in-game doesn't end up rewriting the outgame stuff. Ideally they'd all become game-agnostic, which should be doable with some refactoring. If I have to package up my classes into an eclipse plugin that's going to make it harder to keep the two in sync.
- I'm still not sure of the advantages of having an eclipse plugin vs. a standalone app. I know Kev did a nice map editor as a plugin (which I'm going to try in just a bit) but it still seems like an odd idea to me.
- Swing gets a plus because I already know enough of it to get going without too much pain. On the other hand I'm not keen on working with Swing code (tree views, dnd and layout managers in particular I find rather frustrating) and it'd be good to try something else.

Anyone any suggestions/advice for what things to look into? Or any big advantages or disadvantages I've missed?

Cheers.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2006-06-27 21:36:32 »

Worth noting OpenGL is there as part of Eclipse 3.2:

http://archive.eclipse.org/eclipse/downloads/drops/S-3.2M3-200511021600/eclipse-news-M3.html

Also worth noting that SWT is signifcantly different to Swing in structure. Took me a little while to get my head round it. Its not a trvial swap over.

Kev

PS. The last time I tried the map editor it worked for me but I couldn't reproduce a bug someone was having.

EDIT: Forgot to say - having editors integrated into Eclipse is absolutely lovely tho Smiley Saves lots of times, feels very natural in work flow.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2006-06-27 21:47:52 »

Aye, I'd just noticed that SWT support, and an eclipse plugin does sound very tempting.

Other than the conceptual switch, did you find SWT to be as fast to develop with as Swing?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2006-06-27 22:14:26 »

Quote
Other than the conceptual switch, did you find SWT to be as fast to develop with as Swing?

I've worked with AWT/Swing everyday as long as I've worked - moving to SWT took a big of getting used to (its a bit like the Win32 MFC if that helps at all) but now its pretty close on par with Swing. Working as an Eclipse plug-in is whole other ball game though - I still find everyday something new in plug-in framework that screws me over (last time was caching of plugins outside of the plug-in mechanism). Of course once you've got your basic framework working in Eclipse its ok.

Its a bit step to take - but overall I think the reward is worth it.

Kev

Offline kaffiene
« Reply #4 - Posted 2006-06-27 23:49:58 »

In general, I think that plugins are more difficult to write than stand-alone tools and limit distribution.  I wouldn't bother unless you think the Eclipse community (and no-one else) needs your tool.

Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2006-06-28 00:49:36 »

Sorry, I thought we were talking about the bespoke tools of an Eclipse user here?

Kev

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2006-06-28 08:35:03 »

Probably. Er, almost certainly. In theory it'd be nice for users to use the level editor (and other developers to use the skeleton tool). But realistically no-one is likely to want to use it other than me.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline cylab

JGO Ninja


Medals: 55



« Reply #7 - Posted 2006-06-28 09:08:15 »

I think writing tools as plugins has some advantages for developers: you can tidy your workflow using the environment you are used to. That's the reason why I write NetBeans plugins. And since there are rich client platforms available for both NetBeans and Eclipse, you can always create a standalone app on customer demand.

And getting used to the plugin framework of the IDE you use everyday can't be bad...

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2006-06-28 09:31:07 »

I've been thinking about this myself a lot but haven't got the time to do it. All that XML that SPGL uses and the sprite packer etc etc. ... wouldn't it be nice if you could just drop pngs into a project and they got auto-packed and such?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2006-06-28 18:25:52 »

SpritePacker + friends can be a tad annoying, but I'm not sure how they would be changed to be easier/better. I mostly tend to stick it into an ant script and forget about it, but it does place awkward restrictions for doing runtime loading etc.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline hawkwind

Junior Devvie




Java games rock!


« Reply #10 - Posted 2006-06-28 23:34:15 »

If you want to use SWT or Java with a current release of Eclipse then grab the Visual Editor plugin (VE)  I am using the latest with Eclipse 3.2m5 I think.  It is relatively nice way to mess with layouts etc.  The main advantage of a plugin is the ease of development...I write them for a living and my life is so much easier now. 

If you are not aware of it you can export a Plugin (plugin set) as an executable RCP (Ricj Client) Product.  This provides a consise set of your/eclipse jars with startup code etc. that can be executed independently of eclipse.
Offline benjamin

Senior Newbie





« Reply #11 - Posted 2006-06-29 08:21:16 »

I do not know much about Eclipse and how it handles plug-ins. However, I always get a bit worried when someone is suggesting restricting the design/flow of an application because it needs to fit into a specific framework. I have often been in a situation where I had to be very ‘creative’ to actually solve a problem because of the restrictions that was defined by the underlying framework I was using. I presume that Eclipse has similar issues…

I only have experience using some of the plug-ins for e.g. uml modeling and I have never been fully satisfied with these modules. Cannot remember precise which one I tried but none of them actually provided a fully integrated solution I was happy with. I decided not to try using any UML plug-ins for my development for a long time. I believe this is a major issue for the Eclipse concept that it seems impossible to create a development tool that fully satisfies the need for a good UML modeling tool. This plug-in concept seems a bit too modular, which makes it impossible to fully integrate functionality provided by different modules. Please proof me wrong because having a framework like Eclipse would be very beneficial and save a lot of time. It just seems to me that if you want to make a solution where the usability is good and the functionality of the application is clear and easy to use you will have to make it from ‘scratch’.
Offline Herko_ter_Horst

Senior Newbie




Java games rock!


« Reply #12 - Posted 2006-06-29 11:30:19 »

I would recommend writing your tools as OSGi bundles instead of Eclipse plugins. Eclipse provides support for this. The advantage would be that you're not tied to Eclipse (and by extension SWT), although bundles automatically qualify as Eclipse plugins as well. Several implementations of the OSGi framework. Equinox (the foundation for Eclipse) is one, Apache Felix is another, Knopflerfish is a third. OSGi is an open standard maintained by the OSGi consortium. OSGi is an implementation of a Service Oriented Architecture within an application.

Of course if you're set on using the Eclipse RCP and/or SWT, going the plugin route would probably make more sense.
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2006-06-30 10:13:43 »

As I understand it there's no mandate to actually use SWT for plugins anyway. I'm pretty sure you can use Swing too and it integrates somehow.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!