#chatgpt - an adventure; with codereview!

 So there's alot of fuss around AI lately; it's been stirring my curiosity for a while - it's been a long time since playing with it in chess games at university.

For fun, and to explore; i deciced to want to make a "maze" game. A very simple game in which you have to figure out how to get out of a maze, while avoiding enemies.

Nothing fancy, very basic prototype level stuff. Only one requirement: let chatgpt do all the work!

So far, I have:

- a maze

- a player

- two enemies

- a rendering loop

- collision engine

- and some stats

The first funny thing; it calls python "pseudo-code" (i.e. it coded it in python from the beginning). There was a bit a hassle with setting up the dependencies for the OpenGL piping (on Debian), but otherwise it runs. I had a few iterations on it; code restructuring was particularly painful (apparently class structure context is something that gets easily lost when extrapolating from a single file to individual ones - i.e. one per class); when I decided to move the maze code into it's own class, the references to it woule have been still "maze", but it didnt acknowledge the actual maze data present within the maze class (as in maze.maze was missing from the other classes using it).
Most of the logic is then also glued into the rendering class, for some reason - I wonder if  the notion of the inversion of control pattern is tricky for it.

So after this output, we get this:

 

quite an open maze, I must say.  I will try to solve this problem later on.

The stats also do not show, despite being there (there should be a header with a life counter).

The whole process of prompt "engineering" (or whatever it is heretically called) is just brain dumb. Telling chatgpt what is needed is actually _very_ tedious, and can easily lead to errors. Another thing : chatgpt _cannot_ commit to github. Now that's quite the deal; yes of course chatgpt is storing every change for you, and it can revert to any of them at any point; but if you'd want the flexibility of git in it, it'all download/add/commit/push/merge cycles. Unhandy to say the least.
Also, when you ask it for a change, chatgpt will stay specific, i.e. it will prefer to output a short part of the code you are asking changes for, instead (for example) of the whole file with the new changes in it (this makes copy pasting tedious too). It's also "missing out" on some module imports for constants (mainly DOUBLEBUF, OPENGL, which come from the pygame module). As well the font initialization part was missing.

Now lets say I want to add some extra logic (If I click on a wall, I want to be able to "move" the brick by one cell forward or backwards). This is the changeset chatgpt proposes:

48a49,50
>         self.dragging_wall = False
>         self.dragging_wall_pos = None
72a75,78
>     def handle_mouse_down(self, x, y):
>         x = max(0, min(x // 20, self.maze_width - 1))
>         y = max(0, min((y - 50) // 20, self.maze_height - 1))
>         if self.maze.maze[y][x] == 1:
>             self.dragging_wall = True
>             self.dragging_wall_pos = (x, y)
>
82a89,97
>     def handle_mouse_up(self):
>         self.dragging_wall = False
>         self.dragging_wall_pos = None
>
87,89d101
<         # Handle dragging wall
<         if self.dragging_wall and self.dragging_wall_pos is not None:
<             x, y = pygame.mouse.get_pos()
94,107d105
<                 x = max(0, min(x // cell_size, self.maze_width - 1))
<                 y = max(0, min((y - header_height) // cell_size, self.maze_height - 1))
<                 if self.maze.maze[y][x] == 0:
<                     self.maze.maze[self.dragging_wall_pos[1]][self.dragging_wall_pos[0]] = 0
<                     self.maze.maze[y][x] = 1
<                     self.dragging_wall_pos = (x, y)
<
95a108
>     def draw(self):
102a116,119
>             elif event.type == pygame.MOUSEBUTTONDOWN and event.button == 1:
>                 self.handle_mouse_down(*event.pos)
>             elif event.type == pygame.MOUSEBUTTONUP and event.button == 1:
>                 self.handle_mouse_up()
108,109c125,126
<                 glVertex2f(x * cell_size, y * cell_size + header_height)
<                 glVertex2f((x + 1) * cell_size, y * cell_size + header_height)
---
>                 glVertex2f(x * cell_size, y * cell_size + header_height)
>                 glVertex2f((x + 1) * cell_size, y * cell_size + header_height)
111,112c128,129
<                 glVertex2f((x + 1) * cell_size, (y + 1) * cell_size + header_height)
<                 glVertex2f(x * cell_size, (y + 1) * cell_size + header_height)
---
>                 glVertex2f((x + 1) * cell_size, (y + 1) * cell_size + header_height)
>                 glVertex2f(x * cell_size, (y + 1) * cell_size + header_height)

But hey it's been one hour tops, and I am this far! The enemies move, adn the player is controllable. Impressive. The same game took me about 6 hours to code a few years back (mainly the maze algorithm was a bit cumbersome).

 

Jira Herp derp #2

 So Jira.

At it again.

Damn.

It used to be a decent tool (avoiding flame wars here /flame:off).

But recently with all the cloud jazz from atlassian, life has become impossible with jira.

Sorry jira, our relationship is not working anymore. It's not you (but it is), it's just that we want...different things, I guess.

You want to make more money for yourself, to be able to sustain your growth (and buy shiny new features, which will clog your already clogged UI).

I want to have a simple UI, which I can use to track my acitivity and integrate with my CI cycles.

You want to make sure everthing is secured properly; and because of that, you go and hide in the cloud, as if that would be a safe place to be. And not only that, you take all your companion apps with you!

I want to be able to install/manage relevant versions of you according to my needs, be it with the basic jira or with the companion apps. After all, I have paid for your already (see previous post).

Why should I have to pay (alot) more for :

- the same functionality

- in a foreign environment (the cloud)

 just because <insert reasons here atlassian>?

Disagreements, by grades of severity

During my work life I have come to the conclusion that in fact, all that matters are interactions with people; meaning the people you work with, as well as the interactions one has with the others in the context of a team and/or group; specifically a software engineering/developing group in this (and my) case / experience.

It is relevant that the quality of the outcome is affected by the quality of the interactions; and least not only that, also one's experience on the team will be affected. So communication is affecting (of course) a big part of that outcome. Given that communication, then, plays such a big role in the quality of the outcome, one has to realize that conflict, in a team, plays the opposite role, i.e. degrades the quality of the output. Conflict is one of the team traits that I feel are often mentioned; but at the same time its expected from everyone to be capable of handling it. Personally I don't like the word "conflict" itself. Its too broad of a term; when we talk about "conflict", it's very uncertain what we mean. Armed conflict? How would that translate into a Software development team - armed assault? Verbal violence? Personal attacks? Or fad arguments against one's own opinion? Passive-aggressive comments? Banter chit-chat in the interested person's absence?

Conflict is a dangerous word. Back in the 1920's, futurists (and later fascists) belived the world could be changed (for the better) only with conflict.

Fast forward 100 years later, the world has suffered the biggest armed conflict in human history, with millions of lives spent; the Futurists (which by then had become Fascists) had proven the way of changing the world they envisoned not to be the right one, therefore humiliating themselves and their thought school.

The Fascists, as a team, failed. Their "ways of working", their "tools", did not survive. Conflict was shown not to be the "herald" virtue it had been advertised for.

The Fascist's (failed) endeavours is a perfect example as in how conflict is toxic for a team (and im sure everyone agrees on this); even if used as an external tool for "improving" the team's own wellbeing (you won't make good friends if you make everyone an enemy).

I've come to cherish different grades of "hostility" (if you pass me the term) whilst communicating through the years:

- disagreement

- questions

- (counter)argument

- agreement

- violent agreements

Each of these carry a different grade of severity; heaviness in being addressed; and difficulties for the approach.

A disagreement is the simplest form; i.e. any reason that is incapacitating people to find consensus / understanding / common ground.
Typical scenarios can variegate from hearing only "no", to offensive expressions flying in the air.

A question, as such, is a simpler and more neutral form. They might be part of disagreements, or then gather people towards consensus, which is where they get the neutrality from. On a question, you typically have an answer; but the difference is, the discussion ends there. The answer satisfies the need for knowledge completely, no other question (argument or counterargument) is necessary.

An argument, or counter argument, you can have presented either as a reason in a (civilised or uncivilised) discussion, or as a question, posed as an answer to another question, or a follow-up question to an answer.

An agreement is then the situation of (peaceful) "yes"'es which highlight the fact consensus has been achieved, and everyone (or at least the relevant parties) are on the "same page".

A violent agreement, finally, tackles down to an argument being agreed on by all the involved parties, in a "violent" fashion. Think of someone all being involved in a discussion on a given topic; but all shouting wildly "yes" at eachother, as if every one's "yes" would be better than the others (spoiler: they are all good the same, but the passion transpares here the most).

The maturity of a team (and the individuals composing it) can be seen from how "conflict"  situations are handled; more mature teams are more likely to not dig into the details of the issue, whereas younger, less mature teams will tend to split arguments up, hereby achieving the opposite effect, i.e. generating more tracktion for the respective cause - the conflict will spread. Mature teams will most likely steer clear from disagreements with the help of questions, to hover over into arguments, and from there to agreements (be them violent or not).