tuxomania-devel — Development

[Tuxomania-devel] Moved to git

[Vincent P. <PVi...@ya...>]

Hi,

I've moved the tuxomania code from svn to git and removed the svn 
repository.

I find that git is more comfortable to use.

Cheers,

Vincent Petry

[Tuxomania-devel] Continuing?

[Vincent P. <PVi...@ya...>]

Hello guys,

Would you be interested to continue developing Tuxomania ?

Thanks,

Vincent

[Tuxomania-devel] Task list for tuxomania 0.0.4

[Vincent P. <PVi...@ya...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,


Let's use the mailing list from now on to discuss the development
topics.


In my last check in I integrated the World class with the Level
class. Now the Level instance returned by the level deserializer is
stored in an attribute of World. The tiles are copied to an internal
attribute to be used in run time. The original level state is kept
in the Level instance. Note that the game engine is supposed to
never modifying the data stored in the Level instance, and only work
with the World instance. (we might want to change these names later).

I also enabled the debugging flags, so now using Eclipse and gdb
will work.


Here is our task list:

A) Ouyang will be working on the sound part, which includes:

1) Find sounds online and make sure their license allow them to be
used in an open source game. One website for this is
http://www.freesound.org/. Some licenses require us to mention the
author's name, which is not an issue. Usually the license will be
Creative Commons.

2) Add SDL_mixer to the project and find out how to integrate it
with our current code. One idea was to create a sound queue and let
the controllers add a sound event to the queue. Then after the view
has been rendered, let another class (to be created) loop over the
queue and play all the sounds.
The goal is to lay the groundwork so that it's easier to add sound
events later.

If you like you can start with the implementation first and use some
dummy sounds, we can always change them later to something better.



B) Heng will continue working on the level serialization part:

1) Integrate the color bars properties. Currently the level model
classes use an unconvenient format to store the color properties. If
possible, please add a helper method that will return instances of
the Color class directly, so that the World class can use them. We
can extend this later to cover more cases. I'd like to have the
original one to work as before (vertical bars with 2 colors).

2) Make the "Level" class self-contained. It means that the internal
objects, like the array of tiles, is created by the Level class
itself, not by an outside class. Remove the setTiles() method and
others that set complex objects. Only the deserializer is allowed to
directly or indirectly modify the Level object at creation time.
In a similar way, the destructor of the Level class must also
destroy the internal object structures, like the Tiles array.

3) Currently the WorldLoader will still create the levels in a
hard-coded way, but using the new Level class. Try to use the
serializer to save these levels as files and load them again. If it
works well, then we can remove the hard-coded data.


C) For my part I will do the following:

1) Tidy the implementation, especially the state classes. Also some
parts are a little bit messed up / mixes and I'd like to refactor them.

2) Create monsters
There will be three types of non-intelligent monsters: one always
going left-right, one up-down, and another one always following the
player.


For now, let's try to get this done until the end of May.



Please let me know if you have questions or problems.

Thanks,

Vincent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkvW3SwACgkQSSdxpfEEQEwdRwCfQaqnJJz2C6nacaneXv+bB8ii
UKkAn1LTanTqACHSqbOkCd5gFYn3rq34
=6Ef/
-----END PGP SIGNATURE-----

[Tuxomania-devel] Level data structure for the level editor

[Vincent P. <PVi...@ya...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heng, I have been thinking about the data structure for the level
editor. I think that if you are going to display the level, the data
structure using the x and y coordinates is not very good. I am
talking about this:
	struct Tile {
		int x, y;
		int platform,
		int content,
		int sides
	}

It is better that you convert the serialized x/y coordinates to a
map (array of array of Tile), like this:

	struct Tile {		
		int platform,
		int content,
		int sides
	}

A map is much easier and faster to draw to the screen. Also, when
drawing the tiles, the order is important: the tiles on the
top-right must be displayed before the tiles in the bottom-left.

So in the Level class you will have this:
	Tile** map;


What do you think ?

Thanks,

Vincent Petry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkuU+8oACgkQSSdxpfEEQExM6gCeMoYZnjRlhV1iA3XsWA9q4MKM
ingAn1N2BQO4QsxFyOAmfM2PUrHX1qFr
=INl1
-----END PGP SIGNATURE-----

[Tuxomania-devel] Bug tracker for tuxomania

[Vincent P. <PVi...@ya...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,

I have set up the bug tracker for tuxomania and also assigned some
bugs to you (Jun and Heng). You might want to use the tracker's
"Monitor" feature, so you will receive emails when there is a change.

For now, we can use the feature requests tracker to track the
features. Later I will create a wiki with a more specific road map.

As soon as we have a working game with editor, and also some levels,
we can release it as 0.1 alpha (no more pre-alpha).

Thanks,

Vincent Petry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkuU+qcACgkQSSdxpfEEQEwLkQCcCz2SaQqRmjFYRYBwL3pWF4bs
pcoAnip2bwVOyUJBZjt7465d0uKOHLq5
=oTFO
-----END PGP SIGNATURE-----