View previous topic :: View next topic |
Author |
Message |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 03, 2006 10:48 pm Post subject: Arc Progress, Development Style, and Contributor Info. |
|
|
Arc Progress
---------------
Testing: Creation of test applications, manually check to see if they work
Documentation: Consists of A) CandyDoc and B) Write-Up examples
Main Arc 'packages'
---------------------------------------------
ArcBasic
* Purpose: Very basic necessities that a critical mass of modules need access to. The only dependency any module should need.
* Completeness: Undefined
* Testing: None
* Documentation: None
* File path: arc.basic.*
ArcTemplates
* Purpose: Templates useful for game programming
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.templates.*
ArcIO
* Purpose: Anything dealing with input and output
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.io.*
ArcDraw
* Purpose: Drawing stuff to the screen
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.draw.*
ArcGUI
* Purpose: A GUI System
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.gui.*
ArcNet
* Purpose: A Networking System
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.net.*
ArcPhysics
* Purpose: A physics system planned on using ODE 2D Joint implementation
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.physics.*
ArcLight
* Purpose: An advanced 2D lighting system
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.light.*
ArcScript
* Purpose: An adopted scripting language (probably minid)
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.script.*
ArcFileSystem
* Purpose: A file-system used for easily accessing zips and other compressed files
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.filesystem.*
ArcMath
* Purpose: useful 2D math routines not covered in std.math
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.math.*
------------------------------------
Arc Add-on modules, more game specific additions. Add-ons usually need access to many modules at once or they are also unnecessary extras.
-------------------------------------
ArcSprite
* Purpose: A Multi-Animation sprite with sound effects
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.addon.sprite.*
ArcTileMap
* Purpose: A tile map engine
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.addon.tilemap.*
ArcParticle
* Purpose: A particle engine
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.addon.particle.*
ArcMemory
* Purpose: Memory tricks
* Completeness: 0?
* Testing: None
* Documentation: None
* File path: arc.addon.memory.*
Arc Development Style
---------------------------
This library based upon the hard work of myself and many, many others who I have built upon. Special thanks goes to Walter Bright (D language), Aldacron (Derelict), JoeCoder (Yage Sources/OpenAL), phr00t + co (Idea suggestion, beta testing), Sam Latinga (SDL), and many others I have forgot (but send me a mail if I did). The goal of this library is to provide a set of pluck-able major 2D game components, all of which follow a standard API. The goal is to allow developers to take what they want without carrying the whole library with them.
This project originally started out in a monolithic library style, but I then realized that the larger a library is, the less specialized and useful it will become to others. The library has been, therefore, split into smaller independent sub-modules which can be cherry picked for use inside of games. Splitting into a series of smaller sub-modules also means that each sub-module will be better designed, documented, and tested.
The goal of these modules is to either wrap or create cross platform APIs with one common API implementation to common existing cross platform APIs, or to create new APIs entirely from scratch. The ultimate goal is simplification while increasing power of the library.
Contributor Info.
-------------------
If you would like to help this library move along further, look at the above list of arc modules/packages that need to be completed and what needs to happen before they are completed. The modular structure of Arc should allow multiple developers to work on different parts of the library without stepping on each others toes.
If you think you have some code that would be useful for 2D game programming and you don't mind it being under the zlib/png license, just mail it to me or post it here, and I will most likely include it.
Thanks,
~ Clay
clayasaurus 'at' gmail 'dot' com
Last edited by clayasaurus on Mon Oct 09, 2006 4:47 pm; edited 1 time in total |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Mon Oct 09, 2006 4:47 pm Post subject: |
|
|
I just realized splitting Arc into independent modules is a big mistake because if I have everything seperate it will cause massive duplicaiton of code. So... this thread sinks and I'll raise the other one up |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Mon Oct 09, 2006 6:03 pm Post subject: |
|
|
clayasaurus wrote: | I just realized splitting Arc into independent modules is a big mistake because if I have everything seperate it will cause massive duplicaiton of code. So... this thread sinks and I'll raise the other one up |
I thought it was an excellent idea / design / refactoring? Each module just cannot be totally independant, but what you can do is minimize and specify the exact dependencies. This way you can control much more easily when you modify some code what other modules are affected by it, so it will make it easier to change or completly swap out parts, reducing complexity.
Code should have a hierarchy, you could make three layers for example something like how you specified it I thought was good:
1. arc.core <- all the boilerplate code
2. arc.gfx, arc.physics, etc. <- the basics
3. arc.sprite, arc.gui, etc. <- higher level code
Then 3 should only depend on code from 2 and 2 on code from layer 1. For each module, specify what code it directly depends on, if you don't have any public imports this will simply be a list of your imports. When you find code in layer 1 that needs layer 2 or 3, you know you've messed up and need to fix it (as rule of the thumb). When you draw the dependencies as a graph, it should have the structure of a tree.
More (not totally) independant modules means finding and clarifying the exact coupling needed (so as to avoid copy-pasting as much as possible), which I think will end up in less duplication of code.
Can I recommend this chapter from an online book, it really helped me alot you may find it interesting as it deals with this issue: http://www.relisoft.com/book/proj/1software.html |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 10, 2006 7:52 am Post subject: |
|
|
My other problem is that everything is so independent on each other that everything would have to become boilerplate code which ruins the whole point of splitting things up in the first place.
I'm going to take a much gentler approach to developing arc, maybe with the above layout close to my ultimate goal.
I also want to work closer to the freeuniverse team, because their game provides an excellent test case and they are the only ones using it so I might as well have it cater to them for a while. Plus they can help me with Arc and I can help them with FreeUniverse, I get bored with making a little library after a while. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|