Observations For Possible Improvements

[Maximus Dominus]

Thanks - I missed it.

Not a problem. If you missed it, others will likely miss it, also.

[Wookie Panz]

Here is a new idea.  How about improving the granary building so it actually helps against seasonal food loss?  Instead of losing 75% in either summer or winter the granary lowers the loss factor to 50% in addition to giving the 25% food bonus at the time of the build.

Here is a question for our programmer -  How hard would it be to make a bazaar, granary, or port recalculate the bonus every turn instead of at the time of the build on the building.  Would this be something people want?  Would it skew play balance?

[Acererak]

Ok, I'll bite. I've been playing Alamaze off and on for 35 years. Was the Westmen in game #33 back in 1988. Whenever there is a request for possible improvements I ask for two things that seem like no brainers:

1) The ability to station leaders and wizards at popcenters, where naturally their bonuses and spells will be used in battles against groups.

and

2) A spell that allows you to teleport emissaries or agents anywhere on the map. If a wizard can teleport an army group than surely they can teleport a single figure.

No brainers.

[Wookie Panz]

It recently occurred to me that in some games the limit of ten different types in a group was very frustrating.  When you fight a pitched battle and your veteran units are prohibited from getting their well deserved promotion due to the 10 type limit it can really suck. 
The worst thing about this is the way that training levels count as troop types.  With green, regular, veteran, and elite troops all taking a slot, even though they are the same KIND of unit or type. a green unit can keep a veteran from getting a promotion just because the 10 slots are filled.

What is the purpose of this and can it be fixed?  I do think this is the type of thing that people find frustrating.

[Maximus Dominus]

It recently occurred to me that in some games the limit of ten different types in a group was very frustrating.  When you fight a pitched battle and your veteran units are prohibited from getting their well deserved promotion due to the 10 type limit it can really suck. 
The worst thing about this is the way that training levels count as troop types.  With green, regular, veteran, and elite troops all taking a slot, even though they are the same KIND of unit or type. a green unit can keep a veteran from getting a promotion just because the 10 slots are filled.

What is the purpose of this and can it be fixed?  I do think this is the type of thing that people find frustrating.

It's a good example of how a game, for all of its positive aspects and features, can still die the death of a thousand cuts. Small cuts. Little things. Little things take the shine off of a game.

What you describe, Dan, is an example of how a game becomes unwieldy. You want to do something simple, and yet, the game and its interface chooses to make it hard, if not impossible. The military end of the game isn't as smoothly designed as the character end of the game. Not that everything about the character end of the game is polished to perfection, but that end of the game is certainly head and shoulders above the military end.

You can't just let people raise troops and fight. Obstacles and impediments get thrown up to such. It discourages their use. Late last night, I was just shaking my head at the transfer system in place. Just unnecessarily complicated. It's little things that kill Alamaze, but there's numerous little things that are annoying as hell. Obtuse design is what's eating up your troop slots. Why is the limit set at 10? Just an arbitrary decision. Fun should govern. The more fun that a game is, the better its chances of attracting - and retaining - more players.

Is it fun watching your troops/brigades not get their well-deserved promotions? Of course not. Something that plainly obvious remains in place, and the great mystery is, who likes the game that way? Anyone? It's an annoyance. It's a thorn in your eye. It always will be, because it makes no sense for things to be that way.

[luty]

Ah, you poor deluded young person. (I'm assuming you're young, because if you were old you would know why it's that way.)

There is a very sensible reason for things to be that way.

Hint: it's the same reason that the game map is 26x26.

Alamaze came out in 1986.

The most advanced PCs in 1986 were the brand-new 386-based machines with a 32-bit architecture. Much was made of the greatness of 32-bittery, even though nothing used it yet. Production PCs at the time had 16-bit architectures, and most hobbyist machines were 8-bit.

The PC that Alamaze was designed and originally ran on probably had....I'm guessing here....probably 4 megabytes of RAM (mega not giga). 

And although it was a fast machine for its time - probably a 12 or 16 MHz 80286 CPU - for a big game like Alamaze to run in anything like reasonable time, the game data needed to *fit into that memory*. Disks were SLOW then. Slower than me telling this story slow. I was writing PBM games in this period, and I recall spending a week or two recoding the entire game so that it ran entirely in-memory with no disk access, and processing an individual turn went from 10 minutes to about 15 seconds. 

I'm wandering far afield (we old people do that, it's why we carry AirTags in our pockets, so our grandchildren can find us). 

Long story short, you can only have ten unit types, and you can only have three wizards and three leaders in a group, because they were scraping together every byte they could to squeeze the damn thing down to where it would hold everyone's units at one time. If units had been open-ended data globs with an object-oriented structure where there were no limitations, the game would never have finished being written, because ONE of those units would be a slug to load and process, much less 30 or 40 of them. 

The map is 26x26 because that makes it easy to encode all kinds of data in strings, and strings are really easy to work with even with shit computers. Easy to store, easy to parse, easy to program.

In other words - the reason for the limitations is that the hardware of the time the game was written mandated those limits. 

You can fix them now with the stroke of your mouse, and go right ahead as far as I'm concerned.

[Maximus Dominus]

Ah, you poor deluded young person. (I'm assuming you're young, because if you were old you would know why it's that way.)

There is a very sensible reason for things to be that way.

Hint: it's the same reason that the game map is 26x26.

Alamaze came out in 1986.

The most advanced PCs in 1986 were the brand-new 386-based machines with a 32-bit architecture. Much was made of the greatness of 32-bittery, even though nothing used it yet. Production PCs at the time had 16-bit architectures, and most hobbyist machines were 8-bit.

The PC that Alamaze was designed and originally ran on probably had....I'm guessing here....probably 4 megabytes of RAM (mega not giga). 

And although it was a fast machine for its time - probably a 12 or 16 MHz 80286 CPU - for a big game like Alamaze to run in anything like reasonable time, the game data needed to *fit into that memory*. Disks were SLOW then. Slower than me telling this story slow. I was writing PBM games in this period, and I recall spending a week or two recoding the entire game so that it ran entirely in-memory with no disk access, and processing an individual turn went from 10 minutes to about 15 seconds. 

I'm wandering far afield (we old people do that, it's why we carry AirTags in our pockets, so our grandchildren can find us). 

Long story short, you can only have ten unit types, and you can only have three wizards and three leaders in a group, because they were scraping together every byte they could to squeeze the damn thing down to where it would hold everyone's units at one time. If units had been open-ended data globs with an object-oriented structure where there were no limitations, the game would never have finished being written, because ONE of those units would be a slug to load and process, much less 30 or 40 of them. 

The map is 26x26 because that makes it easy to encode all kinds of data in strings, and strings are really easy to work with even with shit computers. Easy to store, easy to parse, easy to program.

In other words - the reason for the limitations is that the hardware of the time the game was written mandated those limits. 

You can fix them now with the stroke of your mouse, and go right ahead as far as I'm concerned.

Glad to see you join us, Robert.


I'll defer to your assumption that I am a young person. Compared to you, I might well be. And as far as your compliment I am deluded, I'm not inclined to argue to the contrary. Certainly, it may well be the case that I was deluded to ever think that Alamaze was still stuck in a 1986 mentality, but 1st Cycle, 2nd Cycle, 3rd Cycle, and now 4th Cycle Alamaze have been visited upon the gaming world over the years, and there has appeared to have been at least some intent and desire to visit the plague of a new and improved Alamaze upon gamers in the intervening thirty-seven years - which is more than half my lifetime, now that i think about it.

I am not entirely oblivious to 386-based machines, as my posting of 03-07-2011 attested to, previously. It was a 386SX that I used to create a small scale PBM game called Starforce Battles on, but not being a programmer, I chose a different route to bring it into existence.

It may well be, of course, that today's era of gamers are waiting with bated breath for 1986's Alamaze to entrench itself in its past. Which begs the question of why Alamaze's Game Creator displayed 1st Cycle: Classic Alamaze and 2nd Cycle: Resurgent Alamaze as having been disabled.

   


Having tried Alamaze first-hand several decades ago, when Reality Simulations, Inc. ran it, I certainly can't say that I am anxious and eager to remain stuck in 1986, a time of Alamaze infancy. Heck, even Alamaze's designer and creator, Rick McDowell, wasn't content to allow Alamaze to remain glued to its 1986 iteration.

That said, I think that whatever delusion that I suffer under, Luty, is no doubt of the self-inflicted variety. Certainly, the time that I have allocated to Alamaze over the last month or two certainly gives credible rise to the proposition that I have transitioned from mere delusion to outright craziness. I probably need to rein that in. I could certainly use some extra rest, I know that.

Certainly, the Alamaze programmer seems to think that many of the previous Alamaze players would want to play the older version that they were accustomed to. But 3rd Cycle: The Choosing Alamaze games aren't disabled, currently, the way that 1st Cycle and 2nd Cycle Alamaze games are, yet no queue of 3rd Cycle: The Choosing fans appears to be forming.

Ultimately, it may well be that stringent adherence to older ways of doing things, programming-wise, may be the key to a much larger player base for Alamaze.

What was it that I wrote in the beginning of an e-mail to John at 1:19AM, this morning, after finally getting my turn orders for Turn #5 of Game 5712 issued?

What a headache it is to do transfers.

Over and over and over, just fighting the interface. Can't do this, can't do that. All kinds of restrictions and limitations.

I got it done, but there sure seems to be numerous hoops for players to jump through. Trying to raise troops and move groups - Sheesh! Wrong kind of military leader. Not enough ships. You've got to split this off from that, then move, then rejoin after you move. Who in the hell came up with all of this? Is it just me?

It's unnecessarily difficult and time-consuming (after all, issuing orders just one time simply isn't sufficient, since you've got to redo the order - and again, sometimes).

The character (figures) end of the game is much less of a hassle, when it comes to just trying to issue orders. It just bogs things down.


That things were programmed a certain way decades ago, and for very valid programming considerations, should not, I think, be immune from being looked at and reconsidered under the light of a new day almost forty years later.

All of that aside, it is good to have you become more active in the forum, here, Luty. By the way, how is your reboot of the late great Jon P. Ogden's "Rimworlds" space opera PBM coming along? I was reading an old posting of Jon Ogden's a little earlier, today.

For those that don't know what reboot that I am talking about, here's a snippet from an earlier issue of PBM Unearthed featuring Luty and his handsome mug.

   

[luty]

100%. I really like this game and I also agree with you on every single point about the fiddly - the POINTLESSLY fiddly - contortions to do fairly simple things. 

As for the reboot....it continues to eat cycles in my head. Someday.

[Brekk]

Thank you all again for your input, I really do appreciate it. I still have a lot to do with Alamaze. I know the interface isnt exactly where we need it to bring more players it, and the initial startup is still confusing for new players. The next update I hope to work with UncleMike on to see what we can/cannot not do. I will share a little of things that is being worked on in conjunction with the current Alamaze and that is We are working to make a new engine able to run Alamaze. Using things like your finger to move troops etc.
Some of the items we have on this list I suspect will not be doable others I hope will be doable.

John

[Wookie Panz]

Thank you all again for your input, I really do appreciate it. I still have a lot to do with Alamaze.  I know the interface isnt exactly where we need it to bring more players it, and the initial startup is still confusing for new players.  The next update I hope to work with UncleMike on to see what we can/cannot not do.  I will share a little of things that is being worked on in conjunction with the current Alamaze and that is We are working to make a new engine able to run Alamaze.  Using things like your finger to move troops etc. 
Some of the items we have on this list I suspect will not be doable others I hope will be doable.

John

What an enlightening conversation this has become.  Thank you all for the wonderful input.  I had never heard about Robert and his work as a programmer of Alamaze.  Robert your work has certainly passed the test of time!