FreeGameDev

Hello all,

Thanks to acme_pjz M&MS has been improved a lot.
There's a new level format, more blocks, an ImageManager and more.
Although we could continue adding new blocks and features I think it won't make M&MS any better.
It should stay a simple puzzle game, so instead of extending the game I think we should aim at improving/polishing the game.

Now my question is, what needs to be done?
Here's a list I made so far:

* Make new levels which contain the new blocks.
* Change graphics style?
* Make an icon.
* Get it packaged.

Not sure about the new graphics style, I like the current style but maybe a new graphics would look better?

Feel free to add suggestion or give feedback!

Well, what do you think about supporting two versions of graphics - classic (the existing one) and modern (new, improved) one. May be with some background, animations and so on.. Both acme_pjz and others will be satisfied

Hello KroArtem,

KroArtem {l Wrote}:Well, what do you think about supporting two versions of graphics - classic (the existing one) and modern (new, improved) one. May be with some background, animations and so on.. Both acme_pjz and others will be satisfied

That's a good idea, we could just make a theme setting in the options menu.

Agreed to improve graphics, waiting for someone to do it

And I think fix existing bug (for example jumping on a moving block) and improve in-game GUI and level editor GUI is needed ...

May be a short story can also be added, full of misteries, wrapped in enigma.. No, just a little simple story.

Having a theme manager is a good idea. (we have one in slime volley, but it's C and the code is commented in french :-/ )

So I think what the game need the most is levels, graphics and packaging.

levels, graphics and packaging

...and advertising too

Hello all,

MCMic {l Wrote}:Having a theme manager is a good idea. (we have one in slime volley, but it's C and the code is commented in french :-/ )

So I think what the game need the most is levels, graphics and packaging.

I don't think a theme manager is that difficult.
Since most loading of images is done through the ImageManager we could simply add a string which contains the name of the theme.
Then we can make a folder structure in the data folder like this:

{l Code}: {l Select All Code}

+ data
| - classic
|    | - gfx
|    | - sfx
| - modern
|    | - gfx
|    | - sfx
| - levels

For packaging we could use the openSUSE Build Service.

KroArtem {l Wrote}:

levels, graphics and packaging

...and advertising too

Let's not forget that!

A nice feature for a good theme manager is that if a file is missing from a theme, the one from the default theme is used.

Edward_Lii {l Wrote}:Since most loading of images is done through the ImageManager we could simply add a string which contains the name of the theme.

I think the theme description should go to a data file

MCMic {l Wrote}:A nice feature for a good theme manager is that if a file is missing from a theme, the one from the default theme is used.

Good idea. Would also be useful to output to a log file whenever a missing file has to be used from the default, that way people can tell how complete/incomplete their theme is.

-- Bodsda

Hello all,

MCMic {l Wrote}:A nice feature for a good theme manager is that if a file is missing from a theme, the one from the default theme is used.

Yeah that could be done,

acme_pjz {l Wrote}:I think the theme description should go to a data file

You're right, I think we should make a theme file which contains the following:

* The name of the theme
* The license of the theme
* The author of the theme
* Description of the theme

We then can place the theme file inside the theme folder like this:

{l Code}: {l Select All Code}

+ data
| - classic
|    | - gfx
|    | - sfx
|    | - theme.txt
| - modern
|    | - gfx
|    | - sfx
|    | - theme.txt
| - levels

I've got a question regarding packaging, if we want to package M&MS we should move the binary to /usr/bin folder and the data somewhere in /usr/share.
Should this be done using make or do we make a separate install.sh file?

You should do that with Cmake.
I did it for divide and succeed this week, it looks like this :

install(DIRECTORY ${PROJECT_BINARY_DIR}/levels DESTINATION share/divideandsucceed/)
install(FILES ${PROJECT_BINARY_DIR}/font.ttf DESTINATION share/divideandsucceed/)
install(TARGETS divideandsucceed RUNTIME DESTINATION bin)

Then the user do "cmake -DCMAKE_INSTALL_PREFIX=/usr . && make && make install" for instance.

I've got a question regarding packaging, if we want to package M&MS we should move the binary to /usr/bin folder and the data somewhere in /usr/share.
Should this be done using make or do we make a separate install.sh file?

I have no idea about this because I'm using Windows, when packaging in Windows simply zip executables and librarys and data files then it's OK ... Maybe we should define some macros which indicates the data directory and they will be configured during compiling ...

Hello all,

MCMic {l Wrote}:You should do that with Cmake.
I did it for divide and succeed this week, it looks like this :

install(DIRECTORY ${PROJECT_BINARY_DIR}/levels DESTINATION share/divideandsucceed/)
install(FILES ${PROJECT_BINARY_DIR}/font.ttf DESTINATION share/divideandsucceed/)
install(TARGETS divideandsucceed RUNTIME DESTINATION bin)

Then the user do "cmake -DCMAKE_INSTALL_PREFIX=/usr . && make && make install" for instance.

Thanks a lot!
One question though, this doesn't work under Windows but can it cause any problems?

acme_pjz {l Wrote}:I have no idea about this because I'm using Windows, when packaging in Windows simply zip executables and librarys and data files then it's OK ... Maybe we should define some macros which indicates the data directory and they will be configured during compiling ...

I don't think that's needed, as long as the executable is executed from within the data folder.

I'll try to make an RPM package ASAP.

Edward_Lii {l Wrote}:Hello all,

MCMic {l Wrote}:You should do that with Cmake.
I did it for divide and succeed this week, it looks like this :

install(DIRECTORY ${PROJECT_BINARY_DIR}/levels DESTINATION share/divideandsucceed/)
install(FILES ${PROJECT_BINARY_DIR}/font.ttf DESTINATION share/divideandsucceed/)
install(TARGETS divideandsucceed RUNTIME DESTINATION bin)

Then the user do "cmake -DCMAKE_INSTALL_PREFIX=/usr . && make && make install" for instance.

Thanks a lot!
One question though, this doesn't work under Windows but can it cause any problems?

I don't think so.
The install process for windows must be done separately.