Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Nomosoft

Pages: 1 2
Paid Work / [PAID] Looking for a concept/character artist
« on: December 21, 2016, 11:46:36 pm »
Reference images are attached to this post. I'm looking for someone to create one or two concept pieces for a character/setting. I'm looking for something with 70s blaxploitation flavor: big, square cars, hip-hugger jeans, afros, guns etc. The style I want is either realistic, or semi-realistic cartoon. Think something along the lines of Archer. I'm also going to attach a picture that's full-on cartoon, but would work fine for this commission.

I'm not terribly picky about the medium you work in, but I don't want any 3d renders that have that plastic 3d render appearance I don't like that flat, smooth look. I also do not want that oil-painting fantasy-game look, unless you do something really amazing with it. I need something at a high enough DPI to be printed at a reasonable size. I prefer something in a digital format that I can work with, but that's not an absolute requirement.

I'm not necessarily looking for the cheapest option. I want someone who will work with me, and who can deliver the look and feel I'm aiming for. Style > price > medium.

Don't be upset if you reply and don't hear back from me. I am posting this to numerous places, and I am going to respond preferentially to artists who can show work that fits the style and/or subject matter of this commission. Having said that, please post your portfolio links, example pieces, and/or rates. You can send me private messages if you prefer.

Game Art / Looking for artist(s) for match game - paid
« on: December 25, 2012, 02:00:00 pm »
OK, I got zero responses to my last call for artists, but I'm going to try this, one more time.

I need an artist or artists for a match-3 style game. The project is fairly small, I am looking for perhaps six object sprites, possibly animated, one large background, and a game-screen interface (score, time, etc.)

In my head, I am seeing polished vector or rendered 3D pieces, but I am always willing to consider other options. Please reply or message me with portfolio links, rates, and so on.


Paid Work / Need a character sprite
« on: November 13, 2012, 11:40:58 am »
Edit: Just to be clear, the character will be in a 2D side-scrolling environment. I would render 3D models to sprites for use.

I need a character along the lines of the player character used in Limbo:

I do not want a clone of that character, but I am looking for a realistically human-shaped character, done in a similarly minimal style. The mood of the game is intended to be a bit gloomy. Another game with the sort of humanoid characters I am looking for, but not the right mood or setting, is Aquaria: I prefer the character be closer to the Limbo character in proportion.

The character will need to: Walk, run, crouch, jump, climb, and hang on/dangle from objects. Character may also need to creep (see: crouch), and slide.

This character does not need to be 100% polished. I am currently trying to put together a demo to get my partner interested in the project. Basically, I need a character charismatic enough to convince my fellow programmer/other half of the money that the project is worthwhile.

Please reply here (to keep the thread alive) if you think you can do this. I will want to see examples of your previous work. If you want to whip up a concept piece, please do.

I would LOVE for this character to be vector art, or a fully rigged and animated 3D model, but I am certainly willing to consider straight pixel art.

Send me a private message with your rates, schedule, and anything else you want me to know. I will likely be posting this ad on several developer forums, so please don't be offended if I don't choose you. I look forward to working with someone on this, soon.

Ask a Question / Stencyl and wmode=transparent
« on: July 19, 2012, 12:42:12 pm »
I want to create a Stencyl project with a transparent background. I've done this with Flash in the past, using the wmode param with a value of "transparent" in the <object> tag. This doesn't seem to work with Stencyl. When I select "no color" for my scene background, Stencyl seems to produce the exact same thing I get when I select a white background: the game fades in to a solid white rectangle, and wmode doesn't allow me to see through the background to the page below.

So, if I want a transparent background and want the actors drawn directly onto the web page behind the game's HTML container, what do I need to do?

When I recycle an actor immediately on collision, then create a recycled actor of the same type, the new actor's Y-speed and rotation speed are both still set to the previous actor's values. This happens even if I use a "set y-speed to 0" block immediately before using "recycle self." So, not only do some values seem to be carrying over, it would appear that new values (at least those set in a collision event) don't take effect, immediately. I don't know if there is some sort of buffer that sets the properties the following frame, or what, but it may need to be flushed on a recycle call.

If I "create recycled" twice, without a "recycle" call in between, the values are zeroed out.

Old Bugs (1.x/2.x) / Plummeting performance
« on: May 03, 2012, 02:41:30 am »
I have a problem that only seems to have shown up since I upgraded to the release build of 2.0. The game I am working on seems to have developed a strange resource leak. The game runs fine for a few minutes, then starts to bog down, and eventually the frame rate hits single digits. The problem is worse in the standalone player, but it shows up in the browser, too.

