Archive

Posts Tagged ‘Programming’

Donationware Release for Nanowrimo

October 31st, 2009 5 comments

Hi all, I have released an early version of a Java desktop application I am calling “aMuse” developed for NaNoWriMo.  Screenshot:

amusescreenshot

Download the zipped  All-in-one Executable

Zipped Runnable JAR (MAC) (ALPHA)

This application is designed to break through writers block by noticing inactivity (30 seconds) and popping up a thought balloon with different words (primarily action verbs, but some variety as well) to stimulate the writer’s creative process.  By default random fonts are turn on, which uses a handful of packaged fonts to stimulate creativity.  The balloon is draggable, you can force it to always be on (not just when you are inactive), and you can turn off the random fonts using the right-click on the system icon tray.  If there is a demand, I would like to look at showing images, and possibly even playing music (possibly through a streaming web service).

I haven’t done a lot of testing, this was developed on a Vista machine w/ java 1.6.10.  Comments on system requirements and bugs are solicited.

If you’d like to donate something for my time and towards future development, I’d appreciate it.

myRoguelike Update

September 21st, 2009 No comments

So the myRoguelike project has been on the back burner for a little while, but I assure you it is not forgotten. I am considering ways to differentiate it from the current stock of roguelikes, and my have hit upon an idea. I am considering the possibility of making it a “buttonless” roguelike. How many other “buttonless” roguelikes there may be, I don’t know for sure, but I suspect that given the nature of the genre its few if any. I can already hear the shrieks and questions of how and why from the millions of followers that this project has, but I think it might be cool to try to provide the depth and variation of play that roguelikes are known for in a “buttonless” package. As a teaser, I will grant that in the traditional implementation, there would be buttons used in the “buttonless” implementation, but they would be confined strictly to movement and could be replaced by a mouse, trackball, or finger (possibly). Any comments?

Categories: Programming Tags: , ,

Where does SOA architecture belong?

September 21st, 2009 No comments

Where does your organization manage SOA services? Are they the property of an application development organization or an enterprise services organization? Does it depend on who the end user is or what back end or subsystems the web services depend on? What about for vendor provided applications? These are questions we need answers to! Leave a comment.

Roguelike Dev Update

April 3rd, 2009 No comments

So I cleaned up some memory leaks that I figured would probably be trouble later.  I may still have one or two lying around, but it is order of magnitudes better now.  I used Visual Leak Detector for assistance.  New updates include extracting the level into a view port so that levels bigger than the screen can be accommodated by a moving window.  This was actually surprisingly easy to do.  It acts as a translator, taking the level-relative locations of cells and glyphs and turning them into screen relative points.  Also added rudimentary random level generation, as you can see in the new flash movie.  Currently it generates randomly sized square rooms with an open end in the center bottom.  Expect more complicated layouts in the future.  The walls also have hit points, like entities do, but the whole hitpoint / combat system is just a place holder for more complicated stuff.  Like, metal swords breaking down wooden walls, but only scratching concrete ones.  I also started setting up the game logic to accomodate multiple levels, as evident from the debug “level respawn” feature in the video.

Next up in the development track, items that entities can pick up, carry, and use.  I’d like to get jack equipped with some kind of ability to temporarily boost his speed.  His framework is all set up for that already, but I need to decide how to give him the choice on when/how to activate it.  As for the player, I’d like to get him wielding a weapon (or not, at a button press).

The Flash plugin is required to view this object.

myRoguelike Dev Update

February 21st, 2009 No comments

I have a new video demonstrating a revamped look, some more demos involving rudimentary effects and AI, a debug mode which I hope I won’t need much of, and a message window prototype.  To talk about the AI for a moment, where before it was blind, deaf and dumb, now it isn’t (quite).  What I mean is that it has a “sense” (like sight, smell, sound, taste, feel, etc), which its brain consults before decisions are made.  And, yes, now you can see there is at least one decision being made, namely “Do I follow the yellow dots, or go around in a circle?”.  If there is a yellow dot in its square, the AI follows the trail, otherwise it goes in a circle.  It is not difficult to imagine an almost infinite variety of AIs which could be developed just based on this one “sense” and the simplistic “A or B” decision making process.

