Working on Battle Tech

MD>>>>>> 6. A 3D spinner is needed, which will be shown when you enter
MD>>>> Send it, we’ll see! In principle, there is no need for more than 128*128 -
N>>> For now it exists only in theory, on paper.
MD>> Get away with Alex Shashkevich, and think about
MD>> this together - the two of you will find the best solution.
A> There is nothing to look for, let the one who will do it look for it. If something can't
A> then let it scream. :) We'll help. And I will do it, as I understand it, myself. ;)

This is where you are wrong! Since there are several people who know how to do one task,
then you need to listen to all points of view and choose the best from each opinion!
And there is no need to be greedy - everyone wants to work! ;) And some of our coders are already unemployed - we need to look for something.

MD>> We had a hell of a coder here (his work is presented in the
MD>> supplement to Miracle magazine #3), so he says that shaded
MD>> vector graphics work faster than wireframe graphics! How? Than
MD>> wire! :))) And this was proven by another coder.
A> I could prove the opposite. But I won’t go into details. I will say
A> that he is mistaken. Explain? I'll explain in 2 words. When
A> polygons are painted over, then when calculating the sides (well, between which
A> dots must fill the line of the figure), then they are calculated using exactly the same
A> formulas as lines. At this stage they work the same way. And when
A> the fill begins to fill every line of the object, then the usual line
A> jumps forward, because she just needs to put a point, and not crawl across
A> the screen and add bytes... But in order to bring the matter to its logical
A> end, I’ll say: in some moments, filling can(!) work faster,
A> but these are usually very rare cases.

I won’t argue, because I don’t know much about this, but I’ll just say that I trust that guy (PSV) 100%! Perhaps he used some kind of algorithm.
Try to crack his work in the appendix to our magazine Miracle #3 - maybe
something will become clearer.

N>>> Yes, one more thing I would like to know, what language the game will be in?
MD>> Hmm. I think it’s in Russian.
A> And I think it will be possible to compile a library of words and sentences in the form of a
A> text file. And the Poles (and not just them) will be able to translate their language into
A>. :) What might she look like? And like this for example:
A> #0a2b{Mission completed commander!|}
A> #0a2c{Yes sir!|}
A> Where 0a2b and 0a2c are the message number, and in parentheses the message itself, where
A> "|" this is enter. Well, the program gives the command: print there and there
A>line like this... :) I really don’t know what to do with adventure... After all
A> the user will be able to look at it, but you can come up with something. :)

In the sense of looking for its address in the table by the message number? It is quite possible,
although translators will have to solve the problem with memory, because the same
message in different languages ​​can take up a different number of bytes. What about
protection?

A> ─────────────────────────────────────
A> Hurray! I got 2 books! "Way of the Warrior" and "Battle". I looked at the pictures
A> of robots...

Excellent! Already 5 have books! Just rulez. Now read them to make it clearer what the bazaar is about ;)) For some reason, everyone mostly talks about “Battle”.
But this will help to discuss ALL parts of the game at once, because they are all
present in it.

A> Uuuuuu... Artists! You're not very lucky! :))))))) Urgently
A> I'm looking for a loss where I will scan.... :) That's it. See you later... ;)

By the way, who will draw what? Sergey Stepanov focused on graphics for the adventure game and drawing all sorts of menus. It seems like all the coding responsibilities
have been distributed, all that remains are the graphic ones.

MD>>>> Okay. Let's then discuss the theory of our 3D map. How
MD>>>> will it look from both the external and internal point of view?
O>>> Well, with the appearance I thinkthere will be no problems :) an example of this is Black
O>>> Raven II
A> By the way, a good example!!!! After all, there is 3D and plus everything is real time!!! :) So,
A> we’ll probably stop resisting and decide on the 3rd day.

We got it, devils ;)))

MD>> This is understandable. Moreover, if the base expands its capacity, then it
MD>> must increase in size. And if something interferes with her in this, then
MD>> warn the user to remove his robots.
A> Or an enemy, or a mountain, or something else... :)

Otherwise, there will be no development of the base, and it will work in the same rhythm.

MD>> It looks like we don’t understand each other! In my understanding, a 3D map
MD>> is printed in 2 stages - first the landscape is drawn, and then everything
MD>> on top. And a 2D map is when 1 cell on the screen = 1st sprite
MD>> of a certain size, whose parameters in memory are set by control
MD>> bytes.
A> It’s the 21st century. The time of laser squads and lastattles is over. People need to be interested
A>! If I can't do it at a decent level, I
A> will raise my hands up and say, I give up, you were right... And only then!
A> Spectrum is a sea of ​​untapped possibilities! :)

Don't you dare!!! ;) There’s too much hanging on you to give up or start all over again!

MD>> You don’t want to close this question ;)Okay, let's
MD>> decide on the name!
A> Let's leave this question closer to the end of the project...

The topic is closed until the end of the subject.

O>>> an insult will be said... the name should be tough (combat)! we
O>>> are fighting robots - not peasants who are fighting against the slave-owning
O>>> system for freedom :) Sorry, I couldn’t resist...
MD>> Well, we will have peasants too - we can’t go anywhere without them ;)))
A> Peasants?????? At 3? century? It seemed to me that they were eating synthetic food there
A>. :)

Don't forget that technology has fallen into decay, much has simply been forgotten, robots
have been fighting for 300 years or more! Therefore, whose side the peasants will be on is one of
the main questions for the command.

MD>> And this is something else, and IMHO - hemorrhoids! We have a real strategy,
MD>> which means the user must be given complete freedom of action! Wherever
MD>> wants, he will build it, even in a cave... Damn it, think about memory
MD>>!!!
A> Let the user think about it! We are already in the 21st century... 128 kb is no longer relevant.
A> We need to give gamers an impetus to upgrade their machines... Otherwise, those who write games
A> are focused on the majority of 128 machines, and their users look at how they have
A> and so everything works, well, don’t upgrade...