My first thought was that I had actors not being properly disposed of. So, I wrote a behavior to display every single actor type and a running count of how many of each actor exist in the current scene. That does not seem to be the problem, all created actors are being destroyed, and the numbers all fall back to zero as actors leave the screen/are destroyed by bullets/whatever.

Next, I conjectured that I had an out-of-control behavior doing something silly, so I wrote a profiling behavior and timed every single behavior being used in my game. Although I do have a few resource hogs, they are all fairly stable. I don't have any behaviors that expand to gobble up more and more cycles as they run. So, that also doesn't explain the creeping slowdown.

My actors are being properly disposed of, and my behaviors are crunching along at a steady pace, but my game keeps slowing down, anyway. It _seems_ to be centered around creating and destroying actors. I say _seems_ because I really haven't been able to pinpoint the problem, but I can sort of coax it into happening by creating and destroying a ton of actors. It isn't the actual creating and destroying that eats up the time, though. The slowdown continues even after the actors have been created or disposed of. The game behaves as if there are many actors in play, even when the actual count shows few or none.

Here's an illustration of the problem:
I have a character that produces a burst of bullets. The frame rate takes a hit when the bullets are created, but jumps right back to 60 FPS as soon as the creation is complete. The bullets go zipping off the screen and are destroyed. After a few dozen bursts, I notice that the frame rate is taking more of a hit, and not recovering as quickly. Instead of dropping to 50 FPS when the bullets are created, it drops into the 30s, and takes a couple of seconds to get back to 50+. Then, after a few dozen more bursts, the frame rate drops all the way to single digits every time there is a burst, and takes a long time to recover, and never actually recovers all the way to FPS, instead hitting the 20s or 30s. Essentially, the game is acting like I have dozens and dozens of actors in play, even though the actual count is zero once the bullets fly off and are destroyed. It's as if every time I created an actor of type "Bullet," every "Bullet" that I ever created (and destroyed) is being processed. The "Update" and "Render" times jump through the roof when the new burst is created, then  settle down some once the bullets fly off the screen. This gets worse and worse as the game plays on. At the beginning, the increase in Update and Render time is not even noticeable.

I have a game uploaded under my account with "Trimmed" in the name. I don't want to make it public, but the Stencyl team are welcome to look at it. It's not perfect, but it's the easiest way I could fine to demonstrate the issue. The problem is actually worse in a "real" game, where multiple types of actor are being created and destroyed, and multiple actors are shooting bullets at one another. It works like this: Load the game, and hold your Shift key down right from the beginning. Holding Shift shuts off the bullet firing behavior. While holding Shift, hit the tilde and look at the Update, Flixel, and Render times. On my computer, they are something like 0ms Update, 6ms Render, 6ms Flixel, 8ms Flash, 14ms total, 60FPS. Let go of the Shift key and let the ship spew bullets for a few minutes. Now, hit Shift, again, and notice that Update, Render, etc, stay much higher than before and the FPS drops (on my computer) by a solid 10+ FPS. Repeat the process, and watch how Update, Render, etc, creep even higher, as the framerate bogs down. The yellow text on the left shows a running count of all actors in the game. You'll notice the performance degrades despite the number of actors settling back to 0 every time. I've tried this on three different PCs with completely different hardware (probably different versions of the Flash player, too, but I didn't check) and they all show the same problem. I did not notice this happening pre-2.0.

As I mentioned, it takes longer for the effect to show up in the browser (Firefox, for me), so leave the game sit a few minutes if you want to see what I'm talking about.

Shared Resources / A very simple code profiler
« on: May 02, 2012, 07:53:51 pm »
"Profiler" is probably a little too grandiose a name for this behavior, but it'll do.

Ever since I upgraded to 2.0 official, I've had a bizarre resource leak problem in a game that was working fine, before. I suspect it may be a Stencyl bug, but I don't want to assume that until I've exhausted all my options. I've spent the last four or five days trying to track down the problem with no real success. So, I am now going to profile every behavior in my game to see where the time is being spent. To that end, I've written a very simple behavior for timing other behaviors. This behavior is seriously alpha-stage, and I wouldn't normally release such a half-assed behavior to the public, but I don't see anything like it on the Forge, so I am going to go ahead and upload share it.

