Dugoma Clone

[RAF68]

link does not walk home quelqu 'un can give me another link which walks thank you

[Hajo]

@Gambit37:

I almost had given up on this project a while ago, because the high number of graphics disturbed me too. At the moment the graphics data is about 1600 files, and this is borderline insane. Particularly since I'm just starting with this.

I only have a paper sketch of the plan. But it should be easy to sum it up: The field of view is 7 blocks wide, and 4 blocks deep, that is a total of 28 positions. Some are not visible, but 18 visible positions remain. I have the light source not centered, so the field is not symmetrically lighted. I thought this helps to improve the view o corridors.

Floors, walls, ceilings need 18 views.

An item which is centered on a square needs 18*4=72 views, since it can be rotated. (My earlier message with 144 files was right, since each view produces an image file and a file with some magic numbers ... so it's not been 144 images, but 144 files. 72 images for the niche thing).

The small items can be placed in 4 positions in a block. This is where the insanity really starts. 4 positions in a block, 4 rotations of an item in each position, 18 visible blocks, that means 4*4*18=288 images for those ...

If I'd use symmetric lighting I could halve all of those numbers. But beyond that, it seems the views are needed, unless I want to stretch/modify the images in memory/on the fly - but if I can have full precision renders at little extra cost, it seemed a waste of effort to code such routines, since I get all views automatically, and the distant ones are very small, often only a few kb.

So formerly I decided to go the path of the many files, let the raytracer render all these views and have as much automatism as I can have to have to handle the amount of files. Still I do not like this, I dislike bloatware, and I do not like the idea of producing such myself ... so this project is against my principles actually. But I thought, maybe I'm too much old-school once again, and for modern computers this is not really a problems; also many people seem not to have a problem to download 100mb for a game demo. I know though, I wouldn't. And there is the catch again ...

A graphics system like this allows for really good quality, this is a fact that I like, but it comes at a high cost in space. I think there are only two solutions: Make full use of the options, within the limits that current computers set (well my computer is 6 years old soon, so "current" in this context means my old box ), or go the total opposite, make a very simple graphics system with it. The middle ground is better covered by the polygon based 3D systems, like OpenGL and Direct3D.

This is my first project with all raytraced graphics. Formerly I did a lot of painted graphics, in between a mix and now I have reached the opposite end, it seems. I think I'll stay here for a while, and explore the options. For sure it's fun to work on it again, the break was good probably.

Edit:

@Bit: Sorry missed your message while typing. I'll write more tomorrow. I think it's a worthy thought to produce tiles that are usable with other projects, too, like yours.

[Gambit37]

@Hajo: I understand what you're saying about wanting realistic lighting, etc, but to be honest players don't notice small inaccuracies while playing. I really wouldn't worry about asymmetric views for items on the floor or walls for example (unless it's really really obvious for a big item that would look silly otherwise). 288 images for items in an alcove is honestly silly. I'm sure you could get away with using ONE image that's relatively positioned and scaled and uses alpha blended masks over the top to simulate shading. This is what RTC does and it works fine (admittedly it's lower res.)

I like what you've done but I'm concerned you've massively overcomplicated it. Simpler is almost always better

[Bit]

Hajo, I just visited your homepage and that was pretty impressive.
I think, all we can do is reflect your own thoughts for that you can decide.
Then again - don't misunderstand me, that's absolutely the same for me too - we are old-fashioned programmers. Do we really know what today's library like OpenGL and DirectX are able to do, including all those shaders and whatever else exists can bring in? For me the answer is no!
After all - nowadays it simply isn't important anymore if there is a really high number of files. You pack them into a large database and that's it. And of course, size doesn't really matter anymore too if things can be realized and the result is satisfying. And this is a lot more than a dozen years ago.
The other interesting question could be: is it possible to have some kind of realtime-raytracing?
There the first concepts have good looking results. Perhaps it's the time to update ourselves what is possible. Let's look around a bit

[Hajo]

I'm glad to hear that you like my homepage, Bit Over the years quite some projects and stuff piled up. Actually I just never got into real 3D coding, but a short try to learn OpenGL, which left me impressed by the features, but it also seemed to be very complex.

I've talked a lot about the graphics options of a DM style rendering system - in the past I had explored also very low-fidelity graphics for another project:

Small scene from a former (failed) try to create an RPG:
http://www.funkelwerk.de/site/misc/line ... _scene.png

Another, somewhat bigger example with a different scale:
http://www.funkelwerk.de/data/study/lin ... p_site.png

I just wanted to say, I appreciate simple styles, too. Just with this project, I'm leaning to the more detailed and realistic side of graphical display. Still I'm concerned about the feasibility of the chosen path ...

Realtime raytracing is something I'm very much interested in. My box is too old, but the demos that were shown in the past year are very promising. The polygonal rendering processors are very strong, after 10 years of evolution, but maybe companies like Intel have the power to place alternative display systems in the market. I'd assume that it's mostly a matter of time till realtime raytracing comes - and there are also the forgotten voxel engines, which had their merits, too, but without hardware acceleration, they can't compete. I think we face an interesting future in terms of graphics engines.

288 images for items in an alcove is honestly silly. I'm sure you could get away with using ONE image that's relatively positioned and scaled and uses alpha blended masks over the top to simulate shading. [...]

I like what you've done but I'm concerned you've massively overcomplicated it. Simpler is almost always better

I agree wholeheartedly to the KISS principle. A small problem here is, that actually it is simpler for me to let the raytracer do all the math, perspective and positioning of items. Basically I took the brainless route, the code does nothing but putting the images on screen, this is very simple.

I'd actually need to make the code more complex to do the scaling and shading, so I buy a smaller number of files by more complex code (which is usually harder to maintain and more error prone).

I've been thinking for a while if it makes sense to store only the near views, and use only one image for the distant views. But this also will introduce more switches to the code, and require additional routines to scale, shade and place the objects. The distant views are all very small files, so the saving isn't even very big, and comes with quite some complexity in the code.

I hope I do not come across too much defending my solution. I know I'm slow in changing my decisions, and it sometimes needs a good while until I make up my mind about new suggestions.

Easy savings:

- Some of the objects do not need 4 rotations. Gates need only 2, and the big amphora would be acceptable with one. This will half or quarter the number of images needed for these.

- Symmetric light will also reduce the number of views needed. Not quite half it, but I think instead of 18, only 10 or 11 block positions must the calculated and stored.

I think I'll implement these two options, both need a bit of additional code but the saving are quite big.

I'm preparing a new walkaround demo - it's now 7.5mb, just because the new walls do not compress so well as they old ones. Maybe later the day I'll have something to show.

[Hajo]

I know the last version did not work for some people, but I'm a bit uncertain why. I figured that mouse events worked, but key events did not work for some people. I have changed the focus handling, but since the old demo worked for me, it's hard to say if this one works better. At least it worked as well as the old one for me.

What's new?

There are now two floor types which are placed in a pattern, to help the impression of moving in big open areas. Also, there are now two wall types, with new structures.

=> http://www.funkelwerk.de/applets/dugoma-004/

You can now rotate the big objects by pressing R. That'd be the already known big amphoras and spider gates, and the new wall niches which can be placed by pressing C.

You must place such niche in front of a wall - stand one step back from the wall, press C, and then rotate it till it's aligned with the wall. Also just a proof of concept.

I manged to push the download just under 7mb, but as already mentioned it needs to shrink. For those who have the problem that they cannot move, try clicking the window title bar, or inside the window, and please let me know if this helps, i.e. if key presses are reported to the code, and it acts accordingly.

Edit:

Hajo, just take the time and checkout my 'reloaded' version together with your wallset.
Take a look in the given wallpictures (they are all between ~050 and 100), replace some with your wallpicture (just pick the right maskcolor) - and just see if that wouldn't be enough.

I've downloaded it (hopefully the right package) and I'm unzipping it right now. Will be interesting to compare!

Edit 2: I see, DM had a much simpler system. Nice, simple and clean, the assortment of graphics there. No surprise that my approach appears like a monster to the old-time DM modders and clone devlopers. The graphical simplicity is compelling, so much is certain.

Edit 3: For a moment I was shocked when I ran the v0.4 demo on another PC for testing - it ate 216mb ram I have no idea how or why, but it seems that on PCs with more ram, the Java runtime makes generous use of that. On my own PC it only needs 46mb ram, and in an artificial restricted system, it even ran in 36mb ram. So there is hope that the demo runs on older systems, too, but still, that was quite the shocker.

[Erik Bauer]

Gave it a run right now...
Well, here are my points and suggestions:
1)You definitely need to flip the tiles each step. Without that trick the walk effect is totally absent.
2)It is a bit too shiny and light, expecially the square where the party is standing, I think a more dim light would be more appropriate even with a full torch or full Light spell in action.

