Research Progress

Pretty good idea, always annoying when you have to make a snap decision about a unit you need now, or a unit you will probably need in a few days.

lol, that's funny you actually believe that they should implement changes that will take money out of their pockets. You think Bytro should be non-profit so you can continue to play your FREE game? lmao, keep hope alive Jessie!

ATownGtr wrote:

lol, that's funny you actually believe that they should implement changes that will take money out of their pockets. You think Bytro should be non-profit so you can continue to play your FREE game? lmao, keep hope alive Jessie!

I support this game in every way I can. But I don't like it when a company uses "nickel and diming" tactics to squeeze their customers. Besides, I won't spend Gold to fix this or any problem. I am resolute in this just as most users are. If Bytro wants to be better funded and more profitable, they should sell more premium services like High Command which actually improve the game for some users without spoiling it for the rest.

Additionally, I think they'd do well to offer game merchandise...both physical and virtual. A great example would be virtual upgrades that can be purchased -- with Gold or other premium points -- that make an in-game match more fun to watch. You could (for example) pay a small amount of Gold to make one of your units grow to monster size and this would get a "monster attacking city" animation viewable to you and your opponents whenever it attacks their cities. This wouldn't change any battle outcomes, just be visually interesting.

There are MANY possibilities that could be implemented that people would be happy to pay for -- in small quantities -- that would more than make up for removing the game-changing gold improvements that do tend to ruin the game for others.

Also, ... who's Jessie?

I don't think this is a mistake. It was decided to be this way. In games that include research or other similar concepts there is a choice. When you decide to change what you are researching, should the progress be saved or not? In some games it is, in some it isn't. It is just a choice. Made by developers.

Both options have pros and cons. If progress is saved, you are flexible to change what you research now and what later. You can change your priorites any time. If progress is not saved, you are required to use more strategy when deciding what is the priority because otherwise you research the wrong thing, lose resources or time. It adds depth to the decision making aspect of the game.

So, with this being said, I don't think it is a design flaw or something similar. It is just the decision made by the developers based on the concernes or issues they tried to address and considered priority. Or, @Diabolical is right and they just didn't care at all so they used the simplest solution.

Actually, I've played many different strategy games over the years and I've never encountered one where you lost all production...except maybe Master of Orion II...maybe. But, lazy programming as an excuse would be a terrible reason.

As for realism? If you have research scientists being pulled off a project to work on something else, they don't burn their research papers. They return to them later on and continue where they left off...maybe after a small amount of time to review and "catch up", but not starting from scratch. That's just wrong game design.

Yea, now that I think about it when I played EVE it was this way. If you have ever played that you know the whole game centers around what you research and if you stop and switch to something else it does save your progress and you can pick right back up from where you left off. It also prorates the costs and refunds you the unused portion so you will have to spend to kick it back in but not the whole cost again. Good Point!

I doubt the current system is the result of any nefarious plan to nickel and dime the players. I think it is more likely the guy writing the code simply wrote the simplest solution to the task given him.

Tracking the yes/no completion of the various tech research items is just a binary variable for each item. This becomes a very easy to read / write / transmit piece of information. Since one of the requirements is to keep the size of the file sent to the browser on log in to a reasonable size, a simple 1/0 for each researched tech makes sense. This makes is difficult to track partial completion.

The actual tech being researched will simply be a time of completion field with a name for the tech being researched. There are only two of these possible so it again becomes a fairly small chunk of data to handle.

The expectation that the game retain a partial status for each tech adds a fairly significant chunk of code and information to be tracked. If that is not part of the original requirement for this code module, the coder would not be doing his job if he overly complicated the software to meet this undocumented need.

This makes me believe it is simply good programming for a defined result.

For the larger question of whether or not this is how things should really work, well that is a bit more complex.

I have a little bit of life experience in dealing with the stopping and starting of development efforts. When funding/resources get pulled off of one project to be assigned to another, there usually is an effort to capture progress to date and put it in an accessible format for a potential restart. The success of this capture can vary widely.

Facilities either get repurposed or retired in place. Materials get surplussed or reused on other efforts. People move on to the next project. If / when the project is restarted, much of the facility / material / manpower has to be restarted from near scratch.

If the game designers want to attempt to model this a simple model would be to allow retention of 50% of current progress when a project is halted. Arguments can be made for more or less but all or none would both be more wrong that 50%.

Coding this would add a layer of complexity. That simple 1/0 table of completed tech now has to have a whole range of possible values. This impacts the browser interface and the size of the transmitted file. Yuck...

Is the gain from this improvement worth the cost compared to other things that could be improved instead? Hard to say. What we have works, to a first order of accuracy. Personally, I would rather that time be put into other areas of game improvement, like an AI that actually does not do stupid things.

F. Marion wrote:

The actual tech being researched will simply be a time of completion field with a name for the tech being researched. There are only two of these possible so it again becomes a fairly small chunk of data to handle.

The expectation that the game retain a partial status for each tech adds a fairly significant chunk of code and information to be tracked. If that is not part of the original requirement for this code module, the coder would not be doing his job if he overly complicated the software to meet this undocumented need.

