Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

simulatoralive

17
Posts
4
Topics
7
Followers
10
Following
A member registered May 30, 2016 · View creator page →

Creator of

Recent community posts

Oh yeah, I failed to mentiion that this update now includes an option to run it in a borderless fullscreen mode, byt simply removing the borders and then maximizing.

It didn't display over my taskbar under linux, but that was no surprise to me.  It is less buggy and more reliable than real fullscreen mode under Linux, though.

Now that I've sat down to actually begin work on using this technique with fluids, I've hit another nasty wall: the current algorithm for fluid motion is incredibly dependent on the specific order it's done in for correct, consistent behavior.

This means that doing this in parallel without redesigning the algorithm will result in bizarre fluid movements happening whenever two different threads work in close proximity.

The only way I can think of to get around this problem is to detect whether or not bodies of fluid are connected or not and then assign threads to work on each isolated body of water.  The problem with this approach is that it doesn't help at all with one massive body of fluid in motion, along the lines of an ocean.

*Sigh* Looks like parallel block physics is on the back burner again.  At least the Tumbler got something nice out of this.

I recently found out that this forum also mishandles  XML when it's in code blocks, as well.  I posted a code block with XML in it to another thread yesterday.  In that case, it took XML tags that were NOT composed of starting and ending tags and pointlessly expanded it into start and end tags.

Again, I say, things inside code blocks shouldn't be modified.  That's the entire point of code blocks.

My tests have convinced me that this is a bug in Butler and a very subtle one, at that.  That's why I wanted the developer that wrote it to see my posts.

(1 edit)

It's in the build file.  I just failed to copy it to my post.  That is NOT the problem.

The channel is "simulatoralive/bigblockengine:win-linux-osx-Alpha".  That should have been on the end of the command string you requested.

As stated in my first post, my build script worked just fine under Windows 7, with the --if-changed switch still in place.  Under Linux, it does NOT work, because butler chokes and dies on an empty directory.  Please, could someone look at fixing this bug?  Additionally, I would appreciate it if the --dry-run switch were modified to actually do the complete file comparisons.  It does not currently do this.

I would have made a bug report through butler's github page, save for the fact that I flat out refuse to ever use github so long as Microsoft is the owner.  I posted here as an alternative.

Dark Dimension, before you continue to nit-pick at what I'm saying here on this forum, look at my build script; I'm posting a copy in a code block at the end of this post (this is not the complete version and has everything stripped out of it except the variables and the publish targets; if you insist on seeing the complete version go download the source archive for my game and look for the file "bigblockengine/build.xml" in that archive).  This Ant build script is what actually does the job.  The publish targets are at the very end.  The variables are all clearly laid out at the beginning (each is a "property" XML tag, which for some unknown reason the forum has expended into start and finish tags; not how it should be, but whatever, the forum software is a control freak about code blocks) and are all surrounded by curly braces, preceded by a dollar sign, in any text where they get substituted in.  The build target you'd want to look at specifically is publish-test.  It's using a different channel, but that's a hidden channel I setup to further test this bug.

In Ant scripts, the "exec" task calls another program, in this case, butler, then add's the "line" attributes from any nested "arg" tags on as the parameters, after it has parsed variables out of them.

As you can see, the ONLY differences between the "publish" and "publish-test" targets is the --if-changed switch and the channel.  The one with --if-changed, which is the old way I was doing things, chokes and dies.

To make myself very plain, I posted here to get the developer's attention.  I believe that would be Amos, yes?  May I please have his attention on this?

