itch.io

Hello!

Around the time of the release of version 1.11.0 in May, I updated the game to the then current version of a widely used community sourced database of joysticks and gamepads:

https://github.com/mdqinc/SDL_GameControllerDB

So everything in there (at the time) should work, assuming it was registered correctly. Even if not there, I can and have assisted people with workarounds on how to supply similar info to MULE Online locally prior to runtime. Even without such conditions, the game engine used will attempt to do its best with the cooperation of the OS and device drivers to use the device as-is, defaulting the button order to their default. In which case, on a joystick with a very limited number of buttons *might* experience issues not being able to bring up the game's main menu or dashboard during the game. For that unlikely case, I'd recommend having a keyboard attached and at the ready.

But alas, I know of one person who's reported they have successfully used the SPEEDLINK SL-650212-BKRD Competition PRO EXTRA USB Joystick.

Using Firefox. I retried and after refreshing the browser and reloading several times, I was only able to reproduce once. 

Godot is my weapon of choice.

I played some Fast Eddie last night. I misspoke about the ability to change directions mid ladder.

I understand how it goes about old test projects. Anyhow, keep up the good work!

Nice job on a Fast Eddie remake. Keep at it!

I played the web version. 

Level 1 kept starting with no collectables. Eventually it did. So I thought it was an introductory level where I just grab the key. I recommend a slow motion or pause when dying or grabbing the key, the music you added, and an animation that gives feedback that I was dying or completing the level--I honestly couldn't tell at first.

Being able to reverse direction on the ladders is a must for Fast Eddie late game levels. I'd say it's a must have feature.

I question the floaty-ness of the jumps, but that's the kind of thing that just means the rest of the game needs to be tweaked around it--not a big deal.

Graphics cohesion suggests to me that this project was part of a game jam.

Again, I'd love to see this game updated.

Hi Dan.

I am aware of some clunkiness with the new game settings interface with respect to some interaction with the interface for each player to interact with their personal panel of options.

However, it is not my expectation that using the mouse to change the level of play while a player is associated with a joystick would have any impact on the joystick player, unless perhaps the joystick's selection focus had been moved to the game level of play and then the mouse took focus of that option afterwards. I at least had anticipated preventing the mouse from doing this--but quite possibly I forgot to address it. Alternatively, perhaps it should just redirect the joystick (or keyboard) selection focus back to a default entry in the respective player's personal panel of options.

If I have not accurately described what you are seeing, I would love to see a video or receive additional details. Two places come to mind for submitting video:

Support Email:
mailto:muleonlinehelp@gmail.com

Discord:
https://discord.gg/eSMCJ2NGdQ

Thanks!

Yet another solid point advocating for collusion. I am sold on the idea.

Great to hear you are playing with your child. I love to hear it. And it's definitely a focus of mine to make MULE accessible & approachable by a new generation.

Thank you so much for the purchase and the praise. It's worth mentioning that this version of the game is developed by a third party and not directly by any of the original authors. However, it's officially licensed and I have a strong relationship with the estate of MULE's primary designer as well as a strong regard for the original game and the vision that its original authors had & had intended.

Funny enough, technically, game saves (and loads) are implemented. I use them for testing quite a bit. They also facilitate the feature where a client can quickly reconnect to a network game still in progress--say if one's computer were to crash.

My intention is to incubate this feature for a while before exposing it through an interface.

I always consider if a new feature can be exploited, particularly in an online multiplayer game. I have already put some work into ensuring crystite is relocated every time a game is loaded. It was a fun challenge, because it can only move crystite to locations that don't contradict any of the crystite revelations up until that point. Unfortunately, I did not make that algorithm work 100% with Meteorite Strikes. I shelved it because I had to move on to other enhancements.

I appreciate the request. It's definitely up near the top. Modern games, especially longish ones like MULE have an expectation to have a save feature. Expect to see this feature in the future, as more things progress with MULE Online.

Thanks. I was super excited to meet Roy and finally publish it.

I agree about the SID chip. There a few things the C64 version does better--music is one of them. I was exposed to the Atari version fairly late; I remember enjoying the differences, like seeing the director's cut of a movie.

