Jump to content

PiotrW

New Members
  • Posts

    4
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

PiotrW's Achievements

Combat Commando

Combat Commando (1/9)

2

Reputation

  1. Replying to my own last comment, the game I mentioned was most likely Chris Crawford's „Easter Front 1941”. As one could buy the source code of the game in the early eighties, I wonder if and what impact it had on Sid Meier's design of this game...
  2. I can't say I understand very well how AI works, as most of the logics and formulas I've just mechanically transcribed from the disassembled custom bytecode. From my limited understanding AI is basing its decisions based on several "strategic level" maps which stores information which side has advantage in which area of the map, and where valuable points of interests are locations. Then for each unit it takes into consideration its own strengths and weaknesses to make the decision whether to attack, defend or move, etc. I guess this high level description would match also other war games created at that time. I vaguely recall seeing similar logic in an annotated disassembly of another 8-bit war game (maybe by Gary Grigsby???). As to calculating during player's turn, the game is almost constantly "updating" units one by one (in Crusade in Europe, I thing about three units for every 30 minutes of game time). So if you're not touching keyboard the units may attack or retreat on their own. Though only units under computer's command would be controlled by the aforementioned "AI". Cheers!
  3. Hi, Recently I was entertaining myself during my daily train commutes recreating an "engine" to play Atari versions of old Sid Meier/MicroProse Command Series games - "Crusade in Europe" / "Decision in the Desert" / "Conflct in Vietnam". As the "engine" started more resembling original games, and as I started losing momentum writing it, I've decided to "publish" it, so that maybe someone find something interesting in it. The original game was written in combination of assembly, ABC Basic and some internal MicroProse programming language, and I was manually rewriting it in the Go language. Because of it there are most likely many bugs lurking in the game logic. Also there are many features missing from the original game, such as saving/loading, intro, sound and music, etc... One feature that I felt like adding was handling the GENERAL command, which was lacking in the Atari version of the game because of memory limitations. You can find the source code here: https://github.com/pwiecz/command_series and you can download binaries for Windows or Linux here: https://github.com/pwiecz/command_series/releases - you still need a legally obtained ATR image of the original game to play it.
  4. Hi, I've been trying to reverse engineer "Crusade in Europe" semi-recently and I've found this thread which seems to contains similar finding us I have. I've managed to find a bit more information about this "inner" script language. I'd guess it's a bytecode being a result of compilation of internal Microprose programming language mentioned here: https://www.atarimagazines.com/rom/issue3/interview.php Implementation of bytecode functions are inside SIDTRAN.OBJ flie. First part are memory offsets of the functions and later there are machine code implementations. Those functions range from standard stack language constructs: PUSH, POP, ADD, MUL, ... to higher level constructs such as various JUMPS, to opcodes implementing FOR LOOPS, to opcodes that seem to be specific and common to all the Command Series games (Crusade in Europe, Decision in the Desert, Conflict in Vietnam). The opcodes that are game specific opcodes, that I've found so far are: find unit or city at specific coordinates count number of adjacent units of given coordinate compute some kind of evaluation function for a coordinate The last of those functions is quite complex and I dont't follow its logic very well. My limited understanding is that: for each hex adjacent to given one, it computes four element bitmap: is_there_enemy unit there is_there allied unit or "good"? terain there is there an enemy unit at either previous adjacent hex or next adjacent hex is there an allied unit at either previous adjacent hex or next adjacent hex it treats this 4-element bitmap as a number [0;15] and looks up a number (score?) [0-5] in a hardcoded array for given bitmap it counts how many of each scores appeared among six adjacent hexes it return sum of coefficients for all [score_value, score_count] pairs Coefficients seem to taken from HEXES.DTA file (at least that's what I found in one case). Probably it may use different coefficients for different orders or other factors, but I couldn't verify it. I don't know how to progress further. My initial plan was to understand and rewrite the whole logic in a higher level language, but I seem to lack skills that would allow decompiling this custom language to a more understandable format. Later I thought that maybe I could create an engine which would allow playing games using modern controls and maybe modern UI. It would consist of writing interpreter for this custom bytecode and writing a UI around it. Unfortunately, lately I have pretty limited time for this, so we'll see. Maybe I should just ask Sid Meier for the source code? Best, Piotr
×
×
  • Create New...