Gamers upgrade to iP in order to hack Quake :(((Thereforeusers
do not need to be touched. I know very well what kind of overclocking they are!

MD>> Just wait, Oleg - we haven’t decided on anything :((( As for the
MD>> adventure - I was thinking... Is it even worth making this
MD>> sophisticated action show in chunks? I mean, will
MD>> be beautiful? After all, it’s this kind of engine that will take an immeasurable amount of effort
MD>> - display everything with pixel accuracy. They're trying to dissuade me - like
MD>> make a regular adventure game, but with animated inserts. WHAT
MD>> say?
A> I'm for it. New breath in the adventure style. Plus, in the background (on the GS
A> example) environmental sounds are played... :) Well, how?

Okay, you can try. Sergey suggested making this display not in chunks, but in smaller sprites, and when displaying them on the screen, I
will add that the background will still have to be made not with pictures, but with colored chunks, so that they take up less space.

A>>>>> And there, in fact, there are no restrictions on the range
A>>>>>, as it might seem from the beginning. -128 to 128. That is
N>>> Increasing the screen, loss of memory speed
A> Imperceptible.
A>>>>> disadvantage: there is no promising conversion But I think for
A>>>>> a simple rotator and not much andneed to... :)
N>>> Somehow it doesn’t look full
A> It’s enough to display weapons and robots in the database. Because there, even if you do
A> perspective, it won’t be noticeable! Therefore, to increase speed
A> it can be discarded! But in 3D action you need a full-fledged one - I don’t argue...

I agree. Still, you'll have to do the battle in the robot's cockpit using vector
graphics. Denis, can you handle it? ;)

N>>> By the way, you can borrow a lot from there, for example
N>>> painting a polygon with a texture, although I have a faster one, but it
N>>> eats up memory.
A> I need to write my own cool one too. :) Well, very cool, to
A> the latest technology... :)

Don't be distracted from the main task! And she is really the main one.

MD>> Talk to each other, discuss everything, and then show us
MD>> the best option. It’s not like “I could”, but more specifically!
A> Give me the address, otherwise I’m trashing all my previous letters, because... disc
A> is not rubber. :(

And you allocated a separate disk for netmail! If it’s not enough, then another one. That’s what I did
once...

A>>>>> I took the strategy and perhaps the 3D part as part of the load (well, where in
N>>> That is, as I understand it, these are the strategic brains of the computer.
N>>> I grabbed it pretty well!!!
A> I can share the 3D part. Because in the strategy and soThe amount of work is quite large... A
A> I grabbed it because no one would take it. :)

You yourself know how our people get promoted ;). Now there are people - there is no
work.

N>>> So, I still don’t understand, do you want to do the whole action in 3D, or
N>>> just a map? Like in CV2 or like in LAST NINJA 2? And it’s so loud
MD>> As far as I understand, no one understands this :( Each to their own...
A> Like ChV2!!!!! :)

Do it, show it. ;)))

N>>> the word '3D engine' is just like on a PC :) And in general, the concept of '3D engine' is associated
N>>> with TOTAL ECALIPSE 2, AWAKEN, HARD DRIVE.
A> It will be in a 3D action game.

Only it needs to be much more detailed and drawn! A robot is not a rude machine or a ship! They are basically humanoid, which means everything should move, arms
legs and heads, and beautifully.

N>>> If I can help, to the best of my ability (and I also drag in 3d)
A> Hurray! Let's join forces! :)
MD>> I say again - run away, and take Denis with you, and discuss
MD>> everything.
A> Address! ADDRESS!!! :))))))

=== Cut ===

MD>>>> be very beautiful, _FAST_ and convenient!
A>>> Well, you have to try.
MD>> You, as the author of the strategy, should offer principles
MD>> for working with the map!
A> Eeeeeee.... How can I say this more correctly. If I do, then
A> should I share the principles of implementation with everyone? Those. does anyone need this
A>? What's the point of me explaining everything? IMHO, how everything will be done
A> these are my problems, and others should be interested in getting it done
A>... :)

The rest, as coders, offer their point of view from the coding side. Yes
and I’m interested not only in getting it done, but also HOW! Okay, since you
don’t want to be disturbed, then we won’t ;)

MD>>>> Since you can write 3D engines, then why not take it?
MD>>>> After all, few people can make them! For example, I don’t know how to (rotate
MD>>>> a sprite in my editor is a no-brainer! ;)
AS>>> Let’s see. Maybe I'll do the job 50/50. Those. both strategy and 3d.
MD>> Just don’t do both by halves ;)

A> There is a suggestion: Make 3d action as a subpart of the strategy. Ie
A> When robots (teams) collide, they enter into a 3D battle. And the strategy
A> loads the 3d action part and the player proceeds to control the robots...
A> Well, off we goheat! :) IMHO this is much more interesting. The continuity of the battle will
A> be felt... :) This is what has been done in many turn-based
A> strategy games on the PC. Unit combat has been moved to
A> a separate part. Those. everything will depend on the player. And not like LB where
A> when robots fight, it is not clear by what standards their battle is measured and
A> why one robot kills another. The weak always has a chance to defeat
A> the strong. And this chance must be given to the player. Otherwise, when fighting in LB, nothing depends on
A> the player. Well, based on this, it will be possible
A> to organize teams of robots with only 5-8 units each...

A very good proposal! But this should be disabled in some setup, otherwise it can get very annoying! Maybe the user is a good strategist, but the reaction is not right...
By the way, yesterday I saw Mech Warrior 3 on PC, and this is exactly what I wanted to see
battle in the cockpit of a robot! Obviously, not with such graphics, but it’s roughly similar :) True, the overheating is quite unrealistic there - the machine turns off too often, and the ammunition quickly runs out. According to the books, there were enough of them almost until the end of the battle, and
only the robots of the Inner Sphere suffer from overheating, and each in their own way.
Imagine HOW happy the user will be when in the middle of the game he can produce robots
that almost do not overheat!

A>>> simpler: think through everything possible and make 1 large one (3-4kB)
A>>> shipping block which will contain all the data. But we need to make them public
A>>> first.
MD>> Of course. So far we have not discussed how we will work with the data.
MD>> After all, if you do it as is customary in all sorts of Dunes, Warcraft, i.e. at
MD>> each level you are given something new and not interesting.
A> I agree. The game should not proceed in levels, but in one action. Without
A> any levels there... That is. there will be levels there, but they will be connected
A> by the scenario and will go as a continuation of the previous one...