That *is* concerning. Thanks for cluing me into your computer platform. Apple ARM or Intel? The Apple version is built with a different compiler than the Windows & Linux versions--in such cases there is always an edge possibility that the significantly different environments would handle some bad code different than the other.

Unfortunately, I'm doubly boned in regards to reproducing & testing (and thus fixing) this issue myself, as at the moment and for the foreseeable future do not have access to my Intel Mac I use to build the Mac version. And I don't own an Apple ARM Mac to begin with. But I'm not without professional experience investigating this sort of hard to reach issues--it happens and these sort of the issues are the worst! I'll do what I can for the time being. But even if I suspect I found the problem and propose a fix, I won't be able to build a patch without my Mac.

As for making the last round auction skip an option--that is definitely a possibility and I will definitely promote it as such when possible and enough people complain about the current behavior.

Thanks for the feedback, Dan. If ever I get a test build for the mountain slowdown issue you mention, I will likely seek your help in testing / verifying an intermediary build.

Hi. Thanks for the feedback.

Did you know mountains don't slow you down if your planeteer is overlapping a plot's graphics (border and plot type symbol)? Please ensure this isn't the case during your testing.

I was hesitant to skip the last round auctions. I know some other people who do similar on the last round. What allowed me to make this change on good conscious is:

1. In the survey I ran, a good portion of people emphasized the game went a little long or needed a way to be sped up.
2. Selling all your goods does not guarantee your money score will be the same as if you hadn't sold; the only good that is consistent in this regard is smithore. For food & energy, you sell at a point loss. And there is a 3/4 chance you are losing some change if you sell your crystite as well. In a really close game, everyone selling everything would tend to lean the win to the players that focused smithore.

There's actually a bug in the C64 version's scoring of food. In this regard, selling all your food in the last round would actually retain points otherwise lost.

Thanks, Pat! I felt it important to nail classic MULE before adding any enhancements. It is near perfection; so why would we accept any less?

It is definitely my intention to add new events to the game. I consider it almost like an expansion deck of cards for a board game. They generally don't change the core of the game but it adds variety and some unexpected interactions that can be interesting.

The unreleased official MULE sequel did both of what you propose and I definitely look at it as a sort of authority on where MULE was likely going before it got cancelled.

Moving the river valley around is not impossible but it'd take a bit of engineering because the original developers based a bit around the notion that the river is vertical line.

Moving the X coordinate of the river valley is more achievable. And it'd give the appearance of what I recall the sequel referred to as oasises.

What would be harder is having more than one river valley plot per row.

I'm a little hazy at the moment as per what all the MULE sequel's events were but what comes to mind are variants of pirates. I think added like food pirates and such--but I could just be falsely remembering this because food pirates would likely kill a game in its tracks.

I'm guessing they had working were probably just ideas and they were probably subject to change. My understanding that part of the reason the sequel got cancelled was just that theain designer was unhappy with the state of it.

I've of course have thought of my own ideas for events. Some simple but some fairly significant. For instance, I could introduce a sort of mini game (MULE has tons of those, like hunting the Wampus or playing minesweeper with the crystite) where a mule catches a virus that produces both a negative and positive outcome (to keep it balanced)--the virus would boost mules' mining ability but would hurt their ability to produce consumables. And every round after the initial virus outbreak there is a chance of the virus spreading to your other plots or your neighbors'. Maybe that's good for you, maybe not. You'd have to decide. To rid the virus you would need to take the mule back to the corral.

Your ideas are cool and I think they should be accepted as MULE like events because they seem like slight variations on existing mechanics in the game.

As per turn events, what if instead of the dreaded lost plot plots are merely exchanged between players?

I'm totally open to more ideas. I encourage people to submit and explain them. If anything it's just really fun to talk about. And if they are favored, they would more likely end up in the game. Less work for me (maybe...).

My last update to the game widened the path to introducing customization in the number of each event, which is my eventual intention. And adding that enhancement is the precursor to adding new events entirely.

Thanks for the feedback!

