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.

Messages - Epic428

Pages: 1 ... 3 4 5 6 7 ... 62
Unfortunately the size cannot be changed just by dragging. To delete, select the shape and then press the delete key.

I'm not sure how, between the Stencylpedia and Block Docs, you weren't able to understand the API. Anyway, your best bet is to predetermine the names of all Stats you will submit. Then, create a behavior that initializes the Kongregate scores. Place this behavior in the very first scene of your game.

When you have that completed, at each point in the game where the scores should be submitted, place the submit score blocks, type the appropriate name, and add the appropriate attribute block that should be submitted.

Ask a Question / Re: Format of data saved
« on: August 19, 2011, 06:13:39 pm »

File locations

The default storage location for Local Shared Objects is operating system-dependent.

On Microsoft Windows NT 5.x, they are stored in:[13]

     %APPDATA%\Macromedia\Flash Player\#SharedObjects\
     %APPDATA%\Macromedia\Flash Player\\support\flashplayer\sys\

On Microsoft Windows NT 6.x, they are stored in:[13]

     %APPDATA%\Macromedia\Flash Player\#SharedObjects\
     %APPDATA%\Macromedia\Flash Player\\support\flashplayer\sys\

On Mac OS X, they are stored in:

    ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects/
    ~/Library/Preferences/Macromedia/Flash Player/

On Linux or Unix, they are stored in:


Look into a Shared Object Editor to see what the saved data looks like. This will help you determine if the saves can be easily modified. I'm sure there are ways to determine if saves had been modified as I know Kongregate has a way of "disciplining" users for modifying saves and cheating. I'm just not sure how they are able to detect if a save has been modified. My guess is that a duplicate save is made elsewhere, such as server side (likely using some javascript) and then the files are compared.

I'll admit, though, for fun I have used a shared object editor to modify a save for a game on Kong and it bared no effect on the game. This is why I assume there is some additional save elsewhere, because after modifying and loading the game, my changed value did not appear in game. Then, upon inspection of the shared object a second time, I discovered the value had been reset. Though, it could have also been due to a faulty editor.

Chit-Chat / Re: My games have been Stolen!
« on: August 18, 2011, 07:28:48 pm »
We are working on Mochi implementation. It will be available in the free version because it is Flash. As to when it will be available, most likely in 1.2 as there are more pressing issues to be worked on. iStencyl will have its own ad system in place.

Chit-Chat / Re: My games have been Stolen!
« on: August 17, 2011, 08:03:51 pm »
To play devils advocate to Sitelocking and Obfuscating your games, the stealing of these works could actually be beneficial for the games creator. The idea behind making these games, at least for those who are monetarily driven, is to get the game out to as many people as possible and get as many plays as possible, hence, virility.

For those who are monetarily driven, having the game go viral, because it was stolen, would be an excellent opportunity if they had an Ad system built into the game, or if they had a Sponsor who did not require them to keep the game exclusive to their site only. The Ad systems would help generate revenue, and having the Sponsor link, or your own link, back to where the game should be hosted would help generate traffic, and could also generate more revenue.

As Jon pointed out "Robichai" had approximately 20x the plays on a site which stole the game than it did on one of the largest game portals. If the game incorporated some sort of Ad system like Mochi-Ads, then it is likely the creator would have seen some revenue from the game, and just as likely to see the same, if not more, revenue than it did on Kongregate.

Due to the nature of people, the internet, and programming, the stealing of games like these is never going to stop. So precautionary steps like Sitelocking and Obfuscating are good enough to prevent about 99% of thefts, but utilizing the thefts as a way to generate your own revenue with some smart decisions would, in my opinion, be the better choice. I figure, if someone is going to put forth the effort to hand pick the games, or write a spider to obtain them, then why not take advantage and gain something out of it.

Ask a Question / Re: things from StencylForge won't download
« on: August 16, 2011, 07:38:43 pm »
my suggestion: Post your logs here so someone can look at them for any errors. Debug > Generate Logs

Archives / Re: On screen controls kit
« on: August 16, 2011, 07:37:06 pm »
To the best of my knowledge this functionality is being implemented into iStencyl. Whether there are plans to carry it over into Flash, I'm not sure.

To be perfectly honest though, it isn't all that hard to code it for Flash-based games. You basically need an actor that acts as a button, you then need a behavior which basically targets an actor in the scene (most likely the player) and when the button is pressed or held, force the target actor to perform the requested action.

Ask a Question / Re: How to Create Custom Pause Screen [ADVANCED]
« on: August 15, 2011, 08:03:26 pm »
The default pause screen has no functionality. What you see there is actually text and images displaying what the hot keys are.

However, if you really want to add functionality to the pause menu, you will need to add a lot more code. Ultimately, you will need to create event listeners for Mouse events. These Mouse Event Listeners will listen for "Mouse Down", "Mouse Hover", etc. Then you would react based off what conditions are met.

Again, though, the problem with going the route of these custom pause screens is that everything about the pause screen is detached from the actual game. This means there is no physics, there are no Actors, there are no SW managed Sounds, etc. This is a ton of functionality that is lost and ultimately affects how the game is designed (It goes against the very reason Stencyl was created).

