Taking a break...

Graduating Spring 09, looking for jobs, need to improve my C++ skills, might make a C++ game w/ C++, Lua, Box2D, Fmod, OpenGL, may look for a job as a gameplay programmer, or look for a job in a different industry and try to get into gamedev on the side.

Therefore, I'm taking a break from D for a while, and looking to start a career. I'm going to keep a blog on my game development on a different blog, Rise of Super Penguin . This game will hopefully help me crack into game development as a game play programmer.

DSSS update...

DSSS has been updated so all the ArcLib extensions, including freetype, should work with the net intall.

(Offtopic) Blender Game Engine

This Blender Game Engine looks quite promising.
I've been wanting to learn 3D modeling and such, and it looks like Blender is not only a full fledged modeling program, but it also has a fully featured game engine.

Learning this would allow me to learn modeling, animation, do scripting in python, and have blender do the work using Ogre and Bullet in the background.

/me needs to learn this.

arc_extname trunk change

arc_extname changes are now in the trunk. This fixes the problem of arclib extensions polluting the library name space in general.

particle is now arc_particle
light is now arc_light
freetype is now arc_freetype
etc.

Free Mind - My Favorite Game Design Tool

http://freemind.sourceforge.net/wiki/index.php/Main_Page

Let's you map out all the ideas for your game on a tree, and export it to cool formats. A great tool for organizing ideas. I use it for trying to think of every possible feature to be implemented into my game, the levels, the setup of a level, the menu, etc. Once the mind map is complete and very detailed, it gives a really good solid foundation to start coding with. It also is a good tool to show how complex a seemingly "simple" idea is, and the feasibility of such an idea.

If you can't mind map it, you can't code it.

I'd suppose this would work well for any large software projects.

ArcLib status + The Problem with D

Just a short time to post, spending most of my time finishing up college, looking for jobs, thinking about the possibility of graduate school.

ArcLib status: ArcLib development should be considered "on hold" until about May 8th, 2009. I'm leaning towards doing some more work on ArcLib after that. It is already on solid ground and the D community is fairly awesome.

The Problem with D: From a language standpoint, there is one major problem with D, and that problem is that D is not C. I have a feeling that most serious system level projects (Operating Systems, Game Engines) are done in C, because...

1. C is everywhere, there is a compiler for every system
2. Everyone knows C, it is tried and true
3. C is a better language to program in than C++ for large scale projects. The C++ STL is not up to par, and C++ adds more complexity than useful abstraction. Game companies that do use C++, like EA, implement their own version of STL. I'm guessing they also use a restricted subset of C++ features.

I think what is holding D back is
1. You can not find a D compiler for every system
2. Not many people know how to program D
3. There is too much legacy code written in C++ / C

Problem 2 and 3 are problems due to marketing and language maturity. Also, as more code gets written in D, even more code gets written C++, so the amount of D code will probably never be able to eclipse C++ / C code.

Problem 1 can be addressed, but needs to be addressed via the community like what is happening with the LLVMDC project.

So, D will probably stay as being a very niche language in the ecosystem of computer language's, catering to those few independent minded folks who do not need to program for the Ps3/X-box, etc., and who actually value the beauty of a language over it's acceptance in the world, and who don't mind having to re-invent the wheel. These "problems" are actually acting like a filter, and so the D community itself is very cohesive.

WC Release v.2 - Lights

I've integrated lights into the tile map, and I've allowed the editor/game to place, save, and load lights.




The yellow dots and the red polygons are there only for debugging purposes only, and I will soon get rid of those as I smooth out the system.

I also ditched the scenegraph system, as it was too complicated for what I wanted to do, and instead resurrected my old Camera class which allows simple transformation of the screen to give a scrolling effect. The new camera extension can be found in my ArcLib svn.

Lights are a really nice way of bringing the detail out in the scene, and prevents it from looking boring and repetitive. Thanks Christian K and OrangyTang!

So, for the lights, it seems like I will be using those for a 'Fog of War' type system for the bots. The bots will have a limited vision range, which the programmer can see by the current area it illuminates.

Now that lights are in, the next big step will be to integrate the lights and tilemap with the excellent Blaze physics system.

Until then...

Game Delay...

The game is going to be delayed a little bit. I don't have anything to show in this post, but the next post should be amazing... when it's done.

WCR Release .1 - Tilemap + Tilemap Editor

Tilemap and tilemap editor is complete. Can edit tiles, save to XML, and load tiles again. Most of the code taken from the Tankwars project.



Quickpost this image to Myspace, Digg, Facebook, and others!

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.

Last 2 weeks of semester....

Last 2 weeks of the semester... nuff said.

Just posting to say I'm still thinking about ArcLib stuff and expect some new stuff for the summer, but right now and for the next 2 weeks I'm totally booked to the point where I can't even write a decent blog post about it.

Tango XML and Blaze

Blaze is nearing a 1.0 release. See Announcement. Blaze supports 2D physics for polygons, and has recently added joints. Since Blaze is too fast for me, I added some timing code into the Blaze demos that will cap the frame rate on faster machines.

I also replaced my XML code in ArcLib with the Tango XML code. The whole process was pretty simple, I only had one or two questions for the Tango folks about Tango XML, and then using Tango XML allowed me to reduce my lines of code count quite a bit, too.

First Blaze 2D Physics Engine Release

See the announcement for more details.

Get the Windows Demo: Blazed-Demos

*nix Users: dsss net install blazed-demos

What does this mean for ArcLib? It means, finally, that a major roadblock for Arc v.3 (polygons in physics) is removed, and all the built in Box2D Lite stuff that was built into ArcLib will be removed, as well.

Also, the next release of Tango looks like it will feature XML, so I can remove my own XML code from ArcLib in the next release. I can also remove a bunch of my templated code in ArcLib, thanks to Tango.

Box2D4D Officially Abandoned...

If someone wants to pick up where I left off...

1) branches/ has the old c++ --> D port and the attempt at a java --> D port
2) I think trunk/ may have the new c++ --> D port

The reason Box2d4d is being abandoned is because...

1) Impossible to debug (been trying to debug it for about the past 3-4 months)
2) Code is too complex for its own good
3) There is something better on the horizon...

:)

~ Clay

GlazeD, Chipmunk --> ActionScript 3.0 --> D

Alright, so box2d4d is a no go because it is impossible for Mason and I to debug. If somebody else can figure it out, feel free.

So, Mason found an Action Script 3.0 port of Chipmunk, except that it doesn't support joints. We are now trying to convert it to D, and it does compile but we haven't had the chance to figure out if it works or not.

As usual, I kept my habit of making doc comments. Here are the Ddocs.

So, hopefully this one will be easier to debug because it is simpler, and this one at least supports polygons.

Then, if we get it to work, Mason will base his rb2d efforts off of glazeD and add various features and things to it over time.

And, the big picture for me is, that I will have a physics engine in native D that I can integrate into ArcLib, that I won't have to maintain or add new features to myself.

Play Tankwars on Win32

Alright... probably should have posted this a long time ago... but here is tankwars for win32. For *nix users, wine will probably work.

Just in case anyone out there on windows wanted to try it.

Box2D4D 1.4.3 Documentation

Box2D4D 1.4.3 Docs

Ok, so I started over again with the latest box2d, and one of the things I did this time, was to give every variable and function a doc comment!

I got it to compile, and immediately compiled these docs.

Enjoy, Box2d fans :-P

On a side note, here's a link to a promising 2D physics engine written from scratch in D, rb2d. You can obtain it with 'dsss net install rb2d.'

Both these projects are one man wonders, so if there are any 2d physics programmers in the D community, feel free to jump in and join the fun!

TankWars Screen Shot

http://svn.dsource.org/projects/tankwars/downloads/screen.PNG

Just in case anyone didn't see it on the project page.

ArcLib Development Slowing Down...

ArcLib has been slowing down its development rate. I simply don't have the time to develop as much as I used to, so development from now on will probably be in short spurts every couple of months or so, and be more into a maintenance phase.

~ Clay