The behavior is called Nomosoft Scene Profiler, and it works like this:

1) Attach Nomosoft Scene Profiler to a scene in your game.
2) Customize the font, font color, and x/y coordinates where you would like the profiling information to be drawn.
3) Inside the behavior(s) you want to profile, drag in the "Start Profiler" custom block from under "Nomosoft Scene Profiler" on the "Custom" palette. Give the profile a name by filling in the text box on the "Start Profiler" block.
4) Drag the "Stop Profiler" custom block into the bahvior and place it in front of any exit point(s) in your behavior. See the attached screenshot for an example. Make sure to use the same name you did when you started the profiler.

You can use more than one profiler per behavior. So, if you want to profile the entire behavior, you might put "Start Profiler [My Behavior]" and "Stop Profiler [My Behavior]" at the very top and bottom of your behavior's update/draw/whatever function. If you want to profile a sub-section of the function, start another profiler, such as "Start Profiler [My Behavior Targeting Loop]." Remember to Stop Profiler, as well, or you will not get accurate numbers.

Profiling data is displayed on screen in this format:
[Name of profile]: [total milliseconds used] [[average milliseconds per call]]
As of right now, no effort is made to adjust the layout to fit everything on the screen. If you profile too many things at once, they will run off the bottom of your game's window.

Please note, in the screenshot, below, I could have simply started the profiler after the "if active" check, but I wanted to demonstrate how you should stop the profiler before any exit point in your behavior.

Game Art / Look upon my mushrooms, ye mighty, and despair.
« on: April 28, 2012, 09:53:48 pm »
I am the world's worst visual artist. No, I mean it. Every once in a while, I get it in my head to take another shot at making my own graphics. This always ends in failure, but I keep coming back to the well.

This time, I'm fooling around with Inkscape. I would appreciate any critiques and/or advice about the mushroom PNGs I've attached to this post. What should I be doing differently to make my mushrooms more attractive? What do you think of my color selections? Is one mushroom superior to the other? Am I on the right track, here?


Ask a Question / Are recycled actors supposed to be alive?
« on: April 13, 2012, 03:57:10 pm »
I've seen this brought up, before, but I am not sure if it was considered a bug or not. When I recycle an actor, "if [recycled actor] is alive" keeps reporting true, while reporting bizarre values for its x and y locations. This seems like a bug to me, but since it's still around in 2.0, maybe it's intentional, so I figured I'd ask here before reporting it as a bug.

I have a behavior called "Gun," which accepts a few parameters, including an actor type to use as ammunition. Every X seconds, the gun spawns an ammunition actor and sends it on its way. Great, except that I want multiple guns on my Player actor, and I don't want to do something silly like make ten copies of my gun behavior and call them Gun1 through Gun10.

So, I thought it would be good to have the gun store a list of all the types of ammo that it can fire, and each frame it checks each piece of ammo to find out whether that piece of ammo should be fired (checks the time since the last piece of that type was fired, checks whether a target is in range, etc.) Imagine the Gun behavior having a list with Bullet, Laser Beam, Missile, Grenade, etc.

I want to build all of the relevant information (delay between firings, time last fired, range, etc) into the actor. That way, the gun simply checks each actor type in its list, gets the information from the actor, then either spawns or doesn't spawn the ammo actor. I do _not_ want to have to hard-code each possible kind of ammo into the Gun behavior, I want to simple have every ammo actor share a behavior, such as "Ammo Stats" that the gun can read. That way, I can simply create a new ammo actor type, fill in the necessary information, and add it to the Gun's list, and the Gun itself does not need to be modified for each new piece of ammo I add.

Still with me? OK, here's the problem: the only way for me to do this seems to be if I create an actor of every type from the ammo list and have them exist somewhere in the scene at all times. Otherwise, I can't read from the "Ammo Stats" behavior because, if there is no actor, there is no behavior. Is there any way to do what I've described without having a bunch of invisible ammunition actors hiding in every scene?

Ask a Question / Two questions about slopes
« on: March 22, 2012, 11:56:02 am »
I am working on a platformer that involves sloped terrain. Instead of rolling my own, I'm using the slope detection behavior from the Run-n-Jump kit. I have a couple of questions I'm hoping someone can help me with.