Down the road, I plan to look into ways that the custom pause screen can be integrated in the same manner that every scene, etc is created. There are several options that can be taken here:

The first option is to look into how the class would behave if Stencyl related classes were imported.

The second option is to look into scaling the inheritance hierarchy for public methods/variables which will enable me to save the current state of a scene exactly as it is, at the very moment in which the game is paused, and then switch to a new scene which would be a Pause/Menu hybrid, and then return to the scene as if it had never been interrupted.

The final option is to look into how the Flixel classes used for a pause screen can be modified so that a behavior can create and implement the pause screen yet remain interactive with the rest of the environment.

Unfortunately, I find myself torn on the Custom Pause Screen issue. The reason I find myself torn on the issue is because not every platform will use the Flixel engine. This means that projects such as iOS development, will see an entirely different way of pausing a game. The next reason I am torn on the issue is because there are so many different ways a pause screen can be implemented into a game, it seems to make much more sense for the developer to roll out their own behaviors for creating pause screens (Not always will a game simply display a dialog saying "Paused", some games will prefer to overlay a miniature menu, while others may prefer to open a much more full blown menu system, such as inventory, options, etc.) The menu options is where the pause screen creation gets more difficult considering it could simply be the addition of a few new actors, or it could be a switch to an entirely new scene.

One option I began to work on a little while back and would love to revisit again is a behavior that allows the creation for "Actor Groups". I don't mean groups in the same sense as collision groups, but more so in the sense that a predefined list of actors and their coordinates are added to the scene at the same time, and then removed at the same time.

For example, in ASLoF (aka Don't Croak) the menu bar in each level is actually made up of several actors. One actor is the background, while others are the buttons. Having a behavior create these actors as a group, then remove them, would make life a lot easier.

One of my biggest hurdles in terms of this type of behavior is that I wanted the behavior to be global across the entire game so it is only needed once. The behavior would manage the list of groups, then the list of items/commands inside each group, then it would manage the creation of the groups, deletion of the groups, and even feature custom blocks to add and remove from the groups.

Because of how much functionality would exist, and the complexity of the behavior, the current format for behavior/instance customization makes this difficult to present in a user friendly format for game developers. This is primarily to do with the need for nested lists, which I suppose could be somewhat solved by splitting the behavior up into at least two, a Non-Customizable Manager and a Customizable utility behavior which is where the group members are specified. Though the issue of having multiple groups remains in the sense that the behavior would likely need to be duped and renamed so that it is group relevant.

Resolved Questions / Re: API Confusion??
« on: August 15, 2011, 06:40:45 pm »
All of this is answered for you if you actually read the page on Kongregates website.

To satisfy your question, however, when publishing a game on Kong's website, you are provided with the option to integrate their high scores. When implementing their high scores, you give each "score" a name. For example, you could have a score called "Number of Moves".

Whatever NAME you give the score when setting up a game on Kong's website, you must use that exact same name for stat submission. This allows the Kong API to know what value is changed so that it may be reflected appropriately.

Windows / Mac / Flash / HTML5 / Re: A Second Leap of Faith!
« on: August 07, 2011, 07:26:37 pm »
In the next day or two we will be updating the game. I just need to fix a problem on my end where I can't update the game with what I have.

We have 62 levels made so far not including the 3 levels KungfuFurby created. I am leaving his levels out of the update for now because I need to fix some lag caused by them. They may be some of the best levels in the game so the very moment they are released you can look forward to playing them.

When the update comes out, we have a huge request we'd like the community to fulfill, please keep an eye out for further details. Thanks!

ehaviors would you recommend to account for my situation (>1 type of weapon and create two players)?

It sounds to me like you are planning on having more than 1 weapon for single player? Or are you planning on having multiple players with the same weapon?

In the first case, it would be best to have the player use a Weapon Manager behavior. Then each actual weapon gets it's own behavior defining what the weapon does and how it works.

In the second case, you would just need to attach the same behavior to multiple actors.

Let me know if you are looking for more information.

Chit-Chat / Re: What music do you like?
« on: August 07, 2011, 09:03:22 am »
Locking to prevent duplicate thread.

Sensors detect collisions. They just don't use physics to act upon those collisions.

Oh. well boo.. Curious though. I wonder if there is a way I can go up in the parent hierarchy to actually accomplish something of this nature.

If I can find a way to actually save out whatever AS3 variable contains the scene, (perhaps a Flixel PlayState) then maybe there is a way to re-invoke that scene. The only issue I could think of is if there are certain options in a menu that would affect values in the scene. Though, if there was a system in place to do this, then that'd be even better.

Curious. Does this save all details of the scene at that given moment?

For example, I can see this being extremely useful in terms of creating a menu system that can be utilized in game without actually saving each and every detail of the scene to a separate attribute.

If it truly does work this way then that is extremely amazing and I would consider making a behavior to specifically do this and share it on forge.

Pages: 1 ... 3 4 5 6 7 ... 62