no comment.

MD>> But here difficulties immediately arise:(
MD>> 1. It is necessary to make a very powerful AI of the computer so that it can not only fight professionally (and we are fighting with just such an enemy, and our commander - Grayson Carlisle is only 20
MD>>years old!), but rebuilding damaged/destroyed buildings, warehouses, etc.
A> As for AI. As one programmer said, at the present stage of
A> computerization it is still difficult to create AI, but to give the impression to the
A> player that the computer has amazing AI is possible... That is, to make the appearance of
A> good AI.

But after all, You can write something like this, right? ;)))

MD>>>> In my engine for Robo #2 it’s done something like this... But there will be real time
MD>>>>, only quasi...;)
A>>> Damn... There is almost no difference between UFO2 and CV in terms of working with the screen.
A>>> Everything will be OK! We will have 1 unit moving!
MD>> ??? Why ??? I actually wanted to unite them into groups...
A> Nothing is stopping you... But they will not move en masse, as in real time
A>, but one at a time.

But this is not rulez! Imagine that I need to transport 40 robots for
the decisive battle. So wouldn't it be a bad idea to send them one by one? Or am I again
misunderstanding something?

A>>> Well, landscape animation is not a tricky business.
MD>> It depends on what method of working with the map you choose!
A> If you update the screen every 3-4 frames, this will be normal. Well, the way
A> is to choose the fastest one. This already depends on the encoder! :)

I suggested to you what is more convenient in my opinion, but of course it’s up to you to decide.

MD>>>> By the way, you need to decide on the type of strategic game -
MD>> IMHO, this is not very interesting! Warcraft 2 infuriated me after the World War II.
MD>> This is why I propose making satellites/anti-satellites! If you choose
MD>> the LB principle, then we will make anti-satellites and hang them above ours
MD>> make anti-satellites and hang them above ours in order to confuse opponents.
A> We do it as in UFO2. If the enemy falls into the range of vision of our units,
A> then we will show it. If not, then hedisappears. Well, the map remains open
A> if we went through it. In short, the most profitable option is as in UFO2. :)

Although this is more realistic, IMHO it is not interesting. What do others think?

A> It can also be done for Hayes modems. Fortunately, I learned how to program them
A>. Well, the modem driver for the game can be selected from
A> MMD2.20. This is already a standard. And write in addition for haes (although I have
A> already written). So this issue may fade into the background. The
A> package includes drivers for CDOS, VICOMM, XTR and
A> HAYES modems. Luckily I have them all. :)

That's good. Then immediately think through the coding of the strategy for a modem game,
so that you don’t have to redo it later, like I did with SED - in order to
redo it for the mouse, you have to write all the procedures for working with sprites again ;(

MD>> Let him fuck off the music and free up the memory! Nobody listens to IT anyway
MD>> Or let him find a professional a musician
MD>> who will write good, not boring music for him. There is always a way out,
MD>> you just have to look for it and sacrifice something.

To VM: ^^^ That’s what they meant!

A> Isn’t that what I meant. Is there enough memory to keep the stock of units? And if
A> we make the game 3d (which will undoubtedly raise the game to a good
A> level), then there may simply not be enough memory... :(

Why do you think that units will take up a lot of memory? IMHO the maximum is 5
bytes per snout, and even that is a bit much...

MD>> You didn’t understand me. Under 256-1024 all the possibilities, but under 128 without
MD>> the same music, any effects, etc. But you also need to use memory optimally
MD>>, and you still insist on 3D ;)

A> Understand! We want the best! Time does not stand still. And the time of Laser
A> Squads and Last Bottles ;) has passed! After CopperHeels
A> did UFO2, somehow I don’t want to go down to a level below it... :)

Why should we go down below it? Was ChV worse than Ural Federal District? But there
2D graphics!

A>>> 128*96=12288 bytes (if there is 1 byte per 1 card cell) Well
A>>> it’s quite normal. It fits into the page.
MD>> So this is if 1 byte is enough. Otherwise, you'll have to move it into the main memory.

A> Eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeaaaaaa with with With with the main memory you don't need to move anything... It
A> is designed for the current code! According to my considerations... Let
A> be the code in the main memory, and let us insert pages with data (maps, sprites, etc.)
A> into pages. If we start scattering the code across pages, then
A> a situation may arise that the code and data will end up on pages and
A> access will be denied. It would be possible to swap pages<-->main memory,
A> but this is machinetime!

There’s no need to swap! If one page is not enough for a map, then take
another one.

MD>> That's for sure! Here again I received a whole set of letters from you :)
A> Yeah... And how glad I was when I sat down to answer all this... :)

And I’m so glad to answer after a wild delay, when a lot of letters had accumulated ;)

A>>> @Via 2:467/81 @20000107.225749.UTC+2 T-Mail 2607.DOS
A>>> @Via ifmail 2:467/10@fidonet, Fri Jan 7 2000 at 23:18
A>>> (2.8f)
MD>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's where your
MD>> letters were lost :(((
A> I'm explaining the situation. We have in Odessa, Fido is gated to the Internet through one
A> very cool provider. At one time, a fidish person
A> worked there, who arranged the whole thing. But then he had a fight with his boss and
A> left... But the admins don’t even go there without supervision, because if they start tearing out the feed, then they will. you will have to reinstall everything
A>, and this will entail stopping the work of the company
A> for at least a day. And here is one very cool hub that takes away mail from the provider, likes to reconfigure its configs. butThanks
A> to this state of affairs, we have practically no limits on
A> transferring file volumes... The company is cool, but there fidosh things
A> are not recorded... Here... :)

How everything is launched ;)

MD>> Why??? After all, we have at our disposal combat robots that
MD>> are the size of a 9-story building (some). These will go anywhere ;)
A> So... You describe to me completely point by point everything that concerns the strategy and
A> what should be implemented there. We will think about how the map will
A> be organized... :)

Because. there were many new proposals, then I think it would not be amiss to repeat the requirements once again:

Strategic part.

1. a wide variety of landscapes, such as mountains, forests, deserts, plains, rivers, etc., so that it is as close as possible to real life. Moreover, we will conduct combat operations on different planets with different climatic conditions.
2. the possibility of capitulation on the part of both the player and the company with all the consequences.. (reputation, “sucker” missions with meager payment from the employer, etc.)
3. Bases: engineering (development, research), technological (production,
repair), agricultural (even in the 31st century, warriors want to eat! 2 types -
raising livestock, and wheat. On different planets, with different climates, the name will simply
changeproduction, or the impossibility of such.),
radio navigation (communication with far-gone troops), barracks (accommodation,
training of soldiers, technicians, doctors), warehouses that can be destroyed by the enemy,
neutral cities, towns. As a consequence, hiring/firing people to maintain the bases.
4. types of troops: obviously combat robots (of different tonnage, speed,
power), infantry, tanks, platforms for “dragging” the remains of robots from the battlefield into bases, satellites, AQIs, shuttles and T-ships (the user will not be able to produce them until he successfully completes the operation to find a Star League warehouse with new robots and most importantly - technology lost due to constant wars(he will copy the information and order a new T-ship or shuttle) Until then
he will be content with 1 (!) shuttle and 1 T-ship. Here is the solution
to the problem of where to put the units after the victory - there will simply be nothing to take them away from
the planet :)
5. a large number of resources that are present in real battles and require
their acquisition: walkie-talkies, computers for setting up robots, simulators for training
robot drivers, ammunition, armor for robots, explosives for infantry,
fuel for shuttles, medicines, spare parts,
If something is missing, then subordinates must demand purchase. If not,
then things may come to a refusal to carry out orders, orsabotage.

6. time of day, depending on which the illumination of the map will change.
7. trade with other planets (with a list of buyers) to earn
money, as well as with special achievements, purchasing drawings of new, more powerful
robots. The user can decide whether he will send his only shuttle "Phobos" into battle
or whether he will successfully trade it.
8. Traces from robots that will disappear as soon as the player
who left them starts walking again.
9. Detailed repair of cars is not easy, as in Last Battle, when
protection is restored, namely reporting on damage, repair time, etc.
10. Animation of stationary objects - bases, warehouses, cities.
11. detailed accounting of the player's reputation. In the 31st century, people are very sensitive to the word honor! Therefore, if a user destroys peaceful cities (even if they stood
on the road of his robots, and there is no way to bypass them), or wages a vile war, then send punitive troops against him, followed by a game over.
12. Alex, think about storing generic cards for your car so that they don’t take up precious disk space! If it still doesn’t work out, then draw about 20 of them, and
then just change the names and conditions on the planet. But the first one is better ;)))
13.

This is something that only applies to strategy. Now about the adventure:

1. constant connection (for the duration of the scenario) with the strategy. Those. wonbattle,
think about something. And when the scenario ends, the missions will simply be
generated, and only the strategic part will remain.
2. beautiful and convenient arrow interface.
3. a large amount of animation.
4. hot buttons for the main functions.
5.

Manager - still full 0. :(((

Battle in the robot cockpit.

1. great dynamism.
2. convenient controls
3. detailed graphics.
4. at least some opportunity to lead your troops. Window for reports
of other warriors.
5. visual representation of available weapons (with choice) and damage to the robot.
6. radar, distinguishing between friendly and alien
7. ability to zoom in on the landscape in the cursor (to better see distant
robots)
8. participation in infantry battles with tanks
9. ejection of both the player and computer-controlled robots
10. etc.
11.

Well, maybe I went too far with something, but it’s better to think about everything right away than to add later. Therefore, we are waiting for improvements, criticism, etc.
If I remember something else, I’ll write.

A>>> Well, let’s try :)
MD>> Okay, we’re waiting.

A> Well, for this we need at least. rough working material... I won't show everything on
A> in the form of crosses and toes... Well, or at least
A> I'll try to draw it myself(fortunately, I have the rudiments of skill and taste :) and
A> to animate myself... :)

First, you need to decide on all the sizes of the sprites, and then give
tasks to the artists! You, as the author of the strategy, have not yet proposed anything on this subject ;)

A>>> In real time you can use a grid. But this local area is needed, but on the spec
A>>> there is no such thing (yet). But the very fact is that it is possible. In general, for the spec you need to connect
A>>> EtherNet. LAN cards are very
A>>> cheap compared to modems.
MD>> It is necessary to involve hardware people in this business, but again there are problems
MD>> - people must live at least in the same house, or run to each other with
MD>> computers and monitors :)

A> Gradually this is turning into a global project. :) Not only
A> a new game will be released, but also a new device and a new standard... My hands are already
A> itching... We need to end the session... :)

And don't tell me! I warned you about this right away! ;))) The game will be a cult one!

MD>> :) The main thing is that it is beautiful! You need a wire and
MD>> painted twisting of objects, but only along the y axis, so as not to slow down
MD>> the procedure by processing other axes.
A> You don’t have to explain it to me... :))))) My blood is thoroughly saturated
A> with a sense of optimization. ;) And when I heard demands from you, then in
A> my brainI immediately threw away all unnecessary things. Including rotation
A> of extra axes. Those. I immediately imagined how the algorithm works. Okay, this is already
A> starting to resemble advertising itself. :)))))

I looked at the requirements for the strategic part, and thought, isn’t it a lot of di
Will you be alone? ;) You write both a strategy and a vector engine. There are a lot of coders, everyone wants to work! ;) Maybe you could just run off with each other, discuss what he
would look like, and choose the less busy person? Denis Ognevsky is eager to work with 3D engine.

O>>> Wow! I'm for Optic Nerves Team! :) OTN - it sounds! :)
MD>> And if Alex comes up with something even cooler, will we
MD>> change the name every time? ;) Then NO TEAM Team is better.
R> And Freedom is better. :). slaveholding system for freedom :) Sorry, I couldn’t resist...
R> Nothing. Just why we (particularly I) chose this name: tell me -
R> what could be more valuable than freedom? And what could be better, more valuable and, if
R> you want, 'sweeter' than freedom? (The priest immediately shouted: grub, grub...
R> :)))))

:)))) But he’s right! And here you are talking to me about some kind of synthetic food
;))))

MD>>>> By the way, you need to decide on the type of strategic game - either as in
MD>>>> LB, i.e. everything that is open is deceptive, or like in ChV - everything that
MD>>>> is open is visible.
R>>> I am for the second :)
MD>> Me too - it’s much simpler, but not as confusing as in LB :)
R> Well, that’s all - 50% shareswith us! :). :)
MD>> Yes. They will be abstract, i.e. You seem to have released it, but you don’t
MD>> see it - why create unnecessary problems? It will just appear
MD>> the opportunity to trade and receive schemes for new robots.
R> I see. This kind of upgrade. I made such an upgrade on some base,
R> built a shuttle - and, let’s say, every 2-3 minutes you have
R> a new robot circuit, did I understand correctly? :)

As for the diagram in 2-3 minutes, you missed it! ;) A user can play the entire game up and down, but still not reach a decent level. And who would sell robot circuits to a child, especially powerful ones? Regarding shuttles, the only one that exists initially can be put on sale. You will see him
only in the video clip when you are leaving the defeated planet :)

O>>>>> Promising anything is stupid IMHO! you need to try to the best of your ability and
O>>>>> only on the basis of this you can draw conclusions... I
O>>>>> personally I will not promise anything, since I have not
O>>>>> written anything like this before... but I am sure that I will think it overThis option is also possible!
MD>> SOMETHING, I forgot, WHAT were we talking about?
R> In my opinion, about the 3D engine...

:) And so they forgot. But it’s a smart idea :)))))))

O>>>>> I don’t think so, since it’s one of my old projects and I
O>>>>> just finally decided to finish everything... the genre is RPG, it was made in the
O>>>>> style from the first person (in the sense of movement)
R>>> You can also connect this project...... :))))
MD>> So it’s already an adventure yes! Or did I misunderstand something?
R> I meant the 2nd project (separate from BT) of our team. :). :)
MD>> Unfortunately, yes. I hope Arthur will read “The Battle” and be able to clarify something
MD>>.
R> That would be good...

So you read it too, and offer your own! Now you and Alex have the book between the two of you ;)

R>>> Max, we’ve got the gate down again here :(. That’s why the echoes don’t work. Please
R>>> tell everyone to throw soap (for now, I hope :(
MD>> So far (IMHO) no one has written in the echoes, at least I haven’t seen anyone there
MD>>. So you haven’t lost anything :)
R> On the one hand this is good, but on the other... :(

MD>> And the introductionshould be accompanied by cosmic music, so that the spirit
MD>> of the battle can be felt :)
R> Let's try...

Come on, otherwise you are our only musician ;)

MD>> But IMHO it is better to write it after this very
MD>> introduction is ready, although according to current standards :))))) the muse should be
MD>> synchronized with video.
R> I don’t argue, but it’s better to write a muse when you know the plot (the same
R> introduction).

You can still add music to various parts of the game. By the way, can you handle the sound
effects?

R> And about the standards :) - Priest and I once wanted to make a demo with
R> the name STARTUP and MIDITATION. :) Here. 8-)

:) And how?

R>>> In general, catch it - I advise you to listen in real life :)
MD>> So I just do everything on it! The emuls don't show on my monitor
MD>> :)
R> Oh! Your man! :)

Atozh ;)))

MD>>>> Definitely! People, how fast are we making robots on each side??? I
MD>>>> propose 200 land and 50 flying, because... they are too
MD>>>> powerful...
P> Too much, especially for a turn-based game, I think 50
P> units are enough, the emphasis should be placed not on quantity but on quality, i.e.
P> attaching new weapons, armor, etc. to the robots. Moreover, than

Here I disagree with you! There must be more troops in order to fight, so
fight ;))) It is much more interesting when the troops are large!

P> the more objects on the map, the greater the delay when working
P>, for example, such a procedure as surveying the area with a robot and opening visible
P> robots and objects

This is possible, but for the sake of battles you can wait :)

MD>> Pavel! Why are you silent???? If you don’t want to participate, just
MD>> say so! And it will be easier for you, and for me to send fewer letters.
P> I didn’t write anything because I was in the hospital for two weeks,
P> I was just discharged yesterday.

The question is removed.

MD>> disguise), residential buildings, villages, etc. How can an encoder work with a
MD>> card? I thought about this question for a long time, changed everything many times. But I
MD>> followed the path of a 2D map, i.e. from sprites 2*2. For each cell
MD>> a certain amount is allocatedthe number of bytes - what is there, what robot
MD> is standing and in which buffer to look for its parameters, etc.
P> It turns out that on one cell you can only have
P> a certain number of objects, plus the inefficient use
P> of memory, suppose that in one cell there can be 5 objects,
P> then with the size cards for example 128x64 it turns out 40960 bytes only
P> for items! I did it differently at Technodrom, one cell of the map -
P> one byte with the logical sprite number, plus a table of objects.
P> If there is an object on the cell, then a section is created in the table
P> for it, which stores the coordinates of this cell, the number
P> of objects located on it and is saved the logical sprite number
P> of this cell, and the sprite numbers of the objects themselves. If an object on a cell
P> becomes visible, then the object's sprite number is placed on the map.
P> if it is necessary to hide an object on a map cell, then from the table
P> section of this cell in the object table we take the saved sprite number
P> and place it on the map. This works great in Technodrom.

Alex doesn’t like being told how to do a strategy ;))) But
seriously, I imagined it completely differently! And 5 items are
a lot - two are enough: a landscape and a piece of equipment.

P>So who writes the strategic part?

Alex Shashkevich.

P> Pawel

MD>> with the name!
D> Freedom. Sounds strong!!!

What kind of resonance did the topic cause :)

D>>> Why? This is the same 2D map, only the sprites on it are 3D. Or do you want
D>>> like in UFO?
MD>> Again we didn’t understand each other :( And what about UFO? Do you mean
MD>> additional printing of the 2nd floor?
D> This is a slowdown and a mess...

I agree! But what do you mean by “like in UFO”?

MD>> That’s exactly what I was talking about! Do it like in Crow, and don't beep...
D> That's what I'm talking about.

You prove it to Alex ;)))

D>>> Byte per cell. Or do you think it won’t be enough?
MD>> No, a byte won’t be enough. After all, not only does the program need to explain
MD>> that this is a robot, or the base of one of the opponents, but also indicate its
MD>> number in the table!
D> It’s understandable if you’re going to separate all this bit by bit. And if you do
D> byte by byte? Do you think 255 different options are not enough?

So there should also be landscape sprite numbers and a robot number in the table..

MD>> Why don’t I see anyone in the echo? Are we slowing down again?
D> The session is behind us. There are still a couple of problems left...
D> Currently I am doing an internship at some factory. I'm fixing Spectrums :)

Well, since we've passed the session, it's time to get to work!

D>>> It all depends on the size of the objects. If they are small, then you can
D>>>Flat.
MD>> Denis, I’m telling you too - the three of you run away with Alex and Kolya, and
MD>> discuss everything!
D> What is there to discuss? Let's have some objects...

Alex will scan the robots, then we will need to model them. And what will you
make them in?

A>>>>> Have you read an interview with Copper Heels where he said that he didn’t know
A>>>>> where to shove his CV at 128k?
D>>> Have you seen how he writes?
MD>> And how does he write?
D> Something like this:
D>
D> label1 ...
D>
D> ld a,(nnnn)
D> cp 0
D> or a
D> jr z,label2
D> jr label1
D> label2 ret
D> ...
D>
D> As if he were writing in some C.

Then it’s clear where his memory goes...

D> Actually, if you look at branded coders, they are cool programs
D> managed to get it into 48k. Our scale may be different, but still

Correct! 128 and no extended machines there! If there is additional current opportunities.

27 Jan 00 в 14:19 st...@overta.ru Subject All
04 Feb 00 1:07 PM Posted st...@overta.ru:

03 Feb 00 21:27, Max Dudnikov wrote to Denis Ognewsky:

MD> Lucky, but we still decided to introduce it in April :( Limit per day -
MD> 10 minutes, every extra minute - 30-50 kopecks...

And what kind of modem games after that?

... no day without speccy!

MD> Already? ;)

Well, if people who don’t care are gathered here... :F~~~~~~~~~~~ then what am I doing here :(
If a person doesn’t care about the title, then the question remains: doesn’t he care about the subj? :(
IMHO it didn’t go beyond tropeology :( if I don’t see
the script in the near future, then I will also think about the expediency of the subj!... :( And my participation in
him...

MD> Sincerely, Darth Vader/ Orion'2000 03 Feb 00

C ya in nE> ASCENDANCY HQ: ascen...@mail.ru http://www.ascendancy.homepad.com

MD>> 10 minutes, every extra minute - 30-50 kopecks...
K> And what kind of modem games after that?

So not everyone will/has a time slot! Now those who don't have it will have to test the subject :-)

P.S. Our swapper (ICE'DI GRIZ) received a report for January conversations inside the city - 2000 extra minutes! Considering the cost for each extra one, you get a lot of money
.. Whoever has such crap (on time) - show us how to deal with it! Please!

P.P.S I haven’t seen any replies on the subject yet, but this is most likely due to our downfall
with mail - even ours, the Chel Echoes, go beyond January 27-29. Therefore, as soon as I see your
letters, I will answer immediately!

With respect, Darth Vader/ Orion'2000 07 Feb 00

O> Well, if there are no-nonsense people gathered here... :F~~~~~~~~~~~ then what am I doing here :(

Why did you get this??? They just screwed a person over (as he understood ;) with the
name that he so animatedly proposed.

O> If a person doesn’t care about the name, then the question remains: doesn’t he care
O> subzh?

I assure you - no don't care!!! He was just a little offended, that's all! Not yet
knowing that almost the majority voted FOR Freedom!

O> :( IMHO it didn't go further than chatter :( if I don't
O> see the script soon, then I will also think about the expediency of the subzh!... :( And
O> my participation in it...

But this is not necessary... From the authors of the subject, on I realized that you and I,
Oleg, are working together, the rest are studying. And the session just ended the other day. Therefore, there is no need to make hasty conclusions, but in the end
you decide. Do you think I like it? ZX]
O> ASCENDANCY HQ: ascen...@mail.ru http://www.ascendancy.homepad.com

Regards, Darth Vader/Orion'2000 08 Feb 00 year

07 Feb 00 13:43, Max Dudnikov wrote to Kirill Frolov:

MD> P.S. Our swapper (ICE'DI GRIZ) received a report for the January conversations
MD> inside the city - 2000 extra minutes! Considering the cost for each

LLC!!!! At $10 a month the minimum works out?

MD> extra, you get a lot of money.. Whoever has this kind of crap (on time)
MD> - show us how you deal with it! Please!

No way. :-( Not entered yet.

P>> work, for example, such a procedure as surveying the area with a robot and
P>> opening visible robots and objects,

MD> This is possible, but for the sake of battles you can wait :)

skip
P>> on a map cell, then from the table of the section of this cell in the table
P>> objects We take the saved sprite number and place it on the map. In
P>> Technodrom this works great.

MD> Alex doesn’t like being told how to do a strategy ;))) And
MD> seriously, I imagined it completely differently! Yes, and 5
MD> items are a lot - two are enough: a landscape and a unit of equipment.

In principle, in Battle Tech you don’t have to do work with objects,
according to the books, robots could not find and attach new
weapons during the battle. Then you don’t need to allocate anything at all to items, everything
then will become much simpler and there will be no slowdowns.

MD>> ;))) But seriously, I imagined it completely
MD>> differently! And 5 items is a lot - two would be enough: a landscape
MD>> and a piece of equipment.

PK> In principle, in Battle Tech you don’t have to work with objects,
PK> according to the books, robots could not find and attach new
PK> weapons during the battle. Then you don’t need to allocate anything at all to objects, everything
PK> then it will become much simpler and there will be no brakes.

It seems to me that working with objects is still necessary, in my scenario there is equipment
designed for transportation, which allows you to do tricky things:
For example: taking out defeated ballistic missiles from the battlefield (both your own and strangers).

_/Always yours, Eduard Puzyno./_

MD>> IMHO, this is not very interesting! Warcraft 2 pissed me off after the World War II. For
MD>> this is what I propose to make satellites/anti-satellites! If we choose
MD>> the LB principle, then we will make anti-satellites and hang them over our
MD>> territory in order to confuse opponents.
R> IMHO one does not interfere with the other. As for the map, I also think that it’s worth making
R> like in StarCraft, and satellites/anti-satellites will just be a nice addition
R> and additional complexity at the same time. Look at StarCraft. :)

MD>> camouflage), residential buildings, villages, etc. How can an encoder work with a
MD>> card? I thought about this question for a long time, changed everything many times. But I
MD>> followed the path of a 2D map, i.e. from sprites 2*2. Each cell
MD>> is allocated a certain number of bytes - what is there, what robot
MD>> is standing and in which buffer to look for its parameters, etc.
P> It turns out that on one cell you can only have
P> a certain number of items, plus the irrational use
P> of memory, let’s assume that one cell can contain 5 items,
P> then with a map size of, for example, 128x64, it turns out 40960 bytes only
P> for items! I did it differently at Technodrom, one cell of the map -
P> one byte with the logical sprite number, plus a table of objects.
P> If there is an object on the cell, then a section is created in the table
P> for it, which stores the coordinates of this cell, the number
P> of objects located on it and is saved the logical sprite number
P> of this cell, and the sprite numbers of the objects themselves. If an object on a cell
P> becomes visible, then the sprite number of the object is placed on the map,
P> if it is necessary to hide an object on a cell on the map, then from the table
P> section of this cell in the object table we take the saved numbersprite
P> and place it on the map. This works great in Technodrom.

