- ComputerCraft | Programmable Computers for Minecraft
- → nitrogenfingers's Content
nitrogenfingers's Content
There have been 11 items by nitrogenfingers (Search limited from 30-March 23)
#270595 Anyone up for testing a game?
Posted by nitrogenfingers on 26 September 2017 - 06:12 AM in General
If so leave a message here or a PM, I'll forward you the code and some advice on what I'd like tested. Cheers in advance.
#270451 Thoughts on Drag & Drop Coding
Posted by nitrogenfingers on 20 September 2017 - 10:15 AM in General
Visual programming languages are useful for teaching because both syntax and compsci principles are important to learn when programming, and the use of a syntax-minimal language allows them to be learned independently. The algorithms behind principles like conditionals, looping and recursion are largely equivalent regardless of language, so you can create and observe these structures without worrying about syntactic pitfalls like missing punctuation or misspellings. Of course theoretically a visual programming language can probably implement any finite set of functionality, but the programs I've used keep the scope of their respective languages very small (or choose a simple platform) for the sake of simplicity.
So functionally I haven't seen a visual language that could be used for anything complex, because to do so would be missing the point.
Regarding the impact of hiding low-level functionality on programmer understanding, this was actually the topic of my graduate thesis From my research, yes this is a danger. A good example of this is BlueJ, a Java IDE that uses UML to hide the static elements of the language. It's not a visual language per se but it has visual components in place of code. At my university we observed significant issues transitioning from BlueJ to Eclipse because it fundamentally altered their perception of how Java worked. The author of the IDE discussed this among other issues in a 2008 paper.
It's a super-specific case but my takeaway is as teaching tools they're useful to a point, and students should not come to rely on them in the long run, as this may hamper their ability to learn other paradigms in the future.
#270297 Micropaint: Experimental painting program for tiny pixels
Posted by nitrogenfingers on 13 September 2017 - 07:35 AM in Programs
I haven't set a license for any of the software I've made, but if you keep the attribution comments at the top of the file then it's probably fine.
#270220 [Beta] Dodj - Dodgeball in CC!
Posted by nitrogenfingers on 11 September 2017 - 07:07 AM in Games
Dave-ee Jones, on 11 September 2017 - 05:55 AM, said:
If you can assume players can't change their team once a game starts, then you can loop through each player in the game, get a unique list of colours and use that for scorekeeping.
local players = { [1] = {team = colours.red}, [2] = {team = colours.blue}, [3] = {team = colours.red}, [4] = {team = colours.green}} local team_scores = { } local function createTeams() for _,player_entry in pairs(players) do team_scores[player_entry.team] = { score = 0 } end end local function displayScores() for team_color, team_score_value in pairs(team_scores) do term.setCursorPos([...]) term.setTextColour(team_color) term.write(team_score) end end
Incidentally I haven't tested any of these code snippets but hopefully you get the gist.
#270217 [Beta] Dodj - Dodgeball in CC!
Posted by nitrogenfingers on 11 September 2017 - 05:38 AM in Games
Bug: Once one team scores a point and the field resets, players are no longer able to pick up dodgeballs
I think my comment about the size of the field is still my big concern with this one, although having more dodgeballs on screen definitely makes it more frantic. A game mode where a moving dodgeball is dangerous to both sides would even further raise the stakes. You should have a display somewhere in the frame that shows the current score as well.
One last suggestion, particularly seeing as this game appears to be about fast movement, you might want to instead of using key events to move your characters, you could keep the state of the button as 'up' or 'down'- setting it to either when a key_up or key_down occurs. Then just have a running timer in the background and evaluate each movement when it ticks over. If you do that, you avoid that delay after the first key event fires and you have more control over how fast the characters move.
local player = { x = 10, y = 10 } local keyboard_states = { [keys.up] = false, [keys.down] = false, [keys.left] = false, [keys.right] = false } local key_timer_length = 10 local key_timer = os.startTimer(key_timer_length) while true do local id, p1 = os.pullEvent() if id == "key_down" then keyboard_states[p1] = true elseif id == "key_up" then keyboard_states[p1] = false elseif id == "timer" and p1 == key_timer then if p1 == keys.up then player.y = player.y -1 --etc etc end end
#270140 little rpg engine
Posted by nitrogenfingers on 09 September 2017 - 01:37 AM in Games
#270098 [Beta] Dodj - Dodgeball in CC!
Posted by nitrogenfingers on 07 September 2017 - 04:15 AM in Games
- The ability to change your facing without moving. A second button could do this without overloading the scheme I think.
- A smaller playfield. Right now it's just too easy to miss unless you're quite close
- More dodgeballs on the field. I'm not sure what a good ratio would be but I think it should be reasonably difficult to move around when all are in motion.
- Tweak catching. I found it really challenging to catch the ball- either the game is moving too fast or the window to catch is just too small. Some visual indication of when/where that window is would be really good as well.
As a later deliverable one idea that came to me is to have playfields with obstacles that reflect the dodgeballs in different directions- you could use slashes or teletext characters to bounce the balls 90 degrees. Particularly if these obstacles could be moved, that could lead to some interesting gameplay.
Another layer might be having multiple players- either you move them all at once with the same directions or cycle between them. That could really raise the stakes of the game, make it like spinning plates.
Also I noticed some flicker when I played it. It looks like you're redrawing the game each cycle- you can probably trim this down as there aren't many visual elements on the screen- like only draw a player when an appropriate key event is fired etc.
#269938 Ramuthra's Plane
Posted by nitrogenfingers on 03 September 2017 - 02:13 AM in Games
Hope you can release more content, it looks like there's a cool game here
#269937 CCJam 2017 is here!
Posted by nitrogenfingers on 03 September 2017 - 02:12 AM in General
Scores are below. I thought they were all really impressive, this was a cool jam so nice work everyone
Ratchet2497
Functionality: 7
Creativity: 7
Execution: 3
Code Quality: 3
Layout: 2
Comments:
Teletext frogger with scrolling screens is an ambitious goal for a jam, and all things considering this is a pretty solid effort. The characters look good, and the game runs and plays as you'd expect. Frogger translates over pretty well, albeit with much less screen space. There is some wonky collision detection, the frog blends into the grass a bit and I found on my machine the speed jumped a bit.
My biggest issue with this one was the lack of affordances. There's no in-game interface, and no goals or constraints, like time or score, or progress tracking. Only 1 life makes it very difficult. An end screen and win screen appear to have been programmed, but they don't seem to work.
As for code quality, well I've written worse. It's terse, not very readable, there's a lot of nested functions that could afford to be anonymous or separated out. But that aside this is a really cool demo, and with a bit of polish could be a pretty fun game. I'm really surprised you made Frogger as playable as you did. Nice work!
Wilma456
Functionality: 9
Creativity: 1
Execution: 5
Code Quality: 4
Layout: 4
Comments:
*sidenote* This is super hard to judge because I haven't used packman in a dog's age. So these are based on the experience as a whole- if there are issues I found that are a packman issue not your program, let me know and I'll update my score.
So this seems like a reasonable implementation of packman. It uses the same linux style file structure, (though I noticed it drops a few more folders), and it fetches, lists and installs packages well enough. There's not a whole lot to say.
What I will mention is some things could've been done to make it easier. My biggest issue was search was impossible it lists all the packages at once, so you can only see as many as your screen height. It's also less verbose, I didn't get a warning if a dependency couldn't be resolved or any other issue, although these might be bugs in packman. But either way, help could and should be longer.
The code is simple, quite short. There's no commenting or anything and some unintuitive variable names, but then not sure what I expect from this sort of software. It leverages backpack.
This is a really hard entry to judge. It does exactly what it sets out to do. It isn't creative at all, and it inherits everything from it's inspiration. I can't fault it for that, but it's score suffers a lot from that criteria. As a project on it's own, great job- this seems like a good version of packman.
Saldor010
Functionality: 8
Creativity: 8
Execution: 5
Code Quality: 4
Layout: 4
Comments:
So this I found pretty cool. It's clear you had grander ambitions but you pared it down and got an MVP out. That's hard in a jam so kudos for pulling it off. This one works just as you'd expect, the interface is simple, clear and verbose- I had no trouble playing. The only additions I'd make (besides more content) is disallowing items to be dropped on walls or yourself, and some indication if a key doesn't fit a lock. I'd like a way to quit a game without terminating, and maybe reset if I put the game in an unwinnable state.
The biggest pity is there isn't more. There are only two kinds of objects and the puzzles are pretty simple. I can see a lot of potential here, and it would've been great to see a bit more of that come out.
Reading the code was a bit morose seeing all the cool features that didn't happen. It's well laid out, and names are well chosen, but wow there are some monsterous list operations! Entitymap is indexed to within an inch of it's life! Besides that, I had a pretty easy time reading this.
It's a shame we didn't get to see that grander vision you had planned (Mad props for the awesome intro story), but this is a really nice program. Probably the one I liked the most.
supernicejohn
Functionality: 3
Creativity: 4
Execution: 2
Code Quality: 5
Layout: 3
Comments:
I feel bad for giving this one a low score because it's actually pretty impressive. A working text editor is a pretty tall order, and this one comes pretty close, but it didn't hit an MVP. There is no interface, and once I figured out the ctrl shortcuts I actually quite liked having no interface, more space for typing (and the save menu was pretty slick). Why is there no quit option though?
The typing was almost good, two major issues was an underscore was drawn instead of using cursorblink so the cursor hid the character behind it, and when inserting text before an endline it would push the characters forward, so you had to move one space back, which was frustrating. It had no trouble loading text files, but it only saved blank files and left the stream open so I had to restart to delete them. Pity, it's just a one line fix (file:close() at line 83). That would've bumped functionality and execution up a bit.
The code looked pretty good. I liked queuing events to redraw, it minimized draw redundancy. Not much to criticize here actually.
This didn't get a high score by the jam metric, but this is still a pretty great accomplishment for a week. super nice, supernicejohn
#269167 CCJam 2017 is here!
Posted by nitrogenfingers on 22 August 2017 - 07:57 AM in General
#268924 CCJam 2017 is here!
Posted by nitrogenfingers on 10 August 2017 - 07:06 AM in General
- ComputerCraft | Programmable Computers for Minecraft
- → nitrogenfingers's Content