1) What is the "slope grade" reported by the slope detection code? A 45 degree incline should be a 100% grade, but when my actor hits a 45 degree slope, the "slope grade" is reported as 29.xxxx.
2) I want my actor to elegantly rotate to match the slope he is on. I'm wondering which of several options my fellow Stenylers think is best.
2a) One option is to use multiple collision boxes at the bottom of my actor (which is a vehicle, not a humanoid character), and when the first box hits, rotate a certain percentage of the slope, when the second box hits, rotate a little more, and so on.
2b) The other option I am considering is turning on rotation in physics (currently, the actor cannot rotate in the physics engine), but limiting it to +/- X degrees of rotation. Then, of course, I need to make sure he only rotates when entering or leaving a slope, and not when bumping into things in mid-air, or when ramming a wall. Another problem with this approach is that my actor seems to want to rotate FORWARD when the bottom of his collision box hits a slope, like he's tipping forward from momentum. I don't know how well I can counter this by changing the shape of his collision box.

I'm open to suggestions. I usually do my own crude physics with platformers, but I would really like to use the built-in Box2D functionality, this time around.

Ask a Question / BigFish wants to publish my game, BUT...
« on: December 18, 2011, 11:50:14 am »
... one of their requirements is that I "Disable the Adobe Flash right-click context menu." I've been all over the internet, and these forums, looking for the solution. Mostly, what I find is "stage.showDefaultContextMenu = false," which I finally figured out needs to be "FlxG._game.stage.showDefaultContextMenu=false," but which doesn't seem to do anything, at all. Anyway, that apparently only hides some of the menu items. The other solution I see looks something like this:

var newMenu:ContextMenu = new ContextMenu();
newMenu.hideBuiltInItems(); = newMenu;

However, Flash chokes on "ContextMenu." I have no idea what package or library ContextMenu is part of, or how to import it into a StencylWorks project, even if I did. I see this question has been asked once or twice, but there doesn't seem to have been any real solution discovered. Can I disable the right-click menu in code, or not?

Old Bugs (1.x/2.x) / Behavior confusion error
« on: December 13, 2011, 12:14:09 am »
If you delete a behavior, then create a new one, some wires seem to get crossed in StencylWorks.

Let's say "Behavior A" is attached to the actor "Player." Now, in the "Logic" tree, delete Behavior A. Reload the project (CTRL-R, not close/open), and you'll see that Behavior A has disappeared from Player's behavior page. Now, create "Behavior B" and attach it to another actor, "Enemy." Reload the project. You will see that Behavior A has reappeared on Player's behavior list. Behavior B is on Enemy's page, just as you'd expect. If you try to edit Behavior A, it will open Behavior B. If you close the game and re-open the project, "Behavior A" will have turned into "Behavior B" on Player's behavior page.

So, it seems that deleting a behavior, then creating a new one, causes the new behavior to occupy the same space in the project as the behavior you deleted. For the most part, this just causes Player to execute Behavior B, but I first stumbled onto this because I was getting an error about Type Coercion failing, and something having to do with when I tried to test my project. I am not 100% sure, but I think the type coercion problem might come from deleting a scene behavior, then creating a player behavior (or vice-versa), because you then end up with a behavior attached to the wrong type of object.

Ask a Question / Ballistics maths / targeting
« on: December 09, 2011, 02:25:02 am »
I want to plot a projectile's path from A to B. This is to be used for AI actors to aim and fire at targets. The thing is, I don't understand the units used in gravity or linear damping. Obviously, I need to take both of these into account but are they pixels per frame/second/update, or some other measurement, entirely? Also, Flash seems to choke on any semi-serious math repeated in behaviors. Finally, there will (normally) be multiple viable paths for the projectile to take, so is it best to start with a launch velocity and calculate the curve from that?

If anyone can provide a working example of this type of targeting, I would really appreciate it.

Ask a Question / Big performance hit for seemingly simple operation(s)
« on: December 02, 2011, 01:41:22 pm »
I have an actor with a single behavior. That behavior consists of a single command, which rotates the actor X degrees per call. Using either "point toward" or "turn by x," I see a drop of 12-20 fps with fifteen or sixteen of these actors on screen. Disabling the behavior or deactivating the rotation command (which is the only command in the behavior) is the difference between 26ish fps and 42+ fps. The time seems to mostly be lost to "update."

Right now, I am working around this problem by putting the rotation on a timer, but I still feel this is a lot of hit for a single command. Am I missing some trick, here? The actor in question needs to detect collisions, but other than that and the rotation, no physics need be applied.

Pages: 1 2