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 - Hectate

Pages: 1 2 3 4 5
Ludum Dare 28 / Join us in chat! (Ludum Dare)
« on: December 13, 2013, 05:43:41 pm »
I can't speak for anyone else, but I'm going to try and hang out in the Stencyl IRC chatroom during my active time this weekend. Feel free to join us. Don't be afraid to ask for help, but remember that we're probably all working on our games as well so be patient (plus you'd get more eyes on it faster if you just posted in the forums instead). See you soon!

If you don't have an IRC client, just jump on the one provided here:

Chit-Chat / Article - Android device statistics
« on: June 29, 2013, 07:20:20 am »
Here is an interesting and insightful look into the adoption and usage of Android devices by a major mobile game maker's users. It's rare to get information like this out in the public so it's definitely worth reviewing.
Using data to successfully build for the Android market (Alex Rosen's blog on Gamasutra)

Chit-Chat / Amit Patel's amazing collection of information
« on: May 21, 2013, 12:56:59 pm »
If you have never seen it, you must spend some time there.

He has been collecting links for and commenting on game development for many years now and the information available through his site is an incredible resource.

Stencyl Jam 12 / StencylJam 2013 numbers
« on: May 01, 2013, 07:59:29 am »
Here's a few fun facts about the StencylJam.

2 games were announced but not completed.
88 qualifying games have been submitted for the StencylJam.
11 of those entries were for the special Mobile prize also.
71 users submitted 1 game, 7 users submitted 2 games, and 1 user submitted 3 games.
7 of the entries were LD48 games started and finished only this past weekend, only 1 of the LD48 games was a user's second entry to the StencylJam.

Game Art / Creating and Importing artwork with transparency
« on: March 10, 2013, 02:16:26 pm »
I've noticed that there are frequent questions about importing images, or people complaining that their artwork has the "white border". This post is a quick lesson on what and why this happens.

Here's an image that I created in Inkscape. Notice that the edges are nice and clean. The reason for this is that Inkscape exports with a transparent image to begin with. As a result, I can save it as a PNG and import the image directly into Stencyl with it's existing transparency. You can do this in GIMP by creating a new image and selecting "transparent background". Creating a new layer would give you this option as well, but you'd have to be sure to not export other layers that might not also be transparent.

By comparison, here is a version of it that did NOT have the white background removed (technically, I had to add it afterward). Now visually it's perfectly fine here in the forums, but the anti-aliasing (where edges between colors are blended together so that they appear smooth even at an angle) is going to be a problem. Using this image, however, we can select the color white to mask it out and make the background transparent.

Let's load these images into Stencyl and see the results. The first is loaded as-is while the second had white selected as the masking color.

So here we see the issue. By selecting the white color to be transparent, there are many pixels of anti-aliasing where they appear to be white but technically they are slightly off-white instead. The result is that only exactly white pixels get turned transparent and meanwhile you get a terrible looking sprite.
And yes, there's the one other issue: the eyes were white also and as a result they got turned transparent. The same thing could happen to parts of your images if you select a masking color that you also happen to be using elsewhere in your sprite. That's why many sprite-sheets use a hot pink or bright green for the background color - it can be removed easily (for pixel art anyway) and it's unlikely to be used in the actual sprite.

So, the rule of thumb is to draw your art with transparency from the beginning. I hope these examples help!

Windows / Mac / Flash / HTML5 / Blistered Dirt (tech demo)
« on: January 31, 2013, 11:29:44 pm »
I've been messing around with the Tile API, simple physics, and some homespun ballistic physics. The result is "Blistered Dirt", a throwback to the classic artillery game Scorched Earth.

Right now there are no enemies or other players to target. This is simple a bare-bones "proof of concept" demo/prototype. There are a few bugs with the terrain destruction but it's coming together. You may have already viewed this game - previously it was showing a scene where I was working on terrain generation. The current scene contains tiles placed via scene designer, soon I'll connect the terrain generation to the rest of the gameplay as well.

Bundled Behaviors / (New) Grid-Based Motion [captaincomic?]
« on: January 09, 2013, 09:57:21 am »
I noticed that Grid-Based Motion is listed in "The Master List" as being open but with captaincomic's name at the header of the section, and then in the pre-shipped behaviors for 3.0 thread as being directly attributed to him again. I'm willing to work on this if it's still needed and actually open. It's been several months since either thread were updated so I wanted to check first.

I also noticed that the "Snap To Grid" was needed and I could throw that together as well if also needed.

If I work on this, here's the basic functionality/needs as I understand them. If I've missed anything just point it out - I'll be coming back here to reference these notes if I work on this...

Required Features
1. Is an Actor Behavior
2. When enabled, locks the actor's position to a square grid cell.
3. The position of the actor within/around the cell can be customized with X,Y offset attributes (centering the actor is the default location, and then -/+ offsets).
4. The square grid itself can be customized for width and height of the cells, with the current scene's tile size as a default option.
5. The behavior will accept inputs to permit motion of the actor between cells.
  a. The user will be able to permit or disallow diagonal motion, or other specific directions (in chess, pawns only move in one direction, for example).
  b. Keyboard controls will be configurable for movement to all valid adjacent cells, or continuous motion if held down (if movement is instant, a configurable timer will be needed for this).
  c. The behavior will also accept messages from other behaviors to initiate the motion (so a separate touch or mouse-based behavior could send commands for motion, for example)
  d. The behavior will also accept a message to send the actor directly to a specific, non-adjacent cell (for teleportation or other long-distance moves). Custom Block required?
6. Motion between cells can be configured with a speed, or be instantaneous.
7. If a collision occurs, the actor should return to the nearest cell and stop.

Additional features
7. The behavior could broadcast a message (for other behaviors to receive) every time a move is made. Roguelikes could use this to initiate monster movement (as nothing happens in a roguelike until the player acts). Other uses could be to decrement a "Moves Available" counter, trigger special effects, etc.
8. Select a sound effect for use during motion or when a move is made.

Completed / Renaming events should be in the context menu.
« on: January 05, 2013, 01:25:38 am »
I made a copy of a collision event in a behavior I'm working on and I noticed that it renamed itself to "Copy of..." and didn't like that name. Normally I don't worry much about them but I was going to have several of these collision events between different actor types and wanted to specify each one in the list separately. My first action was to right click the event name and select Rename from the right-click context menu; it wasn't there. My initial reaction was that I thought it odd that you couldn't rename the events, but since the names were just names I figured I could work around it. A few moments later I double-clicked the name and it highlighted itself ready for text editing; surprise!

Anyway, I suggest that the right-click context menu for event names should include a "Rename Event" option. I was not able to locate any other instance of a rename event option existing within Design Mode.

Archives / Preview Frame/Animation for Actors in Scene Designer
« on: August 18, 2012, 10:43:24 pm »
Just a thought that I hadn't seen any other mentions of but seems to crop up as a useful feature for my games...

The ability to select a specific animation or frame to display in the scene designer in place of the default animation.

While the default animation choice is handy in most circumstances, there are times where it is inappropriate or troublesome to use when placing actors in the Scene Designer. Specifically, it is not unusual for me to have actors that are, by default, 100% transparent or visually similar to tiles or other graphical elements. Examples of actors like this include spawners, destructible "tiles", waypoints, etc.

Since it becomes difficult to work with invisible or camouflaged actors in the Scene Designer, the designer has to set the default animation to a different, easily identifiable animation. Thus, the actors have to have a behavior to immediately switch to the "true default" animation when the game first creates them.

I propose that the current system of the default frame be maintained as the standard behavior, which will be sufficient for most actors and won't change anything for existing games.

However, the user should be able to override this choice by selecting specific frame (of any animation of the actor - not just the default animation) to be used as the image for that actor when in the Scene Designer. The default animation would still exist and be used by the game as usual.

Ideally, the user would be able to select either a specific frame or an entire animation as this Scene Designer "preview" image. If an animation were selected, it would continuously loop in the Scene Designer.

So I'm working on my game for NaGaDeMo and I'm curious as to what a wider group of people think of my current conundrum.

I am making a strategy game and, essentially, I'm curious as to what level of color-blindness-friendly design I should incorporate (so if you are colorblind to some degree, I'm particularly interested in your opinion). The issue I have is that the players will have functionally identical units and players need to be able to easily distinguish, visually, between their units and the enemies units. Here are some options that I've thought up:

1. Ignore colorblindness and use the same units with different colors to designate players.

2. Tooltip/pop-up text on mouse-over for individual units.

3. A toggle that overlays icons or text for all units.

4. Design similar units with distinctive shapes between players to differentiate ownership.

Personally I'm leaning toward the last one. It's both visually appealing and functional while avoiding screen clutter. It does require more work on the art asset side, but I feel like it would be worth it. Additionally, the other options can be combined with it. Note that I only plan on having two players initially, so the additional artwork may not be as important for such a low number of variances?


Archives / "Tile-Size mis-match" warning in Scene Designer
« on: January 23, 2012, 04:12:10 am »
In providing support, we regularly notice that it seems easy to overlook the fact that tile sizes need to match the scene settings for them to work properly. The problem is made worse by the fact that the Scene Designer will draw the tiles in a way that makes them appear correct regardless.

I propose a warning system to help draw attention to this fact. We certainly don't want to lose the ability to use multiple tilesets in a single game just because they're different sizes (different scenes have different needs). However, a few additions to StencylWorks might not be amiss.

1. Within Game Settings (and when creating a new game and setting resolution), permit users to assign a "Default Tile Size" that is used when creating new scenes. This is nothing more than a default value that is configurable at a game-setting level to replace the default 32x32.

2. If the user, working within Scene Designer, selects a tileset that does not match the current tile size of the scene settings, pop up a warning dialog box that indicates that the two do not match. Include a check-box to disable future warnings.

3. Add a small icon to the application chrome somewhere (bottom toolbar?) that displays if any tilesets are in use that do not match the scene's settings.

Ask a Question / MOVED: Spawn System Trouble
« on: January 15, 2012, 12:47:03 pm »

Archives / Import/Export scenes similarly to behaviors
« on: January 09, 2012, 09:58:28 am »
I keep noticing requests for the ability to collaborate between users on scene creation. It occurred to me that perhaps the same concept of using .PNG files + meta data could work on Scenes as well? Obviously they're a little more complicated, but the core idea is the same. To any developer with the knowledge, is this feasible?

Ask a Question / Collision groups don't match in XML?
« on: January 01, 2012, 10:24:32 am »
So I had a working powerup. The player actor had a behavior that altered his state when he collided with it, and the powerup had a behavior that altered it's state (temporarily unavailable) when it sensed a collision with the player. All was good.

Today I went ahead and upgraded, did some work, added other features (which required additional collision groups), and then noticed my powerups had stopped functioning. Some testing reveals that...
1. The Player does not sense the collision with the powerup.
2. The powerup DOES sense the collision with the player.
3. My collision groups are set up so that either group should detect the other.
4. My actors are set up in those appropriate groups.

Obviously the situation here is with either 1. The Player's collision group settings or 2. The behavior's handling of the collision. However, with everything visible set correctly, I decided to dig further into the XML thinking that either the upgrade or my collision settings editing had messed something up that wasn't being reflected in SW.

Game.XML shows the following collision group...
Code: [Select]
<group desc="" id="5" name="Powerups"/>
while my behavior has the following code...
Code: [Select]
<if comment="false" x="26" y="1113">
                    <group eventID="-1" id="-1">
                        <print comment="false" x="37" y="1151">
                            <int id="0" val="Powerup!"/>
                        <set-val-0-8 comment="false" x="37" y="1171">
                            <int id="0" val="1"/>
                    <eq comment="false" id="0" x="0" y="0">
                        <collision-shape-group comment="false" id="0" x="0" y="0"/>
                        <pick-group comment="false" id="1" x="0" y="0">
                            <int id="0" val="5"/>
or preview mode...
Code: [Select]
if (sameAs(scene.getGroup(event.otherShape.groupID, (event.otherShape.GetBody().GetUserData() as Actor)), getActorGroup(5)))
        print("" + "Powerup!");
        _JumpState = 1;

So my powerup group is ID 5, but there's only 1 "5" in the XML, is it in the right place?

Chit-Chat / Do It Yourself and save the difference!
« on: December 29, 2011, 04:04:22 am »
So, being the independently minded types we are here, I'm sure that many of us like the DIY philosophy of tearing things up and putting them back together - and saving money in the process! Feel free to post a story or comment yourself. Here's mine.

Christmas Day my wife dropped her HTC EVO 4G phone and fractured the glass face (see attached image). Interestingly, the phone still functioned completely, even detecting touches. That said, obviously having broken glass in contact with your fingers is not ideal, so it needed to be fixed. A few google searches and some youtube videos later, a solution was known! The digitizer (the glass, touch sensitive face of the phone) could be replaced with a small amount of careful work.

Amazon had several merchants listed for the necessary part and I picked one that shipped from Amazon's warehouse (because there is one here in town). I got it with free one-day shipping somehow too, it never charged, so it got here quickly.

I won't bore you with the details, but a little bit (2 hours) of repair, cleaning, and parts replacement and now it's good as new! The best part is how much I saved!

Since she isn't eligible for an upgrade discount, a new phone would have cost about $300. A used one in good condition would still have been $150 to $200 I'm sure. As an alternative comparison, insurance (which we skipped on this phone) would have had a $50 deductible, plus the $84 in monthly premiums ($7 for 12 months) up to that point, to have it repaired or replaced (with a refurbished one) by Sprint.

My cost for the parts was...
Digitizer (New) - $15
Adhesive - $3 (high-end double-sided tape, and I have a lot left over for other uses later)

I also purchased some tools which will now go into my kit for future use as well...
Precision screwdrivers - $11 (I needed very tiny Torx and Phillips bits)

I also had a few other tools (razor, plastic pry-tool, latex gloves, canned air, etc) which cost nothing more.

So total cost for the repair, even if I never used any of the screwdrivers again, was only $29. Compared to $134 for phone insurance, or $200-$300 for a replacement device, I feel pretty good about being the kind of guy willing to tear apart a phone to save some money. Now I just need to convince my wife to give me the difference of $271 - maybe I'll bill her for the labor. She did drop it, after all.  ;D

Pages: 1 2 3 4 5