Using Snowberry for another engine

dosheadoshea
edited 2013 May 14 in General
Hi all,

I would like to provide a launcher with the game engine I'm working on - particularly if that is an easy thing to do - and having played a few games using the Doomsday engine, I thought of Snowberry and found that version 1.2 was fairly easy to customise to do many of the things I wanted.

There are a few very minor things I'd need to change to support the engine I'm working with - e.g. I think Snowberry always passes the "-userdir" command-line option, but I don't want that, and I think I'd like to change the way it passes parameters to the engine, although I might actually be better off changing how the engine accepts parameters. Also, I gather that I have to use the string "configure doomsday" to set the path to my engine's executable, it would be slightly nicer if it was "configure engine" although obviously it works fine as it is; so far that's the only place I think I've seen references to the engine's name that I can't change in configuration/language files, and it's not shown to the user, so that's pretty good!

I was going to suggest that I make some changes to make Snowberry more generic, so perhaps other engines could use it too, and then contribute those changes back. However, I just noticed that Snowberry is being phased out of Doomsday, so I assume that the Doomsday maintainers won't actually be maintaining Snowberry any more?

I'm guessing then that I may as well just fork it on github with no plan to ever have the changes pulled back into Doomsday? I'm also guessing that the changes in the Snowberry code between the latest stable release branch and master would be pretty minimal, if any, so master would be fairly stable too? Ignoring configuration files, of course, where I assume lots of options have now been deleted. Advice on where I should fork from would be appreciated!

Incidentally, I had a look around for similar launchers that could be customised so much via configuration files and couldn't find any. If there are in fact any competitors to Snowberry, pointers would be appreciated.

Thanks in advance!

P.S. The Doomsday Engine and Snowberry are both awesome, thanks!

Comments

  • skyjakeskyjake
    doshea wrote:
    There are a few very minor things I'd need to change to support the engine I'm working with - e.g. I think Snowberry always passes the "-userdir" command-line option
    I am the primary author of Snowberry, so I can provide some guidance here.

    Snowberry has a flexible plugin-based architecture so it should be quite easy to make it do whatever you need. For instance, the "-userdir" option you mention is set in plugins/launcher.py. You could for instance replace the launcher plugin with your own that generates the options in a manner appropriate for your engine.

    From a technology point of view, though, Snowberry is based on wxPython (wxWidgets), which is not the best portable GUI toolkit out there. This may prove to be a limitation for future work.
    Also, I gather that I have to use the string "configure doomsday" to set the path to my engine's executable, it would be slightly nicer if it was "configure engine" although obviously it works fine as it is
    The setting that defines the name of the engine binary is also determined in the launcher plugin: 
    st.getSystemString('doomsday-base')
    The "system strings" to which the method refers to are the ones defined using the "configure" blocks in the .conf files, e.g.: 
    configure doomsday (
  binary: ..\Bin\Doomsday.exe
  base: ..
)
    The name of the block (doomsday) is simply concatenated with the contained keys (binary, base) to produce the full string identifiers (doomsday-binary, doomsday-base).
    the only place I think I've seen references to the engine's name that I can't change in configuration/language files, and it's not shown to the user, so that's pretty good!
    All user-visible text comes from the language files (under the "lang" folder).
    I was going to suggest that I make some changes to make Snowberry more generic, so perhaps other engines could use it too, and then contribute those changes back. However, I just noticed that Snowberry is being phased out of Doomsday, so I assume that the Doomsday maintainers won't actually be maintaining Snowberry any more?
    Yeah it is being phased out. We are only making trivial bug fixes in Snowberry at this time.
    I'm guessing then that I may as well just fork it on github with no plan to ever have the changes pulled back into Doomsday? I'm also guessing that the changes in the Snowberry code between the latest stable release branch and master would be pretty minimal, if any, so master would be fairly stable too? Ignoring configuration files, of course, where I assume lots of options have now been deleted.
    The master has the latest version of Snowberry with all the bug fixes. That is what you should fork. We would be happy to pull any bug fixes or any useful improvements you might work on, providing they have a low risk of disrupting the stability of the codebase.

    Ultimately when Snowberry is dropped from the project, I will likely move it into a repository of its own on GitHub.
  • dosheadoshea
    skyjake wrote:
    I am the primary author of Snowberry, so I can provide some guidance here.
    Thanks!
    Snowberry has a flexible plugin-based architecture so it should be quite easy to make it do whatever you need. For instance, the "-userdir" option you mention is set in plugins/launcher.py. You could for instance replace the launcher plugin with your own that generates the options in a manner appropriate for your engine.
    Awesome! Sorry, I saw mention of plugins and forgot to investigate what you can do with them.
    From a technology point of view, though, Snowberry is based on wxPython (wxWidgets), which is not the best portable GUI toolkit out there. This may prove to be a limitation for future work.
    Oh, well I actually thought wxWidgets GUIs were normally ugly so I had assumed Snowberry was using Qt :) I'm on Windows, it looks pretty good to me! Are the limitations more in the area of customising the appearance? For example, I noticed appearance.conf has a "appearance tab-background" setting which accepts a colour, but I couldn't tell where it was used (and hadn't gotten around to looking in the code yet), I'm guessing that is the sort of thing where wxWidgets uses native widgets, and the native widgets don't actually let you change some colours, whereas Qt might give you greater control.
    The setting that defines the name of the engine binary is also determined in the launcher plugin:
    Very nice, thanks for all the info!
    The master has the latest version of Snowberry with all the bug fixes. That is what you should fork. We would be happy to pull any bug fixes or any useful improvements you might work on, providing they have a low risk of disrupting the stability of the codebase.

    Ultimately when Snowberry is dropped from the project, I will likely move it into a repository of its own on GitHub.
    Thanks, that sounds great!

    Out of interest, do you know if any other projects are using it already? I did come across one forum thread from someone asking about using it (which you responded in), but couldn't find the actual project they were referring to. It seems to me like there are probably lots of projects out there that would benefit from using it, and the fact that non-coders could do pretty much all the work makes it even better!
  • skyjakeskyjake
    doshea wrote:
    Are the limitations more in the area of customising the appearance?
    That is one of the limitations, yes. We also haven't been upgrading wxPython, so there might be unexpected regressions if the latest version(s) of wxPython are used, not to mention any issues from using 64-bit or Unicode.
    Out of interest, do you know if any other projects are using it already?
    I haven't heard of any...
Sign In or Register to comment.

© Vanilla Keystone Theme 2024