For the rest seems to be OK, I like the wallset but more variety is needed within it (But I guess you're still working on it as this is just a demo)

[Hajo]

I'm just starting with this project. So far I have a rendering system and some base graphics. I have improved the graphics several times, and I'll continue to work on it - or just stop the project if I have the impression that it makes no sense to continue. I do this mostly for the fun, and out of curiosity. So please don't expect too much.

About the walking effect problem, I feel a bit puzzled. The former version had only one floor type, but in this version there are two different floor tiles, and they should be sufficiently different to give the walking effect, much like a flipped floor tile would. I'm quite sure that it works, since I saw it in my tests. I added the second floor sort as a response to the former feedback that the walking effect is missing. The pattern is irregular though, and you might just have been in a room which had a big area of only one floor tile sort?

"Totally absent" sounds like it worked nowhere. If it is absent everywhere, you have found a bug indeed.

About the lighting, I have tried to adjust that, but so far failed. The raytracer has a falloff curve for light that is only changeable so much. It disturbs me too, so some day when I get new ideas how to improve it, I'll work on it again. But at the moment this is the best result that I could achieve. Maybe I could try less light overall, and a stronger gamma correction, which should enhance the middle light levels in comparison to the brightest.

Thank you for the feedback, though. It helps to know where the weaknesses are.

Edit: Back to testing different lighting schemes. Will take a while to render all tiles again, but I hope I can provide a screenshot in a while for comparison purposes.

[Hajo]

I think I have two comparable screenshots now:





Which one do you like better? I also might be able to do further adjustments, but it will be more difficult to do them if I have a lot of graphics already.

[Beastman666]

I vote for the top picture...feels more "greepy" and looks nicer.

[beowuuf]

Agreed

[Gambit37]

Top lighting is better.

I tried the 0.04 demo. It still doesn't work in Google Chrome. Well, actually, it loads but I can't move. EDIT: Hmm... If I leave the popup window for about 30-60 secs, it does finally work and I can move around. I think you need to optimise! Either that, or it's an issue with my JRE (V6, update 13). I have a pretty old PC but it plays Half Life 2 just fine, so this small demo shouldn't cause it any issues surely?

The floor flip effect isn't working the way DM works. DM has one image for the floor and flips the whole thing. You've opted to make individual cells have their own image -- and some change when moving and some don't, so the walking effect is not working. This is really unnecessary. Save yourself a lot of trouble and just use one image. No-one will notice the difference when playing.

Similar problems with the walls -- they don't change consistently, so again the walk effect isn't convincing. Have a play of the original DM and see how simple this effect is: basically, the left hand walls are swapped for the right (and vice versa) on each forward step. It's all you need to make the effect work, and I think you're overcomplicating things by trying to make this "realistic". I think you could easily get away with replicating the DM method and still have this look good, simply because you're using much higher quality images.

The joins at each corner aren't convincing -- I think the highlights are too strong, and some walls don't line up. For example:

[ian_scho]

I have the same pause in Chrome, Gambit... It's downloading! There's normal text on the page that it says it'll do this the first time, but there are no progress bars or other niceties that users are used to

[Hajo]

I'll try to respond to the points:

Loading time: Yes it takes a while to load. If half life 2 loads faster, then that is fine. I cannot do much, I just call the JRE API to load a PNG file, and it takes a while. I'd like faster loading too. Maybe some day I find a solution.

Ian's idea of progress bars is good, I'll see if I can add that. Thank you for the suggestion, Ian

Floor flipping: I assume it's hard to imagine, but flipping a floor or wall tile is fairly difficult for me. I have a slight suspicion that you are trained to the DM effect, and thus any other effect looks not right. Anyways, I cannot do the DM effect without spending serious additional work, and I think the walking effect inn the demo is good enough.

The wall lineup I might get fixed some day. At the moment the effect puzzles me, but actually it wouldn't bother me, and I'd just call it good enough. I knew about it before uploading the demo but called it "good enough". A dungeon wall may have flaws in the corners.

Highlights: I've already turned highlights to 0. Less than zero my raytracer cannot do. I want to see if I find workarounds.

I've now spend some hours again on the walls, just to notice there are more problems, which are not so easily solvable again (but can't be seen from static screenshots, they involve turning). But the highlight, and maybe general ambient lighting seems to be better:




I have a feeling that I cannot deliver the demanded quality though. It was quite stressy and frustrating to improve the walls any further since the last demo. I think I must stop doing this, and continue the project on a level of intermediate quality which is somewhat easy and swift for me to create. I'm still interested in this kind of graphics and rendering system, but it will have flaws, and I must get more self-secure to say these will stay, or that something is good enough in my opinion. Will be hard at times, but seems to be necessary to keep this project easy and fun enough to do in my spare time.

I want to say thanks, though, for the detailed feedback. Even if at some points I must say "stop, I don't want to spend more work on that", it is good to know where I meet and where I miss the demand.

[Gambit37]

Oh! I'm not trying to dissuade you from continuing. It's a great piece of work already and has lots of potential, so I hope you continue. I'm just pointing out things that could be improved. Unfortunately I sometimes come across as harsh; it's not meant that way.

The new lighting in the new screenshots is very cool; looks more solid and 3D now, nice job.

Floor flipping: I assume it's hard to imagine, but flipping a floor or wall tile is fairly difficult for me. I have a slight suspicion that you are trained to the DM effect, and thus any other effect looks not right. Anyways, I cannot do the DM effect without spending serious additional work, and I think the walking effect inn the demo is good enough.

As I'm not a programmer, I don't know the detail of what you're doing, but it does seem to me that having one image for the floor and simply horizontally flipping it around its mid point it would be much simpler than what you have currently.