The debug mode I coded in because it was becoming clear I needed a quick way to consult what a given area of the level “looked like” in code.   The windowing system and display redesign kind of came out of that.  The display is essentially a copy of Nethack or ADOM.  The single yellow number “3″ is Chas’s primary stat.  Unlike some other games, I am planning to employ a good deal of information hiding and discovery in this game, and the idea is that this stat is all you start off “knowing” about yourself.

The movie is again in untimed mode, because I find that easier to test in.  Untimed mode means the game pauses indefinitely for user input, as opposed to a “real-time” game where game time elapses independent of user input.

<p>Demo of updated effects, new interface, prototype message window, and debug mode.

It’s Alive!

February 12th, 2009 No comments

Well, I managed to add a prototype for entity “brains”.  Plug a brain into the entity, and away we go…This BasicBrain (as I have so creatively named the class) sets up a movement queue that tells it to run around in a circle.  If for some reason it can’t move where it wants to this turn, it skips that movement.  This is a “feature” of the current game logic engine, which doesn’t yet notify entities of things like “couldn’t move;  @ blocking way”.  I expect to handle some of that when the combat engine work starts, which should be soon.

I also changed the way the curses color pairs were managed, putting them into a singleton color manager.  Check out the Pages link under MyRogueLike -> ScreenShots for a cool .swf video of the AI in action.  The game mode is set to untimed turns, so the movement may appear jerky as I input keys in odd intervals.  I am not the Cyan @ symbol.  Rest assured, I have not (yet) noticed any performance problems.  From the movie, you’d think I was making RoguePaint v.01!

Roguelike Dev Update

February 9th, 2009 No comments

The latest screen shot represents many hours of blood sweat and tears spent hassling with std::sort() on vectors of pointers to objects, among other things.  Fortunately, it turns out I am not completely stupid.  Again, the screen shot does not show much in the way of difference, except for one obvious thing.  However, I was able to code in stats for entities, and also even begin working on effects. Currently the stats support permanent and temporary values, with the temporary values consisting of ordinal pairs where x is number of turns the temporary effect should last and y is what the effect is.  I anticipate in the future making the class a bit fuller in order to support various rates of degradation.

As you can see from the screen shot, entities (including the player) have statistics broken down by color.  The on screen avatar is displayed in the color of the highest statistic.  I prototyped a movement effect, which currently leaves the vacated square of a moving entity the color of that entities highest attribute, but I can envision other cool effects that can be done once I sort out how these effects will integrate.  The nice thing right now is the cell basically just asks for any effects, and it could theoretically treat those effects afterward much like it treats the entities.

colors_and_trails.jpg

myRoguelike update

February 4th, 2009 No comments

I managed to get some more work done on the myRoguelike engine.  I implemented a user input model wherein all entities on the map are notified of user input and take appropriate action (currently just moving in the 8 compass directions).  I did the movement in a way that involves using the map to decide whether it is possible, not the entities (although may decide for themselves whether status effects, etc prevent them from moving).  I also implemented movement blocking, which is on by default, so that entities can block each other from moving over certain squares.  So far, it was pretty painless to implement the blocking and the extra inputs.  Because the map level coordinates the movement, it was also easy to set boundaries on movement to the restrictions of the level.  And since all entities (including the player) are treated the same, that movement should hopefully be a relatively bug free issue going forward.

entitymovementandblocking.jpg

Level up!

January 29th, 2009 No comments

Well, I made some progress, even though you won’t see much difference in the below screen shot.  I set up the basic data structure for levels, and filled a sample level with “cells”.  Those cells currently don’t do anything except display the roguelike equivalent of basic ground, however there is more to it under the hood (I hope, anyway).  I also set up a basic Command class (ala GoF) and started tinkering with user commands.  “Move left” is the prototype.  When I sort out how I want to expose all the various objects and values the commands will need, I can move on to making a basic playground level.

levels.jpg

Check out myRoguelike Pages

January 29th, 2009 No comments

Three new pages were added to the Pages link at the right.  More info to come as work progresses on the project.

Switch to our mobile site