Author Topic: Personal news  (Read 15738 times)

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: Personal news
« Reply #30 on: March 31, 2016, 06:21:15 PM »
The second way vb6 does support classes but I never played with them and DB2 currently uses structures. But I will consider doing that for DB3. Still need to know architecture support for stuff like that. I just realized I can get away with no static variables if I do it this way because the main code or some class somewhere can hold a copy of them and I just fetch them as needed.

Method1 I never knew about actually. Should be a good read.

Thanks for your help Panda!
« Last Edit: March 31, 2016, 06:28:10 PM by Botsareus »

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: Personal news
« Reply #31 on: March 31, 2016, 07:24:12 PM »
Actually, I think it will be fun to make DB2 code nice looking one day. And should teach me alot.  :) However, I am not ready for that yet.

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Personal news
« Reply #32 on: April 01, 2016, 06:08:54 AM »
It would still be possible with structures, just the code organisation would be different, i.e. with constructor methods instead of actual constructors. I don't know how VB6 classes work so I can't really comment on them.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Personal news
« Reply #33 on: April 01, 2016, 02:56:55 PM »
One other thing that people complain about alot that I need professional opinion on is the global variables. I admit I am guilty of using them often. But my question is in ideal conditions what do I replace them with? I made them public so they save state outside the scope of a subroutine. I could have gone with static but than I would not be able to capture there state for the save simulation code.

A strongly enforced MVC distinction would help.  Basically have the simulation state in an isolated bubble, and force communication to/from the simulation to go through specific channels, or at least specific places in code.  The problem with globals is that you can't easily isolate what the side effects of a function are, which makes it difficult to test, and therefore difficult to modify.  Rule one for responsible software engineering: clearly define what the inputs and outputs to a function are.  If the input is the entire simulation, and the output is a slightly modified simulation, how can you ensure code correctness other than eyeballing it?  Instead of passing in the entire simulation as globals, if you passed in just the info for robot X, that would be a step in the right direction.  The narrower the input/output to a function, the easier it is to be sure it's working right and has minimal unintended side effects.

I will say this for the DB2 codebase: the overarching program flow is at least easy to understand.  It's very easy to look at the code and figure out where some feature you'd want to add should go.  But that does no good if you can't be sure you're not breaking something.  Even simply refactors run the very real risk of breaking some feature or other, and we don't have good ways to know that something's broken.  Even in a traditional video game, you can find bugs just by playing.  With DB, if something is broken it just means that there might be some robots somewhere that don't work quite right.  That's hard to catch.

Quote
Edit: A little follow up question: I think the code (although messy in a few places) is tied together reasonably well. I assume you mean there are better ways to tie code together in a more object driven language. Still more detail on this will be good. Edit: Actually answered this question myself by looking on the DB3 Core module that was just released. However, DB2 was never built object oriented, and refactoring it in a major way like this will probably break most of it. :/

Wouldn't have to be OO, though that's certainly the most common approach.  It's more a matter of clearly separating code responsibilities, and you can do that in any language, VB6 included (I don't think VB6 forces you to write bad code).  One part of code to manage DNA, one part of code to manage metabolic things like nrg and body and venom building, one part to draw things, etc. and making sure that the parts only communicate when they have to and through specific places in code.  The problem with the code right now is that each part talks with each other part, often in strange places in code.  Especially stuff around how the UI reads/writes data.  Like, I wouldn't be surprised if there's some code in the DNA execution that updates a UI widget somewhere.  That's convenient, easy, and wrong.  Instead, you'd want the DNA to store relevant info in some debug data attached to the robot instance, and the UI widget to read from that debug data during some sort of "push sim data to the UI" method.  Then you can test the creation of the debug data separately from the updating of the UI widget.  It's not nearly as easy, and it's all sorts of extra hoops to jump through to get a new feature in, but it means you can test both halves in isolation.

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: Personal news
« Reply #34 on: April 01, 2016, 03:37:02 PM »
Thanks Numsgil.

Some of it seems tricky, but it definitely got me thinking.