Actually, the game operates more like a mainframe/terminal than a client/server style with all data being stored on the server. Any changes on the client end are immediately reflected against the server end and inconsistencies are disregarded. The client end deals with UI and retains front-end graphical stores for ease of processing, but the actual calculations and tracking are strictly maintained on the server with it's database in exclusive control of all game data.

That a programmer may have been lazy would be unfortunate. A good programmer would spot this as a possible point of issue and raise it with the game design team. Those responsible for how it is "supposed" to act might not have considered this issue but if they have, and the programmer(s) in question hadn't followed the correct design, then it needs to be addressed on those grounds.

On the other hand, as for simple file size issues and total data throughput, we are no longer dealing with low baud-rate modems from the 1990's or even lower end wired technologies. The end-user is most likely using 3G wireless or better and the server will likely be on a fiber-optic line to the trunk of their provider. That the system handles tens of thousands of matches at any given moment, with computations on tens of thousands more in memory is no big deal for a large bank of servers which this game relies upon.

Data efficiency is swell for minute computations over a wide-ranging set of calculations but is unnecessary in the current context to the extent that you are implying.

This is my analysis based on what I know of Bytro, Call of War, and programming for large-scale systems. It is not the only interpretation, and it may not be correct, but it is the best interpretation -- logically -- unless the programmers and server techs at Bytro state otherwise.

I expect you have more experience writing code than I do since I keep migrating away from that task.

"but the actual calculations and tracking are strictly maintained on the server with it's database in exclusive control of all game data"

I agree with this assessment and this is also where I expect the bottleneck is for tracking progress on a tech research.

At present, the implementation is fairly straight forward. Two timers per game. A simple matrix of what is done/not done.

Modeling a stop / start research queue adds complexity to the above implementation. Multiply that by the number of players in each game and any change to the code that increases computation time needs to be carefully evaluated. It is also likely that the UI display we see on our browser for research is locally generated for show and is not reflecting calcs being done server side. The countdown timer xD yM zS is likely based on the local RTC and is for display purposes only. As soon as they start allowing start / stop of research queue, they will be forced to ensure the pretty little count down clock actually matches what is happening back in the mainframe.

I see the current solution as simple, elegant code. It fails to accurately model what happens in real life but that can be said about every theory / model / simulation ever created. Euclidean geometry is good enough for the vast majority of the engineering work I have done. I know it is not accurate at the "edges" but that is not a good reason to include speed of light and mass calculations into time / distance problems that don't exceed 0.1 C.

A small addition on my part then.

I understand F.Marions point and it sounds logical for 'ease' of programming (or lazy, give it a name). Yet we have the same thing with units...but also with buildings. Buildings can be completed halfway (in certain chunks....heck, call it Sprints in Agile terms) and cancelled, reclaiming 50% resources and do something else.

So Im curious why its not a simple 'copy paste code and replace the part of the code that says 'infrastructure' to 'research/unit'.

Problem solved

...

right?

Mind you, I only know some basics in regard to coding and testing in regard to the how-to, I do not actually speak C++ or anything.

I doubt that this game is done in C++, it's likely in Java. As far as the way the information is being tracked, the elements that have partial progress completed are part of city data. A city, presumably has something to the effect of: city.buildings(currentFactoryLevel(0.0 - 5.0)), city.buildings(currentBarracksLevel(0.0 - 3.0)), city.buildings(currentInfrastructureLevel(0.0 - 3.0)), etc...where the current level can be a floating point number in that range. A capital would be 0.0 - 1.0, but when another starts getting built, any city with a capital goes to 0.0. This is simple logic. Actually, a better write would be: city.buildings(0.0 - max, buildingName).

At the same time, a city probably also has something like: currentUnitBuild(0.01 - 1.0, unitType) where the range is from barely completed, to finished, and when it is finished, it gets cleared out. Thus when a city is captured, there is still a unit sitting there with an already defined unit type that is ready to be finished even if you don't have the technology to begin creating your own.

Now, along similar lines to above, @F. Marion seems to think that it is should be with technologies something like this: techSlot1(0.01 - 1.0, techID), techslot2(0.01 - 1.0, techID); and that only when a tech is completed, then a tech becomes: techID.isResearched(T/F). And that would make sense if the programmers did a lazy "simplest" solution. But it is not the best solution. Research slots should not be treated like cities where the techs are treated like units. But rather, if the research slots are treated like cities, then the techs should be treated like buildings, like this:

techSlot1(0.01 - 1.0, techID(retrieveCompletionLevel() ) ), techSlot2(0.01 - 1.0, techID(retrieveCompletionLevel() ) ).

regardless of how they've implemented it, from using basic switches for communications or complex objects, there are always easy solutions that will make the implementation workable without necessarily clouding up throughput. The values passed would still be very small, just on the order of bytes rather than bits. And that's no longer a big thing to worry about in the real world. It would have mattered more, 15 to 20 years ago, but today, it's just no longer an issue. If it were, then YouTube would be in serious trouble.

Yes I agree. It doesn't make sense how that would work. It should refund you the percent that was not finished, and keep the current progress.