<project name="bigblockengine" default="jar" basedir=".">
  <!-- set global properties for this build -->
  <property name="name" value="${ant.project.name}"></property>
  <property name="name-verbose" value="Big Block Engine"></property>
  <property name="ver-major" value="0"></property>
  <property name="ver-minor" value="23"></property>
  <property name="ver-bug" value="2"></property>
  <property name="ver-flag" value="Alpha"></property>
  <property name="version" value="${ver-major}.${ver-minor}.${ver-bug} ${ver-flag}"></property>
  <property name="version2" value="${ver-major}.${ver-minor}.${ver-bug}-${ver-flag}"></property>
  <property name="main-class" value="net.sf.simulatoralive.blockgame.GameLoader"></property>
  <property name="doc-packages" value="*"></property>
  <property name="doc-title" value="${name-verbose} ${version}"></property>
  <property name="source-version" value="1.8"></property>
  <property name="target-version" value="1.8"></property>
  <!-- Files/directories for this build -->
  <property name="doc-root" location="doc"></property>
  <property name="doc" location="${doc-root}/${name}"></property>
  <property name="src-root" location="src"></property>
  <property name="src" location="${src-root}/${name}"></property>
  <property name="src-bootstrap" location="${src-root}/bootstrap"></property>
  <property name="bootstrap-zip" location="mods-zip/bootstrap.game.zip"></property>
  <property name="temp-dir" location="classes"></property>
  <property name="build" location="${temp-dir}/${name}"></property>
  <property name="dist" location="."></property>
  <property name="dist-jar" location="${dist}/${name}.jar"></property>
  <property name="dist-tar" location="${name}-${version2}.tar.bz2"></property>
  <property name="dist-tar-bin" location="${name}-${version2}-bin.tar.bz2"></property>
  <property name="dist-zip-bin" location="${name}-${version2}-bin.zip"></property>
  <property name="dist-tar-src" location="${name}-${version2}-src.tar.bz2"></property>
  <property name="dist-zip-src" location="${name}-${version2}-src.zip"></property>
  <!-- Classpath for compilation -->
  <property name="classpath" value="lib/hierarchy.jar;lib/jogl/jogl-all.jar;lib/jogl/gluegen-rt.jar;lib/substance.jar;lib/trident.jar;lib/svg-salamander.jar;lib/dyn4j.jar"></property>
  <!-- Jar file classpath is space separated -->
  <property name="jar-classpath" value="lib/hierarchy.jar lib/jogl/jogl-all.jar lib/jogl/gluegen-rt.jar lib/substance.jar lib/trident.jar lib/dyn4j.jar"></property>
  <property name="butler-bin-channel" value="simulatoralive/bigblockengine:win-linux-osx-${ver-flag}"></property>
  <property name="butler-src-channel" value="simulatoralive/bigblockengine:source"></property>
  <property name="butler-bin-channel-test" value="simulatoralive/bigblockengine:test-${ver-flag}"></property>
  <property name="butler-src-channel-test" value="simulatoralive/bigblockengine:test-source"></property>
  <property name="butler-switches" value="--userversion=${version2} --noprogress"></property>
  
  <target name="publish" depends="dist-bin,dist-src">
    <!-- Push the binary build using itch.io Butler command.
         Hopefully this is cross-platform enough to work. -->
    <echo message="Publishing binary build..." level="info"></echo>
    <exec executable="butler" failonerror="true">
      <arg line="push ${butler-switches} ${dist-zip-bin} ${butler-bin-channel}"></arg>
    </exec>
    <echo message="Binary build published." level="info"></echo>
    
    <!-- Push the sources using itch.io Butler command.
         Hopefully this is cross-platform enough to work. -->
    <echo message="Publishing sources..." level="info"></echo>
    <exec executable="butler" failonerror="true">
      <arg line="push ${butler-switches} ${dist-zip-src} ${butler-src-channel}"></arg>
    </exec>
    <echo message="Sources published." level="info"></echo>
  </target>
  
  <target name="publish-test" depends="dist-bin,dist-src">
    <!-- Push the binary build using itch.io Butler command.
         Hopefully this is cross-platform enough to work. -->
    <echo message="Publishing binary build..." level="info"></echo>
    <exec executable="butler" failonerror="true">
      <arg line="push --if-changed ${butler-switches} ${dist-zip-bin} ${butler-bin-channel-test}"></arg>
    </exec>
    <echo message="Binary build published." level="info"></echo>
    
    <!-- Push the sources using itch.io Butler command.
         Hopefully this is cross-platform enough to work. -->
    <echo message="Publishing sources..." level="info"></echo>
    <exec executable="butler" failonerror="true">
      <arg line="push --if-changed ${butler-switches} ${dist-zip-src} ${butler-src-channel-test}"></arg>
    </exec>
    <echo message="Sources published." level="info"></echo>
  </target>
  
</project>
(2 edits)

The complete path, as seen in my first post (this is all on the same line, regardless of how the browser may word-wrap):

