Messages

Well, this is still going to be an adventure game and those tend to feature magic pockets

About the unique weapons: Yeah, but even a Katana isn't usually longer than 100cm. I'd say you can add style to that sword by other things than length...

Wait a minute... an inch is 2,54 centimeters, right? That means the blade is about 60cm long. The blade in the picture is almost as long as the character is tall. Where is that not too long?

Besides, I've done some kendo. If it's a two-handed sword (not European of course), it should be about one meter in length. That would be about as long as his leg.

That's about what it's supposed to look like: http://www.shinzen-dojo.net/le_dojo/les_gardes/chudan_no_kamae_g.jpg

The sword is quite long, but that's some nice work you've done on the main character's face. 

[Practically, you don't have traditional copyright,]

Copyright disclaimer:
People donating material here may not add further restrictions, such as "oh, you can't use my background because I want it to only be featured in good games." or "You may only use my character if you have already released at least three games I can look at".
If you wish to remove your link, just say so. As long as it's here, anybody is free to use it.

Practically, you don't have traditional copyright, since you can't demand people that have used your character in a game to take it down.

Still, people are urged to include the originator in the credits. Failure to do this may result in  their name ending up on a black list.

I don't think a forum post is enough to retain from copyright in the law of all nations. You should agree on "as long as it's not sold".

@zabnat & yarooze: No, I've never fired a gun before which is why I said "would" and "I think that" all the time    I don't want to theorize too much, I just thought professionals shoot both-handedly with slightly bent arms. I don't know how to prevent a gun from hitting your head by recoil so it would be arrogant to theorize about how to prevent that. I'd be glad to learn something about that.

@Evil: I think you're changing so much that every hint of the original style looks non-fitting. The legs are much more stable now, the shoulders are broader, yet the chest and belly remain, making the overall appearance too wasp-like imho. Sephiroth's girl looks almost naked, but your girl looks almost nude. It's a different style and would look good if applied to the whole body... I have to say that oversexy-izing Sephiroth's girls is something I would avoid. 

I'd still not stretch out my arm totally when holding a gun. I think that would make my hand shake too much. Also, you're trying to have detailled shading on the clothes with not so many different colors. The man's shirt looks like it's black camouflage or something and could use at least one more shade of grey. The woman's clothes are okay but look like they have less contrast than the man's.

Other than that, it's definitely gaining style!

Scene dependant, just like I said.
What I meant is that that pose doesn't look like these girls were trained to use guns.

Yo! I see you did some work on the black clothes. They look far better now, good job!

The broader and more detailled legs would require the whole body to be made broader, might as well create a totally new sprite from scratch.

The blonde woman still has somewhat weird shading. I see you're trying to make a different material, but I'd still try making the grey either darker or use gradient-like shading.

The weapon-bearing poses look like the women need some item to carry so you gave them a gun. People aiming somewhere have a more upright if not bent forwards stance and the gun at eye's height. I also think that people who actually use guns wield them both-handed, but I've never used a gun. I think the Counterstrike Logo is a man with an MP in a quite professional, stable stance. That would point out what I mean.

Of course, that's all scene dependant.

Already looks a whole lot better. If you ask me, it has a good unique look now. For example the hair: it's still not realistic but it fits much better this way. The poses are the same. Still somewhat bent the upper chest upwards but it does have its own style. You might want to experiment with an additional pixel for the neck to make it look less fragile, dunno.

However, the legs of the left woman still look a bit strange. I'd say the knees are slightly too low and the Gastrocnemius muscles (sorry, I don't know the English word. It's the muscle on the rear side of the shin) are non-existant.

Yeah, the shading is better but I would advise you to do even more about it. How many sprites are you planning to make?

I'm no expert on graphics, but I guess a layman opinion is better than nothing (Is that even a word?).

1. Pose: Nothing against a sexy pose, but your women aren't standing upright. That would be okay, but the torso sections look as if the pose was normal standing and not leaned back, yet the shoulders look like they were pointing backwards.

2. Legs: The legs are quite thin and flexible in your pictures. There's only the knee, so it's actually two straight lines (thighs and shins). The round shape of a slightly bent leg comes from the thighs and shins being thicker. These womens' legs couldn't support their weight, I think. Give the thighs some more substance, shins are okay imho. Also, the leftmost woman has unevenly long legs or is it just me?

3. Hair: Nice, but monochrome and, about that left woman: Hair doesn't stay that way. May be intended, but I thought why not say it. 

4. Face: I think better defined faces would decrease the anorexic look a bit.

5. Said anorexic look: You should make these women a bit broader, then you can also save up yourself some pixel trouble. See for example the right leg of the leftmost woman? It's only two pixels wide. Three would be too many.

Advice? Well, you could start out by using proportionally aligned lines to determine how broad the shoulders are, how long the torso is etc.

I'd say your sprites look good for freeware AGS, but you wouldn't ask for help if you wanted no improvement 

Well, come to think of it, you could draw the background mines using 8 objects, each object being a big layer. Would also solve the foreground mines problem. However, if you really need this many mines at once, you'd still have to figure something out.

Fun thing is: My name is not actually Heiko. 

The rocket ammunition gauge indicates you're from Germany! That's actually funny, because I'm from Germany, too.

The Surface Drawing wouldn't allow you to put mines in FRONT of your ship, so the parallax scrolling method only works under the assumption that the largest mines are the game-relevant ones.

About the slow-down: You'd just have to try it. I don't know the source code well enough to give you an exact estimation of processor usage, but I think, more than the number of mine layers, the absolute size of your background in pixels is the important factor. I'm no professional, but loading a larger picture into the video memory is, depending on color depth and compression (i.e. file size). Seemingly, your background is quite a large bitmap, and "only" 20 mines for a big minefield is a bit too little I guess. One solution would be to let the mine field consist of multiple shorter levels. Another idea would be not to "destroy" mines after they leave the playfield or collide with the player, but to just change their position back to the front. That way you could have 20 mines on screen at once, not necessarily 20 mines at all. But if you, for example, intend the background (with 5 background mine layers) to have, say, a few thousand pixels in width, that would be 6 huge bitmaps to load every cycle.

I guess you can only experiment. If you want to talk to me in German so I can explain a few things easier, mail at x-heiko@skullbyte.de

Yesterday, I took a look at the link Pumaman posted. Assuming that you have only your starship and the mines (Can you shoot? Then let's just assume we have 5 projectile objects or "others"), then you can use about 30 mines without problems. The rest would be background.

And, as far as my understanding of it goes, it would definitely NOT slow down the game, it could increase loading time at best. In short you convert the background into a Drawing Surface, then stick a lot of little mines in the image (could even make them random) and THEN give the order to release your changes into the actual background. There is not 3000 little objects, there's just (up to) 3000 iterations where mines are being pasted into the background. You could do it even more elegant and just use layers - larger pictures with a few hundred mines each. That would mean 6 or so additional lines of code, each not much more CPU intensive than loading the BG into the video memory. Hell, you could even make ONE single background image, but then - why not just include them in the background image? Or did you mean parallax scrolling?

You can't excessively slow down the game with too many objects because their number is limited.

For parallax scrolling, you could yet use another trick. Get each mine of the same size into one sprite, a big layer so to speak. Let them move with differring speeds, faster for large mines, slower for small mines. That would still only be 4-5  additional objects (I can't quite make out how many different mine sizes you've got there). If the large objects slow down too much, you could still use a refreshing algorithm in the "repeatedly execute" function, which would go something like "On every game cycle: Change the background of the room to [picture with no mines]. Make it a drawing surface. Depending on the position of the player, draw [picture with smallest mines] on (player's X coordinate / large number). Then draw [picture with second smallest mines] on (player's X coordinate / less large number). Then, Then, Then draw [picture with largest non-object mines] on (player's X coordinate / smallest number), then release the changes." The Y coordinate would have to be constant and same for all.

A possible result would be: Let's say the player flew a bit and is at X = 200. Given the number 10, 7, 5, 3, 2, the mine layers would have their left border at 20, 28, 40, 66 and 100. That's only a possible example and I'm not sure whether it's even a good idea, but you may want to try it. Drawing Surface is actually really helpful.

Wow. I didn't know there's a drawing command. I've not yet read into drawing surface routines but what you say sounds helpful AND a lot more like what I originally intended to do. I'll look into that, thanks big time for the help!

Yeah, of course it's possible to simulate such big arrays with tricks, but it's user-friendlier to just have multi-dimensional arrays. I am working with a mixed-base numeric system to address the array.

EDIT: Sorry for the hasty post. I've quickly overlooked it and DrawImage would be a somewhat friendly solution to it all, but my code is still based around the connection wires having an integer property at which they're addressed from inside the code. I'd need to re-program the visualization algorithm which is why more objects would be a lot more comfortable to me, but that doesn't justify "requesting" an update for AGS. I'll try to see to finding a work-around. Thanks though!

So, I know that the object limit is quite high (40), compared to older Versions of AGS. I also know that AGS is intended to be a program for coding Adventure games, which is not what I'm trying to do (fully, that is, but that doesn't matter.).

I have of course searched the forums on this matter, but similar questions were always answered on either very old versions of AGS or in very special cases, giving work-arounds for given cases.

Now to my problem: I'm making an adventure which is rich in minigames. These minigames are intended to be somewhat complex. An object limit of 40 is a little too little for me because there are random riddles to be made with a lot of combinatoric possibilities of the exact outcome of the riddle itself.

I also know of the technical limitations as Object data is saved in an array, which means every extra object limit increase increases memory usage. That doesn't quite tell me why I can't increase the array capacity on my own, as the author. A simple "Warning: try to keep the object limit small" message in the preferences window would do the trick. Using a list instead of an array might be too slow, but it would be flexible for sure. Of course, giving solutions is utopian, especially with no knowledge of the source code whatsoever. Sorry if I'm sounding arrogant, I'm really not trying to do so.

Anyway, I suggest the object limit to be raised. In my case, I'd need about 60.
I would also like to suggest multi-dimensional arrays to be implemented in AGS. It requires a bit of complex mathematic structure to handle a 8192 elements large array which I wouldn't expect from a typical AGS user (which doesn't mean that I see myself as anything better.).

IF however I can only expect a specific piece of help, here's my problem:

I'm making a minigame where 12 logic gates (AND, OR, NAND, NOR, XOR, XNOR are the possible gate types) are arranged in 3 logic levels of 4 parallel gates each. There are 8 input bits and 4 final output bits. The logic levels are randomly connected and an output combination is given. The player has to figure out a combination of input which has the given output combination as a result. That's 8 objects for input bits, 4 for output, 12 for gates and 32 pieces of connective wire that each can be assigned one of 8 graphics, illustrating the connection modes. That's 56 objects, 12 of which could, if necessary, be replaced by buttons.

It's very difficult to imagine by text. If anyone is seriously interested in helping me specifically, I can send a few graphic examples.

I'd like to thank you for helping me in advance.