TheLivingBlooper 2020-06-07 02:23
I make a lot of incomplete games on LowRes NX, only one of which I have actually uploaded. The main reason for this, is the building complexity of creating a game, as it reaches 1,000 lines or more of (potentially) pure spaghetti code.
Especially if you have aspects of your game that consist of different enemy classes and templates for said "classes," the code behind the game can get very difficult to read and update, especially for newer users. I imagine I'm not the only user that has had this issue, but I'm not sure.
I usually use global dimensions for storing data, and from my understanding, this is the best current way to store that data. Using numbers to identify data points fits well with the rest of the language, but again, can become very confusing.
In short, and this is mostly directed towards @Timo, I propose some form of experimental struct. Rather than using
PLAYERDATA(1), for example, to get the health or another attribute of the player, you could use
PLAYER.HEALTH. I'm not sure how this would be implemented, but if you made it this far, thank you for considering. (Maybe something like
Blockhead 2020-06-07 09:59
It's a modern concept, not used in old consoles.
was8bit 2020-06-07 12:25
Why not use compound arrays?
So DIM PDATA(PlayerNum,DataType)
So Player number 1,2 represents players 1 and 2
player number 3+ represents enemy players
DataType #0 = alive status/health
#1,2 = x,y position
#3 = level
Keeps the amount of variables down, but does require a list of what is what on the side to keep track of what # represents what...
was8bit 2020-06-07 12:32
Another solution is if you have a standard approach to processing something, use one SUB for all of them.... example:
IF X<0 THEN X=0
IF Y<0 THEN Y=0
IF X>19 THEN X=19
IF Y>15 THE Y=15
Then use it like this..
IF RIGHT(0) THEN CALL MOVE(PLAYERX,PLAYERY,1,0)
And for computer...
FOR I=1 to 100
IF RND(100)=0 THEN CALL MOVE(EX(I),EY(I),1,0)
SUB will actually update the inputed variables like PLAYERX and EX(I) automatically
GAMELEGEND 2020-06-07 13:28 (Edited)
If timo made a struct it whould make lowres less like lowres
TheLivingBlooper 2020-06-07 13:46
That's true. And thank you for the help, @was8bit. I was working on a project with an abundance of dimensions and I guess I got kind of tired keeping track of them all. Variables keeping points is probably something I should have thought of.
was8bit 2020-06-07 17:14 (Edited)
I try to use SUBS as they help reduce the overall volume of code....
For a big program, i try to make the code as easy to read (and reread) as possible :)
A few more thoughts....
.... dont be afraid to post half written stuff (well, keep them under 100 ;) ) as they can help inspire and give ideas to others...
.... and also try making smaller stuff... lowres really isnt designed for large games... in original lowres the unpaid version only let you write a game with 24 lines of code... even though i had a paid version it was a fun challenge helping others make game,with 24 lines of code...
.. so try these ideas....
1) make a game with only 24 lines of code
2) make a game using only text
3) try reproducing old atari games
Or, at least, when you get a game idea, try reducing it to its smallest portion, and just make that.... like, instead of an entire space game, just make the part where you shoot down one ship at a time... then make another game where you land your ship on a planet... then make another game where you mine the planet for resources...
By breaking up your big game idea into smaller parts, and test each part by making mini games of the smaller parts, you can
1) make mini games others can enjoy
2) flesh out issues and ideas easily in the mini game
3) come up with new ideas ....
TheLivingBlooper 2020-06-07 18:19
That's probably smart. I've already been working on an even larger version of Shuttle, so that may be too late, but I'll keep your advice in mind for future projects. Thanks.
TheLivingBlooper 2020-06-07 21:05
...And also, 24 lines of code certainly sounds like a challenge!
was8bit 2020-06-08 04:33
@24lines, Its actually a fun challenge :)
was8bit 2020-06-08 04:40
Example: 22 lines...
FOR I=0 TO 3071
FOR I=0 TO $1000-1
FOR I=0 TO $100-1
FOR I=0 TO $20-1
FOR I=0 TO $20-1
FOR I=0 TO $30-1
TheLivingBlooper 2020-06-08 12:46
That's cool. I don't know how else to describe it.
was8bit 2020-06-08 15:36 (Edited)
I randomly add and change data in NX's virtual memory, which NX constantly processes, i believe every 1/60 of a second.... i am randomly affecting the character memory, the background memories, the sound effects memory, the sprites memory, the palette colors memory, and the video settings memory
...perhaps this is what NX does when you turn it off... this is NX's dream state, it is dreaming random things ;)
TheLivingBlooper 2020-06-08 15:42
I wouldn't be surprised!
Timo 2020-06-08 17:11
QBASIC already had something like structs, but older versions of BASIC didn't. I know that structs could make code cleaner, but in BASIC usually each new feature made things "stranger" because it wasn't designed for it from the ground. New questions appear, like how to pass structs into SUBs. Is it by value or by reference? Etc.
From my perspective, adding structs to the language would be a lot of work. Not only implementing it, but also documentation and help. Because of other projects I don't have the time to work so much on LowRes NX anymore.
I decided not to try making BASIC more modern. Maybe I should have used Lua instead. It's very powerful and has tons of documentation and tutorials. But as some of you say, old-school BASIC is a big part of LowRes NX's character.
was8bit 2020-06-08 17:50
I always found structs confusing... i found variables existing inside objects confusing... i found writting code inside one object that could affect variables inside other objects more confusing... its why i dont like scratch either....
Basically there is no "timing" or "synching" of all code universally... each behaves like its own mini computer, and just like windows things can start to behave unpredictably and irratic....
Lowres is straight forward and simple, with enough power to pop...
Old school machine code executed ONE COMMAND at time, not hundreds of commands at the same time... the "one at a time" approach makes it abundantly predictable, and easier... when too many things are going off at the same time, my brain shuts down....
Timo 2020-06-08 21:21 (Edited)
Well struct have nothing to do with code executing at the same time. It's really just for organizing data. What you mean is multi-threading, or at least something similar.
was8bit 2020-06-08 21:32
Ah, well, i prefere the old school styles, and lowres hits all my happy buttons :)