I appreciate people providing feedback on this matter. I have been convinced that it is worth bringing back into the game. I am something of a hypocrite to think I can withhold the feature while purporting to provide classic MULE. I had settled towards making it an off by default option, but perhaps it should be on by default but optionally disabled.

A survey link was emailed to then current customers and was advertised on social networks including the World of MULE discord server. I plan on publishing the results but the Roy Glover interview was higher priority. When I do, I'll advertise similarly; instead of an email, I'll make a community post here.

Thanks for the clarification on the speed up ideas. I'll likely supply them without option, relying on the unanimous voting nature we discussed before.

I rather like the simplicity of designing around a single (primary) button, where all other buttons are not essential to the game. And I guess a counter argument would be that a dedicated skip button is not essential. But there is already such a precedent in MULE with using the button "to go on". Did you know you can reconfigure your gamepad settings in the main menu -> options -> input -> gamepad -> customize -> ...

The status summary animation skip is doable. As a product manager, you know how programmers will wince and squirm but eventually implement a feature request. MULE does not distinguish between button just pressed versus button down; it only looks at the latter. There is a use case where players will hold their buttons down during the animation to ensure their scores are hidden from other players when the animation ends. The skip will require that a player raises their button and presses it again. I can think of a couple ways to do this.

I currently don't have a public roadmap list. In my developer logs, I give a general "what's on the horizon".

Hi! That's awesome you've been playing with your kids. We gotta spread the MULE love!

Which version did you originally play? Atari or Commodore?

The Wampus is tough to catch. It was actually tougher to catch in the Commodore version for reasons I am 99% certain were not intended by the original developers. That being said, in regards to catching the Wampus, this version should be on par with the Atari version.

Planeteer & mule collisions with mountains, river, plot border & graphics, and town are the only cases where the shape of what species you are playing as matters, because if your planeteer overlaps a mountain (as you know) it will slow down. So, in a sense, climbing a mountain to catch the Wampus makes it more difficult.

But notice I didn't say that the shape of your planeteer colliding with the Wampus "white dot" is a factor. It's actually the case that for every mountain the Wampus visits, there is only two positions your planeteer can be at to catch it. Consider that each XY coordinate your player can *step* to is a separate position on the board. Observe the following images. The green upper left corner dot needs to be at the vertical offset from the Wampus dot as shown in the first image. And then green dot needs to be at the horizontal offset of either of the latter 2 images.

 
(Images courtesy of Pascal Bringer)

Notice the aspect ratio of the dots--wider than tall. That is true of the entire board. But more relevantly, is it is the ratio for the distance a planeteer moves horizontally & vertically (all throughout the game)--visually a planeteer can cover more ground moving horizontally. Another aspect is that nearly every planeteer is taller than they are wide. Why am I saying this? Consider that it takes more time to move through a mountain vertically than horizontally in most cases (and positions & mountain shapes). And back to one of my original statements, mountains slow you down.

So you want to approach the Wampus from an angle that causes the least amount of slowdown. Surprisingly although mountains certainly look very wide, I have surmised that it's easiest and most successful to wait to the side of a mountain and move in horizontally when it appears.

I don't tell this to many people (but I guess I am now!), but because of all this, it's quite likely the best species for catching the Wampus are probably Packer (for its smaller footprint) and probably Flapper and then Gollumer, as they are the thinnest when shown outside the town.

Greetings! Thanks for the feedback.

Auction Speed Up
Speed up or reduced time during the game when players are "doing nothing", namely during auction while waiting for a timer to expire, is an enhancement that gets brought up to me occasionally. In fact, that category of write in responses figured prominently in the survey I recently conducted.

Thinking on it, I am a little apprehensive about doing it or how it should be done. To paraphrase Dani Bunten:  what happens around the game is as important as what happens in the game. I don't think it matters so much in a solo game, but I worry that if there is more of an impulse or pressure to skip those windows of time where players could propose & initiate deals, etc., some of the heart and soul of MULE might be diminished.

For the MULE sequel, the publisher requested player turns be simultaneous. That'd speed up the game for sure, but at what cost? It's important to observe and think about what you're going to do on your turn. Dani Bunten begrudgingly agreed but that became a slippery slope for the infamous "bombs request" that led to Dani walking away.

As you have noticed, I am a bit guarded with stuff like this and collusion. However, I've softened up a bit, especially after the survey. My current sentiment is to make these sort of things as democratic as possible, on par with your idea about "all players vote".

The scheme I've come up with is very similar to the one you present. However, you bring up an interesting point about the player pressing into their origin / bounds--that could be useful for indicating something! If all players (computer players alike) are not moving and all human players are pressing their primary buttons, the timer speed increases to some rate faster than the speed for when no players are moving in the trade range (between and at where the trade bars varies).

Repurposing the primary button during auction means I would definitely have to come up with an alternate scheme for initiating collusion.

Again, because of the survey and vocal fans like you, this enhancement is higher priority than most (especially collusion).

Skip Computer Player Turn Action Buttons
What is the reason you'd like every button to skip computer player turn actions? Some of the buttons are reserved for other actions, such as bringing up the main menu and what I call the "game dashboard" (where you can currently go to change a player's controller), "start" & "select" respectively. It's possible (and very likely) I will introduce other actions to other buttons as well. For instance, in the unreleased MULE sequel, with the Sega Genesis controllers had 3 buttons, it was possible to view the entire landscape from within the town if you needed to look at your plots (maybe you forgot what kind of mule you needed--I know I do this all the time!). So, in the end, it might be a little weird to have an odd configuration of a subset of buttons to vote for a speed up. I also have to be cognizant of the people playing with keyboard or mouse (have you tried mouse control yet?).

Status Summary Animation Speed Up
You are the first to request this feature. But after the survey, I expanded the general notion of speeding up the game and thought about the places where speed up might be useful. Other areas being during all round event animations and plot production. Again, there is a sort of drama & suspense to watching the plot ticks pop up, where we're almost praying for a good yield. But you might make a good argument that there is definitely something important happening there and it's not as dull as watching the sands of an hourglass empty.

That being said, I thought about this idea as well. And being a player but also a developer, I've watched this animation a lot! This one is a little complicated with legacy behavior. I would want it to be unanimous like the proposed auction speed up. But because the primary button has the function during this screen to hide a player's score and progress to the next phase, it would introduce the scenario where people accidentally do the latter. I suppose if there *was* a dedicated "vote to speed up" button, it wouldn't be an issue, but that idea has its own drawbacks.

I bet if we put on EEGs, we'd probably see a lot of activity during at least the first half of the status summary animation. We are already performing postmortems and scheming what we need to do next.

Speeding up this animation has a side effect that not observed during the auction timer speed up:  the planeteer moving animation will look a little funny. Although, something I could achieve not possible with speed ups using emulators is that I could keep the music at the correct speed.

So, because of these complications, this particular enhancement scores quite a bit lower in the priority queue.

---
I apologize if I've created a big wall of text. I love to talk MULE & MULE enhancements. So, please keep the ideas coming!

Ha, yea, talk about discoverability! I talked a bit about this with someone in the World of MULE discord server. I have an idea to allow for collusion again:  since horizontal controller movement is not used, I think I can introduce an interface that will allow players to indicate they wish to collude with a specific other player. And if the other player reciprocates, collusion occurs as it used to do. Depending on how I present it, it may only be a smidge more discoverable than before, but it'll improve upon how people used to have to count out (1... 2... 3... press!).

I'm happy to have conducted & published the first online interview with Roy Glover, the composer of the MULE theme song.

Check it out over at World of M.U.L.E.:
https://www.carpeludum.com/2024-interview-with-roy-glover-composer-of-the-m-u-l-...

Roy is a great person and was a pleasure to talk to and meet.

Great job. Consider enhancing it further. Lots of cool directions you can go while keeping it feeling like River Raid.

Also, preload / cache your 3D models so the client doesn't hiccup when they are loaded for the first time.

So I think there are 2 issues:

1. I couldn't figure out how to avoid assigning a key to place dynamite. Similarly, I was trying to only configure the keyboard and I guess it detected I had a joystick attached so it seemed to insist I configure it while I was at it. That joystick only has a single button; so I had to abort and find a more suitable gamepad to plug in in order to complete the process.
2. I was actually eager to use a non-directional key for dynamite but I quickly realized I needed to have the old method present as a safety net while I got used to the separate key. But thinking on it, because I'll probably never stop playing classic H.E.R.O., I'll never want to stop using the old method. However, I think I could learn to use both with your series of games.

I get a sense of how you did things. Although I didn't try or realize until right now, I'm guessing that if I set a key other than "up" to make the hero fly, the previous "up" key would cease to do it.

I know button configuration is a bear, particularly introducing the logic required to interactively assign multiple buttons to an action. So, I propose that there are separate checkbox options like "up direction to fly", "down direction to place dynamite", which would both be enabled by default and could be disabled if there has been a different key / button assigned to it.

HERO is in that group of platformers where the hero can't jump. And there is also the group of platformers that require pressing up to jump. And HERO kind of intersects both. As I mentioned before, some people gag at the notion of pressing up to jump. But interestingly, I think the idea of controlling the flying with up doesn't break these rules. I bet people would really dig if you added a Pitfall style jump in addition to flying. In some alternate timeline where HERO because wildly popular, Activision created it's own console, and HERO was its Mario, I have no doubt in my mind that he would be able to jump.

Good job. I played it for a while; so I cannot say it doesn't pass the test--it feels extremely faithful and good. I can tell you spent a bit of effort to nail the physics.

I think the general aesthetic works--even kind of resembles some of the lesser box art branding for the game. But it almost seems like the artist was trying to make the art assets look bad. Why!? You did such a solid job with the game otherwise.

Clever UI control scheme once you discover it.

I would recommend at least putting the dynamite counter, if not also the lives counter, at the bottom of the screen with the oxygen (I think that's what that was?) meter. Keeping them together let's me "keep my eyes on the road", rather than darting to both extremes of the display and away from the playfield. There was one point where I was next to a wall; I looked down and didn't see any dynamites or any indication of whether I had any. I instinctively pressed down to check and I guess mentally I was not prepared to see a live stick of dynamite at my feet. Suffice it to say, I didn't survive!

Great job. It's like HERO got ported to the SNES!

It's very faithful. No complaints in that regard except perhaps when trying to go down a 2 body width hole with an enemy it was harder to avoid dying. I recall being able to not overshoot the cliff. But perhaps I'm rusty.

Being able to dedicate the dynamite to a separate button is nice. But I was a little disappointed when after doing that I could no longer press down to use one. I guess old habits never die. I could see how newer gamers (and by that I mean people who at least started on the NES) could get discouraged by accidentally using dynamite when they press down at times. Perhaps make it a separate option. Or make it obvious how I can skip a button configuration.

Keep going! Playing your game makes it very easy to think about all the cool ways HERO could get enhanced even further.

Thanks for striking up this conversation. You make a compelling argument for the inclusion of the collusion mechanic.

You mentioned you've heard me explain why it's not in MULE Online but I will state it here for anyone who hasn't.

Economics

MULE does a great job of expressing supply & demand and price competition. Collusion foils & circumvents it. It's not like collusion is unrealistic; it clearly happens and there are reasons for it. But I've never seen a collusion at an auction, where some people are barred from participating. It's perhaps a moot point because MULE's auction is more symbolic than a realistic simulation--it could be argued that the collusion mechanic / phase represents a private trade. But that's the irony, as it's not private--it almost needs to be ("hey, where did you get all that energy!?").

Sportsmanship

Colluding against a computer player is one thing, but colluding against an active & willing (to buy or sell) player feels either a bit like cheating or a way to remove a player from the game. When the game takes a plot away from you, it stinks; if the game allowed other players to take away plots from you, it's war. I don't see it as much different than Dani Bunten pushing back against the inclusion of weapons in a MULE sequel.

There are unused messages in the original game which suggested they floated ideas like stealing other players' mules as well as the ability to "go to jail". I guess such actions were considered if they had risks & consequences. But the consequence of playing unfairly against another player is simply that player decides to actually stop playing the game or promises to never play the game again, I don't know how much the insider trading was worth it.

I'm not describing a fantasy scenario--I've seen it happen; I was one of the colluders. I don't think we thought we were doing something offensive outside of the scope of the game. It likely warranted a little more maturity from the player that essentially flipped over the board game. But I do feel there is some responsibility to creating an environment which supports positive behavior. I think MULE does it well by supporting cooperation.

UX

The interface for initiating collusion is clunky and doesn't translate well to online multiplayer. I've thought about ways to better signal that a player was "pressing their button", like highlighting their planeteer's color when their button is down. But even then, the timing has to be just right. I have memories of trying to mess up players trying to collude by joining in when I wasn't invited or trying to verbally throw off other players' coordinating count-off. Although not my recommended way to play, mouse / touch controls would need a dedicated mechanism for initiating collusion.

I've gotten an overwhelming amount of feedback supporting a way to speed up the clock during auctions. I have been on the fence about that too! 'Afraid that it would bypass the opportunity for players to think & try to negotiate trades before time expires. But I've had to reflect a little that giving players the power to decide is probably best, going as far as ensuring it's a situational & unanimous decision among all players. So, I'm leaning towards speeding up the clock when all human players are not moving and are pressing their buttons.

My most recent conversation about including collusion ended with the idea of having it as a non-default option.

If I've rerouted the primary button's action to the "speed up" mechanism, then I'd need a new way to initiate collusion--which is what I really want regardless. I think there might be an opportunity in the fact that there is no horizontal movement during auction. Perhaps each player can cycle a cursor over to another planeteer they wish to trade with specifically and if the other player reciprocates, it initiates a 1 to 1 collusion.

Clearly at least one person involved in making MULE had a convincing argument for collusion. I suppose there are scenarios where the lower ranking players could use their tie breaking to prevent other players from buying from sellers when supply is very limited. In which case, something like collusion would almost be the only way around it.

My goal is to make this versino as close to MULE as possible and I try to have Dani Bunten's ideas for MULE & philosophies on multiplayer gaming in general guide enhancements. I realize omitting collusion seems a bit hypocritical in that regard. Thank you for voicing your opinion. I should bring this feature back one of these days.

Thank you for your praise. If you'd like to share any Dani Bunten anecdotes, I would totally love to hear them!

Thanks, I'm forever recommending people your Boulderdash remake.

Boulderdashtastic!

The Atari ship has been requested a handful of times. I plan on implementing it and making it the out of the box ship graphic.

No one has asked for the Atari river yet. There are technical reasons that make implementing the Atari river less likely. But I might be able to figure out something to make it possible & passible.

Thanks for the feedback.

Thanks. Lots of ideas and things to come!

Version 1.9 has dropped. Includes pause when main menu is up (pressing escape, "start" button on a gamepad).

Starting v1.9.0, a BAT file is included in Windows versions which will perform the instructions above and start the game in a GLES2 fallback mode.

Hopefully, this should resolve any "blank screen but still hear music" issues anyone is having.

@Amos, is there any progress on this issue? I'm not speaking on previous version builds in a channel. It looks like it makes every previous build available for a channel's version available for installation, at least from the Itch.io desktop app. I can't think of a use case where someone would want to have them available, as they, at least in my case, are mistake builds (eg "oops, forgot to add a text file", etc.).

Does any non itch.io developer actually want to see previously uploaded builds for a version?

Yank logistical problems aside, perhaps just only show the most recent build under each version.

Awesome. You have done the original justice. Looks right but more importantly it feels right too!

I agree. I've hobby developed for the C64, NES, Apple II, and Atari 2600, but not yet for Atari 8-bit. But that's not to say I haven't studied up on it. And I purchased a copy of Mapping the Atari. I think you are right that it would suit the Atari computers. So I will give it a shot when time permits.

I immediately recognized this game--even without remembering its name. Very cool.

Thanks for the feedback. I am actually a Commodore kid, but M.U.L.E. got me appreciating its typesetting more than the one built in the C64. Your interest in the game as well as someone else's recent comment makes me think I should pursue this project as an actual 6502 game.

This game was very much inspired by Jumpman and Loderunner. The idea came to me while brainstorming for a game jam--but I didn't develop it until later. I forget the jam theme--was probably something like "between worlds". And I had this idea of phasing between a platformer and a tile based game. I'm sure you could come up with a lot of ideas to make this combination fun.

I love truly retro games. I'll check your profile and website. Thanks!

Thanks for the feedback. This game, like most of my game jam entries, I work on them a little after jam but never get around to updated them on itch.io. I definitely added some good touches to this one, to the point I should probably go ahead and update it.

If I recall right inertia exists but I tightened it up so much that you can't even tell. I think I did that to compensate for deficiencies in my AI.

Hehe. What was I thinking!? I think I was inspired to make a "chess-like". And my spin on the genre was that the proximity between different pieces allowed them to make different moves or actions. Also, I was definitely inspired by Archon and Battle Chess. It's farm themed I think probably to match the game jam theme, but you could easily substitute the farmers with mages.

Darn. That stinks. I'm sorry about that. At first thought, I'd say I haven't heard or experienced your issue. But there was a similar freeze I encountered twice many months ago--so long that I assumed it was no longer a thing and none of the playtesters every reported such.

Do you know if your sister's turn was the last in the rotation and a round event or production was going to happen afterwards? In which case, that would be the freeze I saw a while ago. It's quite elusive. If that's the case, I need to think about it more. If it's not the case, I need to *really* think about it!

Can you do send your game info & game logs to muleonlinehelp@gmail.com?

The logs are located at:
%APPDATA%\puzzud\mule\logs

And the save games are located at:
%APPDATA%\puzzud\mule\games

In the future it will be possible to resume incomplete offline games from those save game files.

Thanks for the feedback & sorry about the lost game. I spent a lot of time chasing known crashes the month before release. Unfortunately, it wasn't enough.

Awesome--that's a big part of why I made the online capability and how you & your wife can play from the same computer with your sons who are remote.

Thanks for the feedback.

Pausing
I recently implemented pausing in offline games. It will be in the game's next update. The game will pause when the main menu is activated. And the gamepad method of bringing up the main menu will switch to the "start" button from the B button. I realize this pausing method will obscure the screen, unlike pausing in the original game. I do plan on eventually adding a pause without the main menu, complete with the clock ticking sound, but it will have to wait for some other important features to be implemented. Concerning pausing in online games--it gets complicated and I don't know of a nice way of doing it.

Collusion
There is no ability to collude, in the classic sense, in MULE Online. The decision to leave that feature out comes down to 2 things:

• Collusion goes against the free market mechanics of the rest of the game--competition driving lower prices; demand driving higher prices. The only feasible argument for collusion I've heard so far is that it's useful for when a computer player is winning. In practice, I find when collusion is used to cut out another human player, it inevitably results in hurt feelings.
• The original method of initiating collusion, as you described, does not translate well to online play. It was clumsy enough on the same machine.

I'd like to hear your thoughts on the purpose of collusion. Perhaps I am missing something.

I have a very large backlog of a lot of other (better) features that I think you'll enjoy.

*OpenGL ES 3 is required but a fallback for OpenGL ES 2 and older GPUs is available. See Trouble running in Windows.

After purchasing MULE Online, a Download button will appear, revealing buttons for each OS:

After downloading the ZIP file that matches your computer's operating system, the instructions to run the install & run the game as follows:

Windows:

• Download mule-online-windows.zip
• Extract mule-online-windows.zip
• Launch mule-online-windows/mule-online.exe

Mac:

• Download mule-online-mac.zip
• Extract mule-online-mac.zip
• Select to launch M.U.L.E. Online.app
• Or drag it to Applications to install it
• Launch M.U.L.E. Online from Applications

Linux:

• Download mule-online-linux.zip
• Extract mule-online-linux.zip
• Launch mule-online-linux/mule-online.x86_64

Itch.io provides a desktop app that operates much like Steam and makes downloading and playing games very easy. And it will also help update your MULE Online installation when updates become available. Here is a link to that app:  https://itch.io/app