This thread will be dedicated to my "finished" projects. Mostly meaning that they work and don't start getting errors when someone sneezes on them. I also usually have at least one other player test all my designs, so I'll make sure to give credit where it's due. Starting to get some projects done, working on my third major project now as a joint effort with HolyCookie. More on that soon :D
CAUTION: I do not know proper electronics terminology, so don't yell at me plox
--------------------------------------------
"FINISHED" PROJECTS:
Logical Tic-Tac-Toe: ( done for now )
Credit goes to Mrs. Jaaskinal for testing the original circuit, then playing logic golf with it to show me new logic methods. Jaaskinal's improved circuit
Vaygr HB marquee project:
disclaimer: please no shit posting or flaming, forum wars are just silly.
This one was a real doozy, lots of new logic methods I had to learn. Thanks to AtraUnam and HolyCookie for helping with trouble shooting and design!
--------------------------------------------
WORKS IN PROGRESS:
--------------------------------------------
edit 1: added "tetris" to the game console project, added a picture for input, changed some wording a bit.
edit 2: added vaygr marquee board project and a hint in "works in progress" as to a future, undisclosed project! look for the out of place question mark.
edit 3: wow this page needs some updating. changed my year old grammatical error. the acronym is CGOL not CGOF ya dingus. Added the resource allocation system based on jumpsuit's request.
CAUTION: I do not know proper electronics terminology, so don't yell at me plox
--------------------------------------------
"FINISHED" PROJECTS:
Logical Tic-Tac-Toe: ( done for now )
Credit goes to Mrs. Jaaskinal for testing the original circuit, then playing logic golf with it to show me new logic methods. Jaaskinal's improved circuit
This circuit uses three arrays of latches:
- 1 for each player (2) to define the color placed on the board
- 1 that stops players from messing up the game by putting two colors on the same square.
For win conditions, it uses 8 AND gates which analyzes the current player's marks after they take their turn.
The blue player force field is actually docked to the main ship, so there can be overlapping force fields.
Finally, the rest of the circuit is just misc. logic stuff, to make sure everything works as it should.
- 1 for each player (2) to define the color placed on the board
- 1 that stops players from messing up the game by putting two colors on the same square.
For win conditions, it uses 8 AND gates which analyzes the current player's marks after they take their turn.
The blue player force field is actually docked to the main ship, so there can be overlapping force fields.
Finally, the rest of the circuit is just misc. logic stuff, to make sure everything works as it should.
Vaygr HB marquee project:
disclaimer: please no shit posting or flaming, forum wars are just silly.
This one was a real doozy, lots of new logic methods I had to learn. Thanks to AtraUnam and HolyCookie for helping with trouble shooting and design!
This circuit is actually two entities. Thanks to a tip from someone on the forums, it stores the data on a different entity, that contains most of the logic. This cuts down on the circuit lag drastically, making the board display at a crisp .5 fps, lol. Besides that, the lag was causing screen shearing on the board, and was causing the binary decoder to display the wrong character. It is also docked to the Vaygr HB station, because having all that logic directly on the station would cause horrendous amounts of lag. I'll give a semi-detailed description below.
The circuit is comprised of 4 parts:
- Binary storage
- Binary storage position selecter
- Read Buffer
- Binary Decoder
In brief: The circuit stores binary bytes in ASCII format. There's a binary interface on the main entity, used to change the value of the stored bytes. Then using the position selector, it outputs the stored info into the buffer, and finally the decoder, where it is shunted to the display row by row. When the decoder is done shunting the character to the display, it sends a signal to the position selector to select the next storage position and repeat the cycle over again.
The binary storage is 127 bytes of storage, or 127 characters. each byte is 8 latches with the necessary input / output AND gates. AtraUnam explained to me that the circuit would have less lag if I also added a series of not gates to the input and output, something about instant pulse logic. She was right, and it reduced the circuit lag further.
The Storage position selector is just an extremely long shift register, shifted forwards by a tick pulse from the main entity. This shift register functions using instant pulse logic, taught to me by Olxinos.
The next part is the buffer, which was necessary to install thanks to the nature of the circuit. There is still some lag when the storage module outputs binary to the decoder, so the message being displayed was some kind of combination of two different ASCII characters. the buffer stops this by storing the character, and then outputting it several ticks later.
The decoder is just a large array of AND gates, one AND gate for every ASCII character. that AND gate turns on some OR gates, which in turn send a HIGH signal to an AND gate. That AND gate then waits its turn to output a high or low signal to the display.
The circuit is comprised of 4 parts:
- Binary storage
- Binary storage position selecter
- Read Buffer
- Binary Decoder
In brief: The circuit stores binary bytes in ASCII format. There's a binary interface on the main entity, used to change the value of the stored bytes. Then using the position selector, it outputs the stored info into the buffer, and finally the decoder, where it is shunted to the display row by row. When the decoder is done shunting the character to the display, it sends a signal to the position selector to select the next storage position and repeat the cycle over again.
The binary storage is 127 bytes of storage, or 127 characters. each byte is 8 latches with the necessary input / output AND gates. AtraUnam explained to me that the circuit would have less lag if I also added a series of not gates to the input and output, something about instant pulse logic. She was right, and it reduced the circuit lag further.
The Storage position selector is just an extremely long shift register, shifted forwards by a tick pulse from the main entity. This shift register functions using instant pulse logic, taught to me by Olxinos.
The next part is the buffer, which was necessary to install thanks to the nature of the circuit. There is still some lag when the storage module outputs binary to the decoder, so the message being displayed was some kind of combination of two different ASCII characters. the buffer stops this by storing the character, and then outputting it several ticks later.
The decoder is just a large array of AND gates, one AND gate for every ASCII character. that AND gate turns on some OR gates, which in turn send a HIGH signal to an AND gate. That AND gate then waits its turn to output a high or low signal to the display.
WORKS IN PROGRESS:
Conway's Game Of Life Circuit: (Mid Priority)
( I use this one GIF way too much, hopefully that can change in the near future! )
Very large project for me, working on developing a type of recursive logic circuit that vastly reduces its massive amount of logic blocks to something a LOT more manageable. Link to it's dev. thread Link to it's wikipedia page.
Update: I pretty much have that recursive logic figured out now, been using several different implementations of it over the past couple months. Although now I understand that recursive logic using quick pulses would probably not reduce lag, but would actually increase it.. I have a couple ideas how to reduce lag now, thanks to the marquee project I just completed, so I'll see what I can do to remake this circuit, as a side to my secret joint project with holycookie
Fellow's Arcade System: (Top Priority)
This one is being developed along with the CGOL circuit, but is a bit more complex.. Basically, I'm working on making loadable logic games that fit inside a "cartridge", which will dock onto the game system and be connected with wireless logic blocks. My goal for this project is to have enough games available that you can't keep all the logic in the same sector without causing severe server lag! All the player has to have with them to play a game is a blueprint of the cartridge(s). Simply spawn, plug, and play!
( I use this one GIF way too much, hopefully that can change in the near future! )
Very large project for me, working on developing a type of recursive logic circuit that vastly reduces its massive amount of logic blocks to something a LOT more manageable. Link to it's dev. thread Link to it's wikipedia page.
Update: I pretty much have that recursive logic figured out now, been using several different implementations of it over the past couple months. Although now I understand that recursive logic using quick pulses would probably not reduce lag, but would actually increase it.. I have a couple ideas how to reduce lag now, thanks to the marquee project I just completed, so I'll see what I can do to remake this circuit, as a side to my secret joint project with holycookie
Additional plans outside the dev. thread: Add an editor mode with a blinking cursor and directional controls to change a cell's alive/dead state between calculations. Needs to be completed to be compatible with the arcade system outlined below.
Fellow's Arcade System: (Top Priority)
This one is being developed along with the CGOL circuit, but is a bit more complex.. Basically, I'm working on making loadable logic games that fit inside a "cartridge", which will dock onto the game system and be connected with wireless logic blocks. My goal for this project is to have enough games available that you can't keep all the logic in the same sector without causing severe server lag! All the player has to have with them to play a game is a blueprint of the cartridge(s). Simply spawn, plug, and play!
The cartridge reader itself will contain several logic circuits that I commonly use to cut down on cartridge size. This will include: latch arrays, calculation circuits, randomizer circuits, clock pulse circuits, etc. It also sports a 4 color display that's 21 meters high and 31 meters wide, so plenty of pixels to mess around with
Finally, a list containing my current ideas for cartridge games:
Resource allocation system: (suggested by jumpsuit(linux))
Finally, a list containing my current ideas for cartridge games:
Pretty much done, the logic is all mapped out, I just need to convert what I have into a cartridge.
Update: it's in the cartridge, but there is so much extra room for more logic that I decided to make that cartridge into a party game, with as much as I can fit in terms of small, simple games.
Update: it's in the cartridge, but there is so much extra room for more logic that I decided to make that cartridge into a party game, with as much as I can fit in terms of small, simple games.
Lots of learning done for this project, turns out my idea of quick pulses seems to lag the game, instead of reduce it. Should have seen that one coming, lol. Still! Using the methods learned in the marquee project, I should be able to make this circuit still, albeit with a few more docked things and a bit slower calculation time per frame perhaps.
I have ideas on how to do this project, but nothing concrete yet.. As far as I know, it won't be able to speed up it's calculations like CGOL, it's not like I can get a usable pulse up to the Khz and Mhz speeds that actual arcade machines used :/ It would have to be VERY similar to holycookie's STAR CONFLICT.
This one should be interesting to implement.. I have some concrete ideas about how to store locations/ player/ troop strength using latches and gates. When I get a system set up for risk, it should be relatively easy to create other turn based games using the methods used to make this one.
A 50cent yard sale game I found a long time ago and fell in love with. This game is kind of like chess, but very strange. It's pieces have a single path to follow, and when they finish their path, they reset back into the player's holding area, until the piece is played again. Should be very fun to implement in logic! This will also be a step towards the more complex game of RISK.
what you see here is the first version of the game board I would hope to use. for the red side, we have the 6 game piece slots, and a graveyard further down to the left. There will be a cursor for each player, and as you can see down on the bottom left, red has selected one of his game pieces with the cursor at the top of the screen, and is being displayed on the bottom left, along with it's starting point and path / resting points. Nothing except some ideas on paper atm for this one, I'm afraid.
what you see here is the first version of the game board I would hope to use. for the red side, we have the 6 game piece slots, and a graveyard further down to the left. There will be a cursor for each player, and as you can see down on the bottom left, red has selected one of his game pieces with the cursor at the top of the screen, and is being displayed on the bottom left, along with it's starting point and path / resting points. Nothing except some ideas on paper atm for this one, I'm afraid.
Thanks again trekkerjoe, I don't know how I didn't think of that :p
This one shouldn't need much explaining, as I'm pretty sure everyone on earth has heard of THAT game... I might shift this one to third on the list, right behind the CGOL project. Mostly because it's a really awesome game!
Update: I managed to build a small 4 by 8 tetris grid! Using zero docked entities, it is able to move left and right, rotate, and fall. I still need to build the collision and line creation logic, but it's much further along than it was before.
This one shouldn't need much explaining, as I'm pretty sure everyone on earth has heard of THAT game... I might shift this one to third on the list, right behind the CGOL project. Mostly because it's a really awesome game!
Update: I managed to build a small 4 by 8 tetris grid! Using zero docked entities, it is able to move left and right, rotate, and fall. I still need to build the collision and line creation logic, but it's much further along than it was before.
a pretty complex system that is going to be able to track info about resources taken from storage, such as who took it, and how much they took. Should be fairly dynamic so a player can select any block, and a number between 1 and 1,000,000 of said block.
I'm out of ideas for now, but while I brain storm ( and work my butt off on these projects ) why not give me some suggestions?
I'm out of ideas for now, but while I brain storm ( and work my butt off on these projects ) why not give me some suggestions?
--------------------------------------------
edit 1: added "tetris" to the game console project, added a picture for input, changed some wording a bit.
edit 2: added vaygr marquee board project and a hint in "works in progress" as to a future, undisclosed project! look for the out of place question mark.
edit 3: wow this page needs some updating. changed my year old grammatical error. the acronym is CGOL not CGOF ya dingus. Added the resource allocation system based on jumpsuit's request.
Thanks to Jaaskinal and Dr. Whammy, For checking out my tic-tac-toe game prior to release! Now I have plenty of ways to reduce the size of my future circuits. And thanks to these players for answering many logic-themed questions! HolyCookie, Olxinos, Bench, @Leviticus , Trekkerjoe, and iceman6491!
Last edited: