It's the end of the semester, and my partner and I spent about 7 hours yesterday finishing up tankwars with about 30 svn commits total, mainly loading tanks and helicopters and allowing them to randomly move and shoot on the map, adding sound effects, and letting the player shoot at the tanks. We had some trouble trying to get the tank pointed at the player, even using the point.angle(point) function, which we never resolved.
If you want to check out the final (unfinished) product, svn co svn.dsource.org/projects/tankwars/trunk/game, and run game.exe. There is a level editor that allows you to place objects and there is a game that allows you to 'play.'
Anyways, unless I get some abundant future free time, this project will most likely be stalled from this point onward, as I'll probably be spending time on my arclib and getting that in better shape.
Wednesday, December 5, 2007
Saturday, November 24, 2007
Box2D for D, take three
Alright, the java port was not giving me the correct output that I wanted. So, I decided to take the C++ D port, remove the memory management code, and implement the java solution for dealing void*'s. Now I'm getting an assert error. So, what I'm going to D, is mostly use the C++ version to base off of, and trace the C++ code versus the D code to see where I have gone wrong.
Monday, November 19, 2007
Box2D for D, take two
Alright, so I become stuck on box2d4d not only with the custom memory management code, but also with all the pointers, of which Erin Catto is a fan of. I didn't really have time to deal with the pointer problems, so I'm taking a different strategy.
There is already a java port of box2d, so I'm taking that code and porting it to D. I already got it to compile. After I get some examples working, I will then add doc comments, upgrade it to the latest box2d version, and perhaps the re-implement custom memory management.
The box2d4d project already has more files than my own ArcLib project has, to give an idea of the scope of the project.
There is already a java port of box2d, so I'm taking that code and porting it to D. I already got it to compile. After I get some examples working, I will then add doc comments, upgrade it to the latest box2d version, and perhaps the re-implement custom memory management.
The box2d4d project already has more files than my own ArcLib project has, to give an idea of the scope of the project.
Thursday, November 15, 2007
TankWars Development Update
The media is almost all complete. All required sound effects, and still images of the tank, helicopter, and person, as well as missle and tank shell. We have some tiles too. We still need person/tank/helicopter fire muzzle flash, destroyed vehicle art, and some dirt tiles.
Also, the XML level reader and writer is 90% done, the last 10% will just be testing it to see if it works.
My next task is to hook up the editor with the level reader and writer.
Also, the XML level reader and writer is 90% done, the last 10% will just be testing it to see if it works.
My next task is to hook up the editor with the level reader and writer.
Tuesday, November 13, 2007
ArcLib get's a logo...
Keyframe win's the logo contest! Many thanks and appreciations to all those who entered. It was a difficult toss up for me between CodexArcanum's logo and Keyframe's logo, but I feel that Keyframe's logo has a more professional look, and indeed more professionalism will be the theme of the Arc v.3 release as I believe that will be the first one on which real work can start being done with games and such as things start to stabilize and the scope of Arc is realized.
Tuesday, October 30, 2007
ArcLib Logo Contest Final Showdown!
The ArcLib Logo contest final showdown has begun! There have been a lot of good logo submissions, and there is still time to submit a new killer logo.
Here is the link to the final logo contest thread. As you can see, if you decide to submit a logo based on the specifications given in that thread, you can guarantee you'll win if you submit the only one and it is somewhat decent.
Good luck!
Here is the link to the final logo contest thread. As you can see, if you decide to submit a logo based on the specifications given in that thread, you can guarantee you'll win if you submit the only one and it is somewhat decent.
Good luck!
Monday, October 29, 2007
TankWars Editor Interface Complete
I've completed the TankWars level editor interface... you can now change the tiles on the tilemap and place game objects on the screen such as Tanks, Helicopters, and rocks. My group member is working on loading and saving a level with XML, and once that is done, the editor will be able to load up levels, edit them, and then save them back as XML files.
The editor is really simple and consists only of 'hotkeys' to edit. The most difficult part for me was simply trying to think in terms of a scene graph, but that took me a day or so and then I figured it out. The way I have my scenegraph set up right now is like so...
WorldTransformNode
-> TileMap (draw all the tiles)
--> Mouse notify node (sends signals to tilemap when mouse is clicked, gives relative mouse coordinates to the tilemap, based on transformation)
The advantage of the scenegraph is not having to calculate transformations myself, which saves a lot of hassle and is worth it once it is figured out.
Also, one of the aspects of Arc v.3 that I'm looking forward to is a large reduction of code without any loss of features :) This will be accomplished by moving all physics code to another project, simplification of the scenegraph, and reliance on Tango's template containers, as well as a possible re-factor.
The editor is really simple and consists only of 'hotkeys' to edit. The most difficult part for me was simply trying to think in terms of a scene graph, but that took me a day or so and then I figured it out. The way I have my scenegraph set up right now is like so...
WorldTransformNode
-> TileMap (draw all the tiles)
--> Mouse notify node (sends signals to tilemap when mouse is clicked, gives relative mouse coordinates to the tilemap, based on transformation)
The advantage of the scenegraph is not having to calculate transformations myself, which saves a lot of hassle and is worth it once it is figured out.
Also, one of the aspects of Arc v.3 that I'm looking forward to is a large reduction of code without any loss of features :) This will be accomplished by moving all physics code to another project, simplification of the scenegraph, and reliance on Tango's template containers, as well as a possible re-factor.
Tuesday, October 23, 2007
TankWars Update...
Here is a little update on my semester long class project that is now 'officially' started.
The TankWars main screen is pretty much complete, it just needs a 'resume' button and a title. It has a 'New Game' button, an 'Editor' button, and an 'Exit' button. When the new game button is pressed, it takes you to a screen that shows a TileMap in a world transform node that can be controlled with the players keys.
Nothing too fancy yet...
I myself am semi-new to the scenegraph in Arc, I havn't really done too much with it until now. I got myself running with it pretty quickly from the scenegraph test, however. The scenegraph is probably not the most newbie friendly concept, and today I thought that it might help to store a scenegraph scene in an XML file and have some sort of scenegraph builder program. It would shorten the users code dramatically, and the scenegraph could be seen visibly as it should be. Until then, ArcLib users need to be pretty proficient in programming to use it.
The TankWars main screen is pretty much complete, it just needs a 'resume' button and a title. It has a 'New Game' button, an 'Editor' button, and an 'Exit' button. When the new game button is pressed, it takes you to a screen that shows a TileMap in a world transform node that can be controlled with the players keys.
Nothing too fancy yet...
I myself am semi-new to the scenegraph in Arc, I havn't really done too much with it until now. I got myself running with it pretty quickly from the scenegraph test, however. The scenegraph is probably not the most newbie friendly concept, and today I thought that it might help to store a scenegraph scene in an XML file and have some sort of scenegraph builder program. It would shorten the users code dramatically, and the scenegraph could be seen visibly as it should be. Until then, ArcLib users need to be pretty proficient in programming to use it.
Wednesday, October 17, 2007
Development halted for a week or two...
Alright, development has pretty much halted for a week or two. This week I have 3 midterms and this weekend I went to the ACM conference and watched presentations by the founder of the XKCD web comic, the guy who wrote the digg.com software, the authors of Girl Genius web comics, and a few other presentations.
When I get time, I'll be working on TankWars.
When I get time, I'll be working on TankWars.
Thursday, October 4, 2007
Flashbacks from the past...
Today, I delighted myself by stumbling on one of my old school WarBots projects. Before I started ArcLib, the project was actually called WarBots and was meant to finish a game that me and my friends attempted to build in High School but never got very far because the lame school admins shutdown the project from their lack of competence (grrr... see: http://warcoders.sourceforge.net/ for more info on what the project was meant to be and how far we got).
Anyway... I ran the exe and amazed myself at what I could accomplish in 2005 with limited D and OpenGL knowledge back in the day, when compiler numbers were still in the .70's and one had to write their own bindings from scratch.
For the curious, here's the way to access the files via SVN.
1. svn co -r 172 http://svn.dsource.org/projects/arclib/ warbots/
2. cd 'warbots\trunk\current'
2. Run 'game.exe'
To interact with the game, click the building, click 'train unit,' type 'miner' then hit enter. Then proceed to witness the miner vehicle collect metal scrap on the map. It uses per-pixel collision detection and a lua script to define the miner's AI.
I'm also amazed that SVN actually kept /EVERYTHING/, I'm afraid to know how much space my project takes up on poor old dsource.
The part that gets me is that I didn't even realize how far I got on that project.
And, as time passed, I decided I needed to write a good generic 2D game library before attempting to write any more game code. I've discovered that large projects have a 'point of no return' where, once the project reaches a certain size or complexity, more and more manpower must be used to achieve less and less of a result.
WarBots reached that complexity for a 1 man project, and ArcLib was the answer to reduce it. Look how far it's gotten me ;)
Anyway... I ran the exe and amazed myself at what I could accomplish in 2005 with limited D and OpenGL knowledge back in the day, when compiler numbers were still in the .70's and one had to write their own bindings from scratch.
For the curious, here's the way to access the files via SVN.
1. svn co -r 172 http://svn.dsource.
2. cd 'warbots\trunk\current'
2. Run 'game.exe'
To interact with the game, click the building, click 'train unit,' type 'miner' then hit enter. Then proceed to witness the miner vehicle collect metal scrap on the map. It uses per-pixel collision detection and a lua script to define the miner's AI.
I'm also amazed that SVN actually kept /EVERYTHING/, I'm afraid to know how much space my project takes up on poor old dsource.
The part that gets me is that I didn't even realize how far I got on that project.
And, as time passed, I decided I needed to write a good generic 2D game library before attempting to write any more game code. I've discovered that large projects have a 'point of no return' where, once the project reaches a certain size or complexity, more and more manpower must be used to achieve less and less of a result.
WarBots reached that complexity for a 1 man project, and ArcLib was the answer to reduce it. Look how far it's gotten me ;)
Wednesday, October 3, 2007
Current Development Highlights ...
1. ChristianK was able to figure out the problem with one of the D files crashing. Apparently it has to do with forward references and enums, and putting an enum in its own file fixes the problem. For the curious, here is the actual bug link.
2. Box2d is almost able to compile, there are just a few last minute memory management codes that need to be implemented and some other small fixes in b2World before it will be able to compile. After it can compile, then the next stage is getting it to work.
3. When working on my TankWars game, I ran up against an OPTLINK bug. Thankfully, that was fixed by using the beta linker found in the bugzilla issue. All that is done for the project is the project layout and a simple 'main screen' for the game with 3 buttons, New Game, Editor, and Exit.
4. I'm really busy. Most of my time will go to my new TankWars project I'm working on for a class, and if I do get any free time, I will be working mostly on the Box2d4d port.
5. ChristianK has implemented some really sweet particle effects in the current development version of arc & asteroids.
6. Tango's logging system is really nice. Each module can have it's own logger, and each logger is part of a tree hierarchy, so you can grab a hold of the root logger and then output all the information of each logger anywhere you want, I like to use the FileAppender. The output looks like this.
2. Box2d is almost able to compile, there are just a few last minute memory management codes that need to be implemented and some other small fixes in b2World before it will be able to compile. After it can compile, then the next stage is getting it to work.
3. When working on my TankWars game, I ran up against an OPTLINK bug. Thankfully, that was fixed by using the beta linker found in the bugzilla issue. All that is done for the project is the project layout and a simple 'main screen' for the game with 3 buttons, New Game, Editor, and Exit.
4. I'm really busy. Most of my time will go to my new TankWars project I'm working on for a class, and if I do get any free time, I will be working mostly on the Box2d4d port.
5. ChristianK has implemented some really sweet particle effects in the current development version of arc & asteroids.
6. Tango's logging system is really nice. Each module can have it's own logger, and each logger is part of a tree hierarchy, so you can grab a hold of the root logger and then output all the information of each logger anywhere you want, I like to use the FileAppender. The output looks like this.
Thursday, September 20, 2007
Box2D C++ porting woes...
My projects are somewhat stalled now, due to the porting of box2d.
1. This problem has stopped me for a while, until I gave up and asked for the answer on the Box2D forums. I knew what pointer + i was, but pointer - i is new to me.
2. D compiler crashes when trying to compile some of the .d files. I'm hoping this will resolve itself as I get more and more D code to compile. If not, it's another potential time waster as I look for a work around or wait for a compiler fix.
I still have some hope that I can get it done soon, though.
1. This problem has stopped me for a while, until I gave up and asked for the answer on the Box2D forums. I knew what pointer + i was, but pointer - i is new to me.
2. D compiler crashes when trying to compile some of the .d files. I'm hoping this will resolve itself as I get more and more D code to compile. If not, it's another potential time waster as I look for a work around or wait for a compiler fix.
I still have some hope that I can get it done soon, though.
Friday, September 14, 2007
Box2d, for D!
Alright. Erin Catto's Box2D (www.box2d.org) is going to be /the/ 2D physics system, as the success of his original Box2D has already created many spin-offs.
I want to be able to have access to the most advanced 2D physics I can have in ArcLib, but keeping the physics system up-to-date with Erin's new stuff is going to prove a challenge, and in order to accept this challenge, I started a seperate box2d4d project on dsource which aims a providing a close-to-source as possible translation of Box2D.
The ArcLib physics system upgrades is now a three step process, now without pressure of us ArcLib developer's having to develop new physics features ourselves, but merely staying up-to-date.
The pipeline goes like...
Erin Catto Updates Box2d --> box2d4d updated --> arclib updated if needed to support latest version.
Simple, mechanical 3 step process. The first pass will be the hardest, the rest will be easy and I can concentrate on other aspects of ArcLib, like lighting and the API. Until then, my time will be spent on box2d4d.
~ Clay
I want to be able to have access to the most advanced 2D physics I can have in ArcLib, but keeping the physics system up-to-date with Erin's new stuff is going to prove a challenge, and in order to accept this challenge, I started a seperate box2d4d project on dsource which aims a providing a close-to-source as possible translation of Box2D.
The ArcLib physics system upgrades is now a three step process, now without pressure of us ArcLib developer's having to develop new physics features ourselves, but merely staying up-to-date.
The pipeline goes like...
Erin Catto Updates Box2d --> box2d4d updated --> arclib updated if needed to support latest version.
Simple, mechanical 3 step process. The first pass will be the hardest, the rest will be easy and I can concentrate on other aspects of ArcLib, like lighting and the API. Until then, my time will be spent on box2d4d.
~ Clay
Tuesday, September 11, 2007
Requested Project on Dsource
Today, I gave my partner the run down on arclib, had him install D + DSSS + Arclib, and requested a dsource project for the game.
~ Clay
~ Clay
Saturday, September 8, 2007
About this Blog and New Untitled game project in the works...
About this blog:
I'm going to use this blog to post about the development of my ArcLib Project and my game projects that I will design using the ArcLib.
Untitled Game Project
I'm going to start making a game for a class this semester, for my graphics class, and it's going to use the ArcLib. I've convinced one of the class members to use D and ArcLib to work with me on the project, as we have to work in teams. I've already started the first stage of game development: writing down my concepts on paper. The goal for the game is to be fun and to be complete within one semester. Here's what ideas I have so far for the game, which I wrote on paper first w/ pictures, and I re-wrote it here as well. Paper + Pencil = greatest way to write down concepts.
1) Codename: Tank Wars.
Terrain styles: Desert and grass
Mission types: Destroy all enemies, stay alive for X amount of time, and retrieve enemy data and bring back to 'base'
Vehicles: Civilian, Tank, Jeep, Truck, and Helicopter, along with weapons that correspond to each vehicle.
Graphics: Photo-realism would be nice...
Levels: Either randomly generated, or loaded from an XML file
Soundtrack: Maybe some techno
Game Objects: Tree, rock, buildings
Features needed to do: Tilemap, lighting, custom GUI theme
11 Steps to get the project done:
Prototype 0: Custom GUI theme and start menu and player hud
Prototype 1: Wire frame tank that moves with other tanks on the map
Prototype 2: Tank Graphics
Prototype 3: Sound Effects for the tank, and tank Weapon Fire, Sound Track
Prototype 4: Implement Destroy All Mission
Prototype 5: Implement Game Objects
Prototype 6: Implement Jeep vehicle and civilian vehicle, and allow civilian to enter and leave vehicles at will
Prototype 7: Implement truck vehicle
Prototype 8: Implement helicopter vehicle
Prototype 9: Implement the rest of the mission types
Prototype 10: Implement lighting effects and night/day time settings
Of course, the prototypes are just a rough guide of how to get a game complete with manageable chunks.
Player Keys:
Enter: Enter / leave vehicle
Space: Fire weapon
Arrow Left-Right: Rotation Left/Right
Arrow Up-Down: Move Forward/Backward
Caps Lock: Turn on-off vehicle lights
ArcLib Project Recent Developments
1) Christian Kamm has developed some cool lighting, which will slowly make it's way into Arc.
2) I fixed the GUI theme system to be an over-loadable class so users can simply write their own themes for their own games. I also need to make a default theme in Arc that looks sort of decent but doesn't require any user-graphics.
The reason for this whole theme thing, is so users can make the GUI look pretty themselves, and I don't have to worry about GUI prettyness, just it's functionality instead.
As I attempt to develop a game this semster, most of the development I will do on Arc will probably be making sure existing features work well, and the MultiLineTextBox and other 'from scratch' features may have to wait.
~ Clay
I'm going to use this blog to post about the development of my ArcLib Project and my game projects that I will design using the ArcLib.
Untitled Game Project
I'm going to start making a game for a class this semester, for my graphics class, and it's going to use the ArcLib. I've convinced one of the class members to use D and ArcLib to work with me on the project, as we have to work in teams. I've already started the first stage of game development: writing down my concepts on paper. The goal for the game is to be fun and to be complete within one semester. Here's what ideas I have so far for the game, which I wrote on paper first w/ pictures, and I re-wrote it here as well. Paper + Pencil = greatest way to write down concepts.
1) Codename: Tank Wars.
Terrain styles: Desert and grass
Mission types: Destroy all enemies, stay alive for X amount of time, and retrieve enemy data and bring back to 'base'
Vehicles: Civilian, Tank, Jeep, Truck, and Helicopter, along with weapons that correspond to each vehicle.
Graphics: Photo-realism would be nice...
Levels: Either randomly generated, or loaded from an XML file
Soundtrack: Maybe some techno
Game Objects: Tree, rock, buildings
Features needed to do: Tilemap, lighting, custom GUI theme
11 Steps to get the project done:
Prototype 0: Custom GUI theme and start menu and player hud
Prototype 1: Wire frame tank that moves with other tanks on the map
Prototype 2: Tank Graphics
Prototype 3: Sound Effects for the tank, and tank Weapon Fire, Sound Track
Prototype 4: Implement Destroy All Mission
Prototype 5: Implement Game Objects
Prototype 6: Implement Jeep vehicle and civilian vehicle, and allow civilian to enter and leave vehicles at will
Prototype 7: Implement truck vehicle
Prototype 8: Implement helicopter vehicle
Prototype 9: Implement the rest of the mission types
Prototype 10: Implement lighting effects and night/day time settings
Of course, the prototypes are just a rough guide of how to get a game complete with manageable chunks.
Player Keys:
Enter: Enter / leave vehicle
Space: Fire weapon
Arrow Left-Right: Rotation Left/Right
Arrow Up-Down: Move Forward/Backward
Caps Lock: Turn on-off vehicle lights
ArcLib Project Recent Developments
1) Christian Kamm has developed some cool lighting, which will slowly make it's way into Arc.
2) I fixed the GUI theme system to be an over-loadable class so users can simply write their own themes for their own games. I also need to make a default theme in Arc that looks sort of decent but doesn't require any user-graphics.
The reason for this whole theme thing, is so users can make the GUI look pretty themselves, and I don't have to worry about GUI prettyness, just it's functionality instead.
As I attempt to develop a game this semster, most of the development I will do on Arc will probably be making sure existing features work well, and the MultiLineTextBox and other 'from scratch' features may have to wait.
~ Clay
Subscribe to:
Posts (Atom)