Vagabond
New Member
- Joined
- Oct 5, 2007
- Messages
- 242
- Reaction score
- 0
The working title is "NOTClient", which can either stand for "New/'Nother OpenTibia Client" or "Nate's OT Client" based on whether or not I get input from other developers.
I'm currently in the designing phases and only have a few hundred lines written, most of it design and some of it implementation. None of it is really specific to Tibia right now.
The client is being written with full consideration to my years of experience with OTServ as both a player and a developer, my 2+ years of experience in developing YATC, and several years of unorthodox but intensive programming experience.
The goals right now are as follows:
1) By the New Year, to have a playable Tibia client.
2) By this time next year, to have a Tibia client that integrates tightly with OTServ.
3) By the next New Year, to have both enough public-use sprites and structured data files AND enough progress on the client to support a functional Tibia server (but not necessarily an exact clone) using nothing from CipSoft except for the concept of gameplay.
I realize these goals are pretty extreme and will require a ton of dedication on my part, as well as assistance from others. I'm willing to bust my ass if enough other people are.
Multiple protocol support is planned, through branching of the project. The reason this was chosen was because it's simply the most flexible method that can take all changes between different protocol versions into account, without encountering a problem commonly referred to as "DLL hell" or placing most of the game logic in scripts or building huge executables. The basic idea right now is that each protocol will have its own executable, and the core NOTClient program will be a launcher that simply choses which version to load based on user input, and can seamlessly (or as seamlessly as possible) change between them.
The project is hosted through mercurial on sourceforge.net: https://sourceforge.net/projects/notclient/
Project is separated from OpenTibia to take advantage of mercurial's neat branching features, which will reduce development load for the chosen method of multi-protocol support. This has an extra benefit of me being the only person needing to approve adding a new developer, so we can take on many developers without crowding the OpenTibia project with developers.
I am looking for other developers willing to assist. A large amount of experience in C++ would be highly recommended at this point, as a novice would not be of much use right now. Additionally, a Mac porter/tester would also be quite nice.
I'm currently in the designing phases and only have a few hundred lines written, most of it design and some of it implementation. None of it is really specific to Tibia right now.
The client is being written with full consideration to my years of experience with OTServ as both a player and a developer, my 2+ years of experience in developing YATC, and several years of unorthodox but intensive programming experience.
The goals right now are as follows:
1) By the New Year, to have a playable Tibia client.
2) By this time next year, to have a Tibia client that integrates tightly with OTServ.
3) By the next New Year, to have both enough public-use sprites and structured data files AND enough progress on the client to support a functional Tibia server (but not necessarily an exact clone) using nothing from CipSoft except for the concept of gameplay.
I realize these goals are pretty extreme and will require a ton of dedication on my part, as well as assistance from others. I'm willing to bust my ass if enough other people are.
Multiple protocol support is planned, through branching of the project. The reason this was chosen was because it's simply the most flexible method that can take all changes between different protocol versions into account, without encountering a problem commonly referred to as "DLL hell" or placing most of the game logic in scripts or building huge executables. The basic idea right now is that each protocol will have its own executable, and the core NOTClient program will be a launcher that simply choses which version to load based on user input, and can seamlessly (or as seamlessly as possible) change between them.
The project is hosted through mercurial on sourceforge.net: https://sourceforge.net/projects/notclient/
Project is separated from OpenTibia to take advantage of mercurial's neat branching features, which will reduce development load for the chosen method of multi-protocol support. This has an extra benefit of me being the only person needing to approve adding a new developer, so we can take on many developers without crowding the OpenTibia project with developers.
I am looking for other developers willing to assist. A large amount of experience in C++ would be highly recommended at this point, as a novice would not be of much use right now. Additionally, a Mac porter/tester would also be quite nice.