I'm afraid I disagree that the walking effect is currently sufficient. It's not working because the floors and walls don' flip and/or alternate consistently. So some movements look OK, but for others it just looks like the walls are sliding around the player, rather than the player moving within the space. (This is the same problem in Dungeon Grind). I'm not trying to be annoying or over critical; it's a simple fact that if you don't simulate movement on every step (by alternating the floor AND the walls), then it appears that the player isn't moving.

Regarding the Chrome start up -- the 60 second wait is AFTER I've clicked in the dungeon display to remove the splashscreen. It already took 30 seconds for the popup to appear in the first place. The comment about Half Life wasn't too serious -- but the point remains: once the player is presented with the game space proper, they shouldn't have to wait another minute to start playing. I realise it's a demo, but you'd need to solve this for mainstream appeal: people have no patience these days

[Paul Stevens]

I have not played the demo and am probably
talking nonsense....but....if you have two
different floor images and you place them
in checker-board fashion....shouldn't the
effect be the same as DM? That is what
DM does, in fact.

[Erik Bauer]

And maybe it is doing so... but then the tiles are not different enough: when I played the demo, the only visive things to tell me I was walking forward were the lateral exits from the corridors moving towards me or the wall in front of me becoming bigger and bigger or the number of tiles separating me from the wall.
Maybe there are difference between near tiles but these differences are not big enough to spot up a movement effect.

I'll play again the demo trying to pay more attention to the effect.

@Hajo: Looking at the latest pictures I like the lighting a bit more, even if it's still glossy... have you tried to turn the light source a little bit red or yellow? That would give it a nice "Light coming from torch's fire" effect and should reduce the gloss a little bit.

[Erik Bauer]