/windows/Users/simulatoralive/Documents/Projects/Programming/simulatoralive/BlockGameEngine/bigblockengine-0.21.7-Alpha-bin.zip/bigblockengine/mods

You'll notice the small bit you quoted is only the very end of it.

Edit: The butler command is assembled from variables in my build script (which you can find in the source archive, by the way), but should have looked like this, for the release in question:

butler push --userversion=0.21.7-Alpha --if-changed --noprogress bigblockengine-0.21.7-Alpha-bin.zip

I'm also building a free game.  Mine gets regular views and when I'm actively working on it, a fair number of downloads each week.  What I did to accomplish this is fairly simple and would likely work for most anyone.

Back in 2016, before I even released the first alpha version, I started posting progress updates to Google+ with animated gifs recorded from my game, to serve as Eye Candy.  Google+ may be dead, but I managed to generate quite a bit of interest among friends and some random strangers that were interested in cellular automata (my game uses cellular automata-like algorithms for terrain changes and flowing liquid).  Oddly enough, a physics professor from India was very actively sharing my progress updates with his students.

I also put a link to my Google+ collection for my progress updates into my signature on a few forums I was busy on at the time.  This drove more traffic to them.

When I finally got around to making that first release, I immediately had at least 10-20 people actively interested and following the project on Itch, because I made an announcement on Google+ at the time.

Now that Google+ is dead, I've been using my game's dev log in a similar way.  At major milestones, I'll send a friend or two an e-mail linking to a good dev log entry.

I also spent a lot of time talking with people in person who were interested and wrote down the URL for them to check it out.  I've sometimes thought of making URL cards to hand out.  These would be similar to a business card, but with the URL for my game written on it, probably with a QR code for smart phone users to scan.

One thing I would like to point out is that for me, doing all of the above also keeps me interested.  I built my game engine practically from scratch (No, I do not suggest doing this, unless you really want to; personally, I enjoy tool building).  It's been a long road with a lot of hard bumps along the way.  Sharing those eye-popping animated gifs is one of the things that I really enjoy, because invariably, those posts tend to get triple the traffic and then lead to downloads.

Always remember: Eye Candy is your most important tool!  Words may draw a few, but a well-made animated gif will likely say a lot more in the first few instants than anything you write.  Some may see the animation, but will never read your words, so wow them right there!

So, to summarize:

  • Make eye-popping animated demos (Eye Candy)
    • Gifs work, video probably would as well, but I really suggest gifs for their immediate eye-catching nature
      • Gifs are particularly good on Itch, because they're animated by default
    • I cannot stress this one enough: Make stuff that looks awesome!
  • Post the Eye Candy on social media or a blog/dev log
    • Talk about what you're doing and why
    • Talk about the technical challenges, the algorithms you choose to use and why
    • Make it fun to read!
  • Post the Eye Candy along with links to the above and your game itself in a forum signature on as many online forums as you use
    • If you don't use forums, start using some forums
    • These are really useful for increasing views on any website/web page, because if search engines see your links all over the place, they think your website is a bigger thing than it may actually be
  • Talk about your game with people in person
    • Share the URL if they're interested

If you get nothing else from this post, always remember the importance of Eye Candy!

I recently made a new post to the dev log for my game.

Here's the post in question: https://simulatoralive.itch.io/bigblockengine/devlog/155808/the-shell-script-launcher-in-detail

If you'll look at the code block with my shell script in it, you'll notice that the editor automatically turned some URLs in the code into links.  I didn't want that and it actually badly interfered with me editing that log entry as each time I saved it, it went through and turned each URL in the code block into another link.  I found the bug after the third or fourth such edit of the draft of that log, so I had several concentric links messily shoved into that code block.

If a URL is found in a code block, it shouldn't automatically be turned into a link when it's saved.  If we're using code blocks, the editor should respect the fact that we don't want any automatic stuff happening to it.

This was particularly frustrating, because each time I've edited to fix a typo or add material, I had to go in and fix that line, copying the original version over all the unwanted HTML.

Just figured you should know about the bug.  Would love to see it fixed.

Thank you.

(1 edit)

My build script does the following:

  • Compiles my game
  • Packs everything required into a Zip archive
  • Publishes this archive to itch via the butler command

