WCR Release v0.0 Main Menu

The first installment of a series of 11 releases, the first being the main menu.
I had to add a new shape to arclib, the drawRoundEdgeRect shape, and then I created a new GUI theme "WarCoders" and I created the mainscreen.xml for the GUI.

Below is a clickable thumb:



I decided to steal the mars rover shot for my main screen because it looks nice, its a robot on a foreign planet, and that planet is Mars. I made the title text with cooltext.com as well, and am using a dungeon.ttf for my main screen font.

There is an options button, but currently doesn't work. I'm hoping I'll have time to get to it at the end, but it is not really too important.

While I won't host on dsource as its own project, it will be hosted here for backup: http://svn.dsource.org/projects/arclib/dev/warcoders/trunk/game . This folder has all the dll's and exe required for windows users, btw, so if you want to svn up along, feel free. *nix users, you are good at compiling ;)

I'm writing the code from scratch but taking inspiration from my TankWars setup, which seperates game media and game source, and then moves the exe to the game media folder after a successful build.

WarCoders Ressurection

So now that ArcLib is basically "finished," I wanted to put down game programming for a while, however my ancient past has come back to haunt me, so I must complete the cycle, and build the game that originally started me off on ArcLib. When the game is complete, I will simply just maintain ArcLib / the game, probably stopping development, or just do tiny incremented dev here and there.

The game will be named WarCoders Ressurection, and each week until Aug 15th (the completion date) it will have a release. The whole development is completely planned out. I will not create a dsource project until the 1.0 version is done. There will be a total of 11 releases + accompanying screen, which I will just post on my blog here, and save 1.0 release for the D newsgroup. The project will use minid as its scripting language.

With that, stay tuned...

Light package

The light Arclib extension is more or less done... the beauty of extensions is that they are a lot quicker to make and maintain instead of trying to put it all into one giant library, and then can be dropped out for better ones in the future if necessary.

Just so folks know, this code was mostly written by Christian Kamm. Here's a screen:

Maintainance fix ...

ArcLib GUI now works well. The light demo doesn't crash, and I will soon make a lighting extension.

Current arclib + extension features...
1. 2d physics
2. gui
3. freetype font rendering
4. openal sound/music
5. particle fx
6. sprite

To be soon done
1. 2d lighting

"WarBots" blockers are now...

1. Simplified scene graph
2. In-game text editing component

Networking would be nice too, but not necessary.

ArcLib to begin maintenance phase

Arc has been an interesting spare time project. Arc began in 2005 as a library that needed to be developed in order to complete my Warbots game project. After 3 years, it slowly took on a life of its own as I forgot about Warbots. I wrote code that would be useful to me and assimilated it into one library.

I have learned much about the D language, binding, and writing 2D game style code. I’ve had fun, but time doesn't permit anymore to actively develop 2D game code.

ArcLib will now move into maintenance phase. For this maintenance phase I have split ArcLib up into an ArcLib core and several extensions.

Current Arc Project Structure
1. Arc Core
2. Arc Extensions
- Blaze 2d physics
- Freetype font rendering
- GUI (currently crashes, however, due to assocArray.keys call, but tech has worked well in past)
- OpenAL sound
- Particle system
- Scenegraph
- Sprite

These extensions will all depend on the ArcLib core, but compatibility between extensions will not be guaranteed.

From now on, ArcLib will be on a yearly maintenance cycle.

ArcLib and all its extensions should soon be installable via DSSS as well.

Only example code will be kept up-to-date, tutorials and the like will not be.

ArcLib all-in-one vs. modular design

Forum thread: http://www.dsource.org/forums/viewtopic.php?t=3861


Here's an idea that I'd been thinking about in my head a while, about
which design route I should be taking ArcLib in.

1. Modular design
- Arc Core Library
- Arc Scenegraph
- Arc Particle
- ArcLib compatible Blaze
- etc.

2. All-in-one design
- The way it is now. Everything is well mixed together.

I'd rather stick with one design or the other, to have a strong design
philosophy behind the library, at least.

I've been leaning towards the all-in-one design, which is what ArcLib
is currently, for ease of use. However, to keep up with this design, I
/will/ need to integrate Blaze directly into the ArcLib code base. It
also puts the pressure on me to maintain / develop more code, and
slows down the release cycles.

Recently I've been thinking of a modular approach as well... this
approach works well for the SDL library (SDL_image, SDL_ttf, etc.) It
would allow game programmers to 'pick and choose' which components of
ArcLib they would want to use, and the core of ArcLib would become
really well polished. DSSS would remove the pain of installing all the
libraries separately. This way, different members of a future 'arclib
community' can make arclib compatible extension libs and people can
choose to use them or not, and my 'GUI' implementation would have the
possibility of 'disappearing' if a better one from the community
emerged, or certain sections of arclib can be redesigned without
really much of a problem.

Anyways, I've been struggling with these ideas for a while and kind of
want to know what others think about them.