I'm testing it again right now...
Well the movement effect, as I can see, seems to be totally absent... I'm going to make myself clear (read this as a suggestion or costructive criticism):
when I step forward, the floor tile that was right in front of me is replaced by another one that is exactly identical, the same happens for the tile two steps in front of me.
The very same thing can be told for the wall tiles: they are always looking the same.
This way, without a step/burst movement effect (Bard's Tale, Dungeon Master II, Entombed) when you are in a big enough room or long enough corridor, when you step forward nothing seems to happen at all, unless some object on the floor gets nearer indicating you are moving towards it.

The solution to this problem is rather simple: Having at least 2 different tiles for floor, roof, left and right wall and alternate them each step movement. This way each step movement will be perceived by your eyes as something is changing on the screen.

[Bit]

I have not played the demo and am probably
talking nonsense....but....if you have two
different floor images and you place them
in checker-board fashion....shouldn't the
effect be the same as DM? That is what
DM does, in fact.

Adamo missed this in my clones already too, I wonder where I lost that piece of code.
It toggles floor and ceiling, but not the walls atm.
EDIT: found and fixed it! available with next upload.

@hajo:
the basic 'checkboard'-idea is:
if the position (x+y+z) is odd, the mirrored wallset/floor/ceiling will be used.
The trick is, that walldecorations (alcoves too!) are added later!

[Hajo]

I'm testing it again right now...
when I step forward, the floor tile that was right in front of me is replaced by another one that is exactly identical, the same happens for the tile two steps in front of me.
The very same thing can be told for the wall tiles: they are always looking the same.

I cannot understand this. The first demo has only one floor and wall tile. So there was no such effect. The second demo (which shows as v0.4) has two tiles each. The pattern is not checkerboard, but irregular, but usually the movement effect is visible. I had done this in response to the feedback with the first version, and it shows in my tests. I cannot understand why it does not work for you

I think I could even prove that with screenshots, but it seems useless. You don't see the effect, and so I must assume it doesn't work for you. I know howto make regular checkerboards, I just re-used code from an older project that produces irregular patterns. I can make it checkerboard if it's that important, but since Erik sees no patterns at all, this won't really help much.

[Gambit37]

The movement effect does't work in the latest demo because it's not consistent. Sometimes the image on a floor tile changes, sometimes it doesn't. And it's the same problem with the walls. It appears to be completely random?

You need just one image for the floor and ceiling and flip it on every other tile as Bit proposed. And for the walls, you basically swap the left hand images for the right on each step (obviously you need to flip these too). It's up to you how you do it of course, I'm just trying to help you cut down on the amount of work you've given yourself I won't labour this point anymore and will not mention it again.

[Erik Bauer]

I'm testing it again right now...
when I step forward, the floor tile that was right in front of me is replaced by another one that is exactly identical, the same happens for the tile two steps in front of me.
The very same thing can be told for the wall tiles: they are always looking the same.

I cannot understand this. The first demo has only one floor and wall tile. So there was no such effect. The second demo (which shows as v0.4) [....]

Then maybe I understood the problem: following the link in the first post of the thread, the demo that opens is labeled as V0.3! This might be the cause of the misunderstanding

[Gambit37]

He he, good point. @Hajo: you should probably update the first post with the revised link each time you make an update. Lots of people look for links in the first post of a thread and it's easy to miss new links lower down.

[Hajo]

The movement effect does't work in the latest demo because it's not consistent. Sometimes the image on a floor tile changes, sometimes it doesn't. And it's the same problem with the walls. It appears to be completely random?

The floor is layed out for the dungeon at creation time, patterned in an irregular style - this pattern is made with a random number generator, so yes, it is random. I wouldn't call this a problem though.

I want to postpone further work on the floor pattern and also the wall style. I think I have spend too much time and effort already on these, while there is so much still missing in this project.

Since the graphics data takes such a big part in this project I decided to lower the resolution to 512x384 pixels, which will immediately save about 30% of space. This area will be embedded in a 800x600 pixel window area, which should be a good size to work with on a lot of systems. Below is a screenshot of the new new size, also featuring the recently added copper coins and item "stacking", rather offsetting system:

(800x600 seems to wide for the forum, so I link the image rather than inlining it)
=> http://www.funkelwerk.de/data/dugoma/te ... _coins.jpg

The dungeon display is framed by 4 areas while will carry game information and control elements eventually. The two brown areas can be merged into one bigger area if that will turn out to be more useful than the two small areas. The dark blue area at top is supposed to show messages to the player, one line. The green area at the bottom will be kind of an inventory area with direct access to the players possessions.

I do not have plans to make DM clone in strict sense, and to make this clear I have arranged the UI differently from DM. I just want to make a game with a graphical display that was inspired by DM. At the moment the general idea is "dungeon exploration and puzzle solving" - there will be no party, and no fighting, thus most likely no stats or player character progression. It's still a very blurry idea, but I'll try. There might be more options to alter the environment than DM has, for example to remove walls in certain situations, or maybe to flip/exchange two wall tiles - if I continue the idea that wall pattern will have a meaning, and in some cases it will be important to arrange the walls in a certain pattern.

I also have evaluated options to save space by reducing the overall number of graphics needed. It seems that particularly for items like the coins which previously needed 240 views, there can be drastic saving, so that only 12 or so are needed. I must investigate this further, also change some code, but so far the new approach looks very promising and should cut the storage space requirements down quite a bit, particularly in future when the game has a lot of different items included.

I worked on new spider gates as well, with true semi-transparent drops along the circular mesh lines. Unfortunately it turns out that the effects isn't that much better than the old gates and the rendering times went through the roof. I'll see what to do, but for the time being I think I'll try a compromise since I have to re-render the graphics rather often due to adjustments in the light sources and overall size.

[Hajo]

@Hajo: Looking at the latest pictures I like the lighting a bit more, even if it's still glossy... have you tried to turn the light source a little bit red or yellow? That would give it a nice "Light coming from torch's fire" effect and should reduce the gloss a little bit.

The light source is yellow, but it's indistinguishable from yellow walls in the screenshots - the walls are actually quite gray and the light makes them more yellow. I was a bit disappointed too, when I tried it. Meanwhile I had even forgotten about it and was wondering why a blue color does not appear blue until I remembered that i had the light made yellow. I think I'll keep it though.

The gloss is a problem of the walls, and maybe the total strength of the light. For the moment I want to let the walls be as they are, since the last update already took 4 hours of experimenting, and I rather want to work on the project core some more - if the project turns into something interesting I can still adjust walls and light later.

I have uploaded a sketch how the inventory area could be used:
=> http://www.funkelwerk.de/data/dugoma/in ... a_test.jpg

The idea is to have all items directly accessible. They will be selected by a click, and a list of options what to do with that item will show in the left border area. I don't know how well this will work, but since many items will have a few usages, this seems to be a good idea. I'm too lazy to implement drag and drop for this project, so I strive for a simple point-and-click interface.

I think the usage list will depend in the selected item, and the object faced, for example "unlock" could be a usage of a key, but is not active until you face a lock. Otherwise it will be shown but disabled.

I'm a bit worried though that the inventory area is too small, but I could choose smaller graphics and stack the items better ... must see how that will work out. Feedback on the inventory and usage list ideas will be welcome. I know that DM did it differently, but my concern is rather if the described approach will work for a puzzle-centered game.

[Erik Bauer]

I see... and I agree: let the light stay for now, time gives nice ideas.
I like the inventory at the bottom of the screen, it is easy to access and makes you think it is not a realistic game like DM is putting you in the mindset "This is a puzzle game".

About the item images: maybe writing a small routine that resizes them by taking away one every 2 pixels won't be so hard to implement and you'll manage to save space in the inventory list. I'm not sure the trick would still make justice to the GFX tho, you'll have to experiment.

Another solution would be to have the inventory scrolling left-right when the mouse reaches the borders.

[Hajo]

While Java does not support flipping of images on the fly (well, it does but requires a matrix transform which I assume to be slow), scaling works very nicely and fairly fast. So it's no problem to scale images - also I have a number of different sizes in the set already, just chose the largest ones for this test.

I can put the whole inventory view in a scrollpane, but I think customizing the scollbar look and feel is quite some work. Must see, that is more a question of how lazy I am than a technical problem.

I still feel very uncertain about this project. Once I do not want to step in competition with those who make combat oriented dungeon crawls, on the other hand the puzzle idea seems to be fairly difficult - difficult in the way to make it interesting for the player. Not only once, but each time the game is started ...

if it doesn't work out I can always change my mind and make it a more standard dungeon crawl.

[Bit]

Not that it had a direct relation to a dungeon game, just for inspiration:
http://www.janko.at/Raetsel/Masyu/index.htm
(sorry, is in german, but the google-translator works okay for the rules - also: http://en.wikipedia.org/wiki/Masyu)

[Erik Bauer]

Well, a dungeon puzzle can be quite intriguing, if done properly.
But are you willing to make a rogue-like dungeon puzzle? That can be definitely challenging to implement.... but if you want somebody to discuss about program logic count me in as I'm thrilled by this kind of challenges

[Hajo]

This depression makes things very difficult. Like the door problem, on some days even the smallest tasks look insurmountable. With being unhappy there also comes a big sensitivity to things being said to me, and even if I know people try to be helpful and friendly, on some days it freaks me out a lot ... this combination of my own inability to get stuff done and the suggestions how to do it right.

For the moment I think I want/must/will let this rest for a while. I'm sorry to disappoint. If I cannot pick up work on this anymore I think I'll release the graphics under an open/shared license and look for easier things to do in my free time. Graphics work, although I'm not really gifted there, is easier than coding these days, and this is a big change from how things have been for me in the past ... I must see what the future will bring.

I'll try to stick around, this forum is a good place.