N>>> telephone numbers throughout Russia and the introduction of per-minute payment for
N>>> talkers :(
N>>> == Are you planning something like this?
MD>> Here in Chelyab, they threatened to introduce it on January 1st, but the Duma
MD>> categorically prohibited (for now :(, in view of the fact that this is a violation of the rights
MD>> of disabled people, and not only them. But I noticed that since this ode, traffic from
MD>> has decreased on average by three times :(
D> We wanted to, but it looks like it won’t happen because we have the experience of other cities. For them it
D> didn’t pay off. People practically stopped call.

EP> It seems to me that working with objects is still necessary, in my scenario there is
EP> equipment designed for transportation, which allows you to do tricky
EP> things: For example: transporting defeated ballistic missiles from the battlefield (both your own and
EP> others).

I’m talking about the same thing - there is a cell with a landscape, and there may be one thing on it, either a robot, or a tank, or a “hand” from a robot (as a bonus after
the battle). But this should be in STRATEGY, and not in action (when you’re sitting in a robot)!
Don’t confuse these 2 completely different parts of the subject! By the way, maybe we can also put living people there (on the map)? Was it okay to crush them? ;))

EP> _/Always yours, Eduard Puzyno./_ -+-

*With respect, Max* aka _/*Darth Vader*/_ /Orion '2000 March 03, 2000

_/[TEAM Guitar] [TEAM Babylon #5] [TEAM Gaza Strip-BEST!] [TEAM ]/_
_/[TEAM Hard Rock & Metall - RULEZ!!]/_

EP>> Pavel, don’t forget that in addition to robots, infantry,
EP>> tanks and motorized units took part in the battles.

MD> The fact is that I indicated the MAXIMUM number of units that
MD> should be supported by the procedures in the strategy. Judge for yourself - what kind of war
MD> of 20 units? Of course, there is also infantry and tanks, but still robots -
MD> this is the main thing! Remember the Mercenary Star - how many robots did the troops have there
MD> Kurita? And if he had not agreed to surrender, then what kind of mess would have happened with
MD> Steiner’s troops?! After all, we have a mercenary unit - at first, such
MD> number of troops will only be a dream, but then, after accumulating
MD> experience... After all, it is not necessary to go into battle with all 200! There are
MD> various reserves... By the way, I propose to connect such a sharp increase
MD> in the number of equipment with the location of the Star League warehouse.

I don’t argue, the total number of robots can reach 200 or more.
But battles at the regiment level are something terrible, I honestly can’t even
imagine (maybe because I’m not a coder) how this is possible to do.
I would suggest breaking the big battle into a series of local clashes, where
victory would provide the opportunity to send more powerful troops into battle again,
updating them somewhat.
Unfortunately, I could not get the book “Mercenary Star”, but IMHOmy
suggestion is quite capable of defusing the situation regarding the quantity.
Waiting for comments...

_/04 March 2000 at 12:00 Eduard Puzyno wrote Max Dudnikov/_
_/06 March 2000 at 17:18 I replied/_ _Eduard Puzyno_:

EP> I don’t argue, the total number of robots can reach 200 or more.
EP> But battles at the regimental level are something terrible, I honestly can’t even imagine (maybe because I’m not a coder) how this can be done. I would
EP> propose breaking a large battle into a series of local clashes, where victory
EP> would give the opportunity to send more powerful troops back into battle, updating them several
EP>.

Have you seen the Last Battle? Here there are more than 200 robots implemented on each
side ;) I don’t mean a simultaneous attack by all 200, but in parts.
That is. in one part of the planet there is a battle with 10-15 robots, in another - another 20, etc.
And some will be in reserve. Still, we (as the commander of a mercenary unit)
need to count on the fact that there may be tasks from which the regiment
will not receive real benefits, but will be forced to sign a contract. The reasons may be different - political, a matter of honor, pressure in the end. You, as a screenwriter, need to think this through;)

EP> I would suggest breaking up a large battle into a series of local clashes, where
EP> victory would provide the opportunity to send more powerful troops back into battle,
EP> updating them somewhat.

In principle, this is what should be done. The enemy's points (areas) are determined that are capable of providing maximum resistance (or at least above
average), then for each point a “team” is formed, containing approximately
as many units of equipment as are necessary for victory at a specific point.
As soon as the “teams” are formed, they are sent “to the points” :) and for
for some time, roughly speaking, they are thrown to the mercy of fate, i.e. Each
unit of
equipment operates separately due to its own AI (you can also organize
command AI, if it makes sense). After some events have passed (for example:
after some time, or after the death of a certain percentage of equipment on one or
the other side), the resistance of a specific point is again assessed and
compared with the damaging power of the corresponding command. If the strength of the team
turns out to be greater, the clash can be considered won, and after its end
the team is disbanded into other teams. If the strength of the team
is not sufficient to win, then depending on the resources - either a battle “to
the last drop of blood”, or a retreat, afterwhich the command is updated and repeats
the collision, or the disbandment of the team.

This is so, thoughts about the implementation of computer logic.

By the way, a small thought on how you can primitively calculate the resistance force for
a specific point on the map. For each enemy unit capable of attack,
the resistance force at the desired point is calculated (i.e., what this
unit is capable of, being somewhere far away, if there was an attack on this point);
all results are summed up. We obtain the relative parameter of resistance
for this location.
The strength of resistance for a specific unit can be calculated using the primitive
formula: (attack_strength) * (speed)
Resistance = -------------------------------
(distance) - (damage_zone)

attack strength and so it is clear - how many units of “energy” are knocked out in one shot;
speed - how many cells on the map are covered per unit of game time time;
distance - between the coordinates of the processed point and the coordinates of the given
unit;
damage zone - the maximum distance at which the unit is capable of
firing.
If the denominator is less than zero (the sought point is in the affected area
of the unit), then Resistance = attack_force.

The meaning of the formula is approximately that the farther the unit is, the lessher
resistance (by the time she gets there, it will be too late); but the higher the speed, the greater its contribution to the point's resistance (let's say an attack has begun on a point, and
the unit is already right there, as if it was there).

Thus, the computer can calculate the resistance parameter for each
building or piece of equipment of the enemy, and attack the weakest points.

Example: the opponents have a couple of slow robots with a powerful attack,
and at a considerable distance a certain number fast, weak-attack
robots, and their total attacking power is greater than that of the first two.
Who to attack? If you attack a couple of slow robots that are weaker, then quickly fast robots will appear there, and you will have to deal
with all of them at once. If you attack the fast ones, then you can forget about the slow robots for a while. Thus, we obtain a lower resistance force
which is what this formula allows us to calculate.

You can, of course, take into account the rate of fire, different types of weapons and other things,
but these are subtleties. But it will be interesting to play with such
a computer opponent who does not constantly break into the same place,
but makes separate effective raids, the goals of which depend only on
how the player himself has positioned his troops...

With the best, Eduard!

... I'll buy a moonshine still. intermediary phone number02.

MD> one thing, either a robot, or a tank, or a “hand” from a robot (as a
MD> bonus after the battle). But this should be in STRATEGY, and not in action
MD> (while you are sitting in a robot)! There is no need to confuse these 2 completely different parts of the subject! By the way, maybe we can also put living people there (on the map)? So that
MD> they could be crushed? ;))

EP>> where victory would provide the opportunity to send more powerful troops back into the
EP>> battle, updating them somewhat.
DD> In principle, this is what needs to be done. The enemy's points (areas) are determined
DD> capable of providing maximum resistance (or at least above
DD> average), then for each point a “team” is formed containing
DD> approximately as many units of equipment as are necessary to win at a specific
DD> point. As soon as the “teams” are formed, they are sent “to the points” :) and
DD> for some time, roughly speaking, they are thrown to the mercy of fate, i.e. Each
DD> unit of equipment acts separately due to its own AI
DD> (you can also organize a command AI, if it makes sense). After
DD> some events (for example: after some time, or after the death
DD> of a certain percentage of equipment on one side or the other), the resistance of a specific point is again
DD> assessed and compared with
DD> the damaging power of the corresponding command. If the strength of the team turns out to be
DD> greater, the clash can be considered won, and after its end
DD> the team is disbanded into other teams.

/Skip/

IMHO, this is better attributed to the AI ​​of the computer, but not the player. Those. the user himself must
lead the battles, and not rely onassistants, although they too must make
a real contribution to the battle. And as for large-scale battles... Of course, this is a rarity, but anything can happen! Missions are different. There is also such a thing as the GBP (Combat Losses Group). I quote “The Price of Glory”, p.358:

“The concept was based on the fact that in battle the robots of one
unit reach critical levels of damage at approximately the same
time. For example, a company consisting of a dozen machines can fire forever
(in military terms - about 3-4 minutes), and during this time none of them will be
seriously crippled.
Then, a few minutes after the start of the battle, one robot will leave
the game. Almost immediately another one will follow it, then another one or two. Within
thirty seconds, half of the combat power of the company will disappear.
This happens because even light robots must accumulate a sufficient
amount of damage to be out of action. The same thing usually happens with several robots of the unit. one of the warring
sides will lose several vehicles, the enemy will be able to concentrate more fire
power on fewer targets, thereby increasing the level of damage
among the surviving enemies."

So during attacks it is highly desirable to have at least a numerical superiority.

DD> By the way, a small thought,how can you primitively calculate the strength
DD> of resistance for a specific point on the map. For each unit

/skip/

Thank you! Alex, take note! By the way, where are the scanned robots?

*Sincerely, Max* aka _/*Darth Vader*/_ /Orion '2000 March 08, 2000

[ skip my thoughts ]

MD> IMHO, this is better attributed to the AI ​​of the computer, but not the player.

It was for the computer that I wrote. Because a living player completely controls the situation
in his troops, and all the tactics and strategy of his troops are in his power.
If there is a human-human game, then the robots need maximum intelligence
to “Stop, I’ll shoot!”, and there is no need to invent anything special.

And when playing a human-computer, it is important that the person does not collide with the intelligence
cistern or bureaucratic apparatus.

MD> And about the large-scale battles... Of course, this is very rare, but anything
MD> can happen! Missions are different.

Again, this related to the behavior of the computer. Those. if a big battle is planned, then the computer should not send all its robots in one heap to the battle site, because they will interfere with themselves; and if possible, he could
simultaneously deliver several blows to the enemy’s weakest points.
With such a development of the game, the human player clearly will not get bored ;)

MD> Group of Battle Losses). I quote “The Price of Glory”, p.358:
MD> “The concept was based on the fact that in battle the robots of one
MD> unit reach critical levels of damage at approximately the same time.
...

I already know this from my own experience. And options likeYou can
reduce your own losses and increase the enemy's losses. It depends
on the specific implementation of AI in the game.

With the best, Max!