No decent internet connection until the 20th.
I've been thinking of hooking ArcLib up to the minid scripting language to provide rapid prototyping of games.
Some more extensions I plan on to help provide the rapid development of games as well.
arc_actors - keep track of actors in game
arc_menu - in game menu capability
arc_credits - end credits capability
arc_hud - in game hud capability
arc_tilemap - bird eye tilemap
arc_scrolling- scrolling tilemap
Some other tools in consideration...
Map Editor
Sprite Editor
Tools to facilitate rapid game development plans are the current future.
Thursday, July 9, 2009
Friday, June 26, 2009
D - Good, Bad, Ugly, Pretty
Well I just got back in South America and it looks like the community is trying to get an honest evaluation of the D language so that it can plan for its future correctly. This is a healthy process (unless the complaints are ignored), therefore I will voice my opinion on the state of D, or more so what should be done for D's future success.
First of all, I see the biggest problem for D is that the community is small, and there is no incentive for the community to grow. All jobs are done in C++, Java, C#, etc. Because D isn't really old or rich, the community isn't likely to grow much in the future. From my experience, D is a hobby language and that isn't looking like it will change much in the future, not without a lot of money. I see D's small community and lack of real world jobs in D as the MAJOR problem with D, and probably as a huge reason why people try D, like it, then move on. Those who stay are not in it for the money, but the love of the language.
Second, productivity tools. You can have the most productive language in the world, but if C++ or C# has better productivity tools for refactoring / coding, the productivity of the language itself may not matter as much as the productivity gained through the productivity tools. Plus having no productivity tools scares away main stream programmers.
Third, stability. While stability is somewhat accomplished with D 1.0, there is a new DMD release, new phobos + Tango release about once every month or two. These releases tend to have small breaking changes that make old code obselete if not updated every month.
Fourth, simplicity. The simpler the language, the easier it will be for new people to pick up or maintain. Some people enjoy complexity, while I enjoy the simplest possible solution. D 1.0 is almost perfect, but IMO D 2.0 is creeping on the complexity scale. If a concept can't be quickly grasped by most programmers, perhaps it should be left out.
I really don't see the D language itself as the problem, and I see the D tool chain easily improving in the future. The real problem with D is that no one is ever going to use it in serious applications, because no one really knows it. Its not taught in the University, D has no means of spreading the word of itself, its not revolutionary enough to really catch anyone's eye. No one will use it because no one uses it, there are other languages that perform a decent job with decent productivity tools to accomplish practically the same thing as D (C#, Java, Python, etc).
So, what's the future of D? I think the future of D is in indie games. The end user doesn't care what language its in, productivity is increased, and most game bindings are already converted to the D language. Since indie games are usually written by a small team without industry experienced "bosses", they can freely choose the language they want to use.
D will continue to excel in hobby projects as well, since there is no real money stream coming from D incorporated to fund itself.
My prediction is that D's state will probably stay the same, maybe picking up some more indie game developers, for the future.
First of all, I see the biggest problem for D is that the community is small, and there is no incentive for the community to grow. All jobs are done in C++, Java, C#, etc. Because D isn't really old or rich, the community isn't likely to grow much in the future. From my experience, D is a hobby language and that isn't looking like it will change much in the future, not without a lot of money. I see D's small community and lack of real world jobs in D as the MAJOR problem with D, and probably as a huge reason why people try D, like it, then move on. Those who stay are not in it for the money, but the love of the language.
Second, productivity tools. You can have the most productive language in the world, but if C++ or C# has better productivity tools for refactoring / coding, the productivity of the language itself may not matter as much as the productivity gained through the productivity tools. Plus having no productivity tools scares away main stream programmers.
Third, stability. While stability is somewhat accomplished with D 1.0, there is a new DMD release, new phobos + Tango release about once every month or two. These releases tend to have small breaking changes that make old code obselete if not updated every month.
Fourth, simplicity. The simpler the language, the easier it will be for new people to pick up or maintain. Some people enjoy complexity, while I enjoy the simplest possible solution. D 1.0 is almost perfect, but IMO D 2.0 is creeping on the complexity scale. If a concept can't be quickly grasped by most programmers, perhaps it should be left out.
I really don't see the D language itself as the problem, and I see the D tool chain easily improving in the future. The real problem with D is that no one is ever going to use it in serious applications, because no one really knows it. Its not taught in the University, D has no means of spreading the word of itself, its not revolutionary enough to really catch anyone's eye. No one will use it because no one uses it, there are other languages that perform a decent job with decent productivity tools to accomplish practically the same thing as D (C#, Java, Python, etc).
So, what's the future of D? I think the future of D is in indie games. The end user doesn't care what language its in, productivity is increased, and most game bindings are already converted to the D language. Since indie games are usually written by a small team without industry experienced "bosses", they can freely choose the language they want to use.
D will continue to excel in hobby projects as well, since there is no real money stream coming from D incorporated to fund itself.
My prediction is that D's state will probably stay the same, maybe picking up some more indie game developers, for the future.
Wednesday, June 24, 2009
Back From SA
Back from SA: http://pcsa2009clay.blogspot.com/
Need a couple weeks to get settled down, working on ArcLib if time permits.
Need a couple weeks to get settled down, working on ArcLib if time permits.
Monday, May 18, 2009
Tuesday, May 12, 2009
Busy as Hell
In one week, I have had...
* Finals
* Graduated College with B.S. Computer Science
* Packing up apartment
* Getting ready for my 42 day South America trip
Leaving May 13... Getting back June 24th.
http://pacificchallenge.org/?page_id=18 Search South America
I will be gone for a little while, then. I also have just installed Ubuntu 9 side by side with MS Windows, but I'm contemplating making Ubuntu my main OS for this computer.
* Finals
* Graduated College with B.S. Computer Science
* Packing up apartment
* Getting ready for my 42 day South America trip
Leaving May 13... Getting back June 24th.
http://pacificchallenge.org/?page_id=18 Search South America
I will be gone for a little while, then. I also have just installed Ubuntu 9 side by side with MS Windows, but I'm contemplating making Ubuntu my main OS for this computer.
Saturday, April 25, 2009
Hybrid now runs on the ArcLib Core
The Hybrid GUI has been ported to the Arclib Core from DOG.
The main issues in the process was deleting DOG and getting xf.input to run on top of SDL (thanks LeoD). In addition, I added input code to read in SDL's unicode characters. The only problem is that now when you type the backspace character, it inserts the backspace character instead of deleting text. The xf. imports were changed to arc.hybrid, as well. Besides calling
arc.window.open("Title", 800, 600, 0);
while(true){ arc.input.process(); arc.window.clear(); <--hybrid code--> arc.window.swap(); }
arc.window.close();
and renaming the imports, all the code should pretty much work the same. Here are the examples I have working so far.
So, ArcLib now has a good GUI. Enjoy!
The main issues in the process was deleting DOG and getting xf.input to run on top of SDL (thanks LeoD). In addition, I added input code to read in SDL's unicode characters. The only problem is that now when you type the backspace character, it inserts the backspace character instead of deleting text. The xf. imports were changed to arc.hybrid, as well. Besides calling
arc.window.open("Title", 800, 600, 0);
while(true){ arc.input.process(); arc.window.clear(); <--hybrid code--> arc.window.swap(); }
arc.window.close();
and renaming the imports, all the code should pretty much work the same. Here are the examples I have working so far.
So, ArcLib now has a good GUI. Enjoy!
Friday, March 20, 2009
Per Pixel Collision Detection Extension Added
There is now a collision map class in the new arc-perpixel.
Usage link.
Implementation link.
This class allows for per pixel collision detection. It can also build its own collision map circle, box, or create a collision map based on the intersection of two boxes. It can test for collision between two PerPixel classes, or it can test collision against a single X,Y point.
Usage link.
Implementation link.
This class allows for per pixel collision detection. It can also build its own collision map circle, box, or create a collision map based on the intersection of two boxes. It can test for collision between two PerPixel classes, or it can test collision against a single X,Y point.
Subscribe to:
Posts (Atom)