Because I prefer to save time and bandwidth, if possible, my script uses the --if-changed switch.  This worked well under Windows 7, last year when I was last actively working on this project.  This year, I'm running from Linux Mint and butler chokes and fails with the following output:

• Comparing against previous build...
checking for differences: lstat /windows/Users/simulatoralive/Documents/Projects/Programming/simulatoralive/BlockGameEngine/bigblockengine-0.21.7-Alpha-bin.zip/bigblockengine/mods: not a directory

I can assure you that the directory in question is definitely a directory.  It doesn't fail when I remove the --if-changed switch, which is what I'll be doing for the time being.  I even tried switching to an older version of butler matching the version I used under Windows and this did not work either.

I've had an irritating time testing and investigating this bug, because the --dry-run switch does not perform the file comparisons like one might expect it to when combined with --if-changed.  What I ended up doing was making a pair of hidden test channels to test publishing to, to investigate further.

This bug isn't too big of a deal, but it is a bit frustrating.  The main reason I was using the --if-changed switch is that most of the files in my game's archive are support libraries and their required libraries.  These don't normally change from one upload to the next and my changes are often quite small by comparison.  I would prefer not to have to wait for an upload of close to ten megs for a tiny, one-line code change for a bug fix.

This time and bandwidth savings is actually the reason I switched to using butler over manual uploads.

Thank you.

Edit: Here's a link to the game in question: https://simulatoralive.itch.io/bigblockengine

The file "bigblockengine-win-linux-osx-alpha.zip" is the one you'd want to look at if you want to analyze in detail what went wrong.

I finally got my slime fully working the way I wanted, both on the art side and the code side.  It jiggles when hit, stares at enemies in an aggressive way and jumps at them.

Here's a Slime I tricked into doing a circus act (the ball is a decoy prop that triggers it's attack behavior, without which it just sits there):


Here's the newest sprite sheet:


The slime is now published as  part of my game engine.  If you're interested in that, it's called Big Block Engine.  If you want to use this sprite, it's license is CC-BY-SA 3.0.  For the attribution part, I'm Richard Lewis and if possible please share a link to my game engine when you credit me.

After talking with a friend about it, it became clear that what was bothering me was a lack squishing on the part of the slime and it needed to jiggle just a little, even in it's rest state.

Here's the new gif (I decided to put it on a checkered background this time):


Here's the new sprite sheet:


(1 edit)

I've drawn a slime monster in Inkscape (so I can resize to any resolution required).  I'm trying to make it look like a monster made out of a very stiff gelatin.  To that end, I'm working on an animation to play whenever it's disturbed by a collision.

Here's an animated gif I captured of the jiggle animation, as taken from my game engine:


Here's the current version of the sprite sheet:


As you can see, when struck, the slime jiggles.  Something about this animation is bothering me, every time I see it running, but it's probably just me being a perfectionist.

What do you think?  Can you see any way I could improve this little sequence?  Thank you.

(1 edit)

Having worked on that "cake walk" for a few hours, I can say, yes, I can get it to work.  However, I'm not sure I can ever make it work in a stable fashion, plus very low density fluid ejected actors at ridiculous speeds.  So...never mind.

The other approach I might try would be based on propelling actors to the surface using the collision forces already built into dyn4j, but for that I've got to figure out the walking on water feature.  So, probably eventually, but not now.

Led, what algorithm is your lighting node using?  I'm wanting to build something similar for a project of my own.

Is there, perhaps, an article you could give me a link to that would aid in my understanding?

Thank you.

Nice art.  I like it.

What is the license?  I downloaded it, hoping to find a license.txt or something like that in the archive, but it's just the images.

Is it public domain?  Are there any restrictions on re-use?  Could you please make this clear?

Thank you.

Very good writing in this game. I've never been sucked in so fully by a phone conversation before. It's a fascinating game concept.

Great job!

It's fascinating the way the text seems to be perpetually almost, but not quite, decipherable, or in another language. It's like someone that had a very, very shaky grasp of English went out and wrote an entire library of books.

Try picking up a book that seems almost on the cusp of understanding and try pronouncing a page out loud. It's like you're reading some kind of magic spell.

I think this authenitc gibbberish could be useful under certain unusual circumstances, like picking words for a magic spell in a story. It might be helpful in making up a fake language, too.