next »

[lithander]

EDIT: Check this blog post for a comprehensive description of the project.

This survival of the fittest, which I have here sought to express in mechanical terms, is that which Mr. Darwin has called 'natural selection', or the preservation of favoured races in the struggle for life.
 ~Herbert Spencer

Core Society is a digital organism simulator where programs live in a rectangular Grid of Cores, not unlike a cellular automata.

In the famous cellular automata Conway's Game of Life quite stunning complexity can emerge despite a very simple set of rules: Cells have only two different states (On or Off) and effect only their direct neighbourhood.

In Core Society each cell is a programmable microprocessor with a custom architecture and instruction set. Most of the instructions deal with the axioms of computation. But some allow the core to interact with adjacent cores and that's where stuff get's interesting. There's an energy mechanic that governs the execution and interaction of programs. Energy is a precious resource each core accumulates. It's spend when a core executes instructions. It's also what prevents adjacent cores from writing into one's memory. There is an instructions that allows you to transfer energy into a neighbouring core. And one to drain energy from it, respectively. So a program that has spread on multiple cores can make the nodes work together to establish dominance of the grid against competing programs.

My hope is that Core Society will provide players a platform to enjoy some creative low level programming in a competative environment. Not unlike what Core War did some 30 years ago but with fundamentally different gamemechanics.

For now the project is still in it's infancy. There's a first version of an assembler/debugger.


The program you see on the left calculates prime numbers and stores them in free words in the 5th row.

And you can watch it chrunching numbers...

...eventually filling its memory with colorful primes!

[po_bear]

Low level programming is so much wonderful masochistic fun. Your project is exciting. Good luck.

[William Chyr]

The concept sounds like it has the potential to be a very interesting game. And also quite a complex one. I read the description three times, and still not sure I fully understand it.

But yeah, low level programming... I did a bit of that a couple of years ago, and I'm pretty sure I still have nightmares from the experience.

Anyway, looking forward to seeing how this develops!

[lithander]

It's interesting that both of you associate "nightmares" and "masochism" with assembly programming. I know what you mean. But I'm convinced that if you take a monster like x86 and strip out all things that were introduced to overcome hardware constraints, save memory, optimize performance or maintain compatibility you end up with something quite beautiful.

The core & grid architecture is purely virtual. Performance is not an issue, memory is not an issue - the constraints are artificial and deliberate choices.

For example a core has only 256 words of memory. But instructions can manipulate it directly. No MOVing of data in and out of registers is necessary. There are no registers! (And neither are there Flags or Interrupts or whatever)
It's still low level programming but my hope is that it will feel more like a complex puzzle game then work. Currently (as you can see in the screenshot) there's a mnemonic based listing that is barely readable. But thats work in progress and I hope I'll come up with a more user friendly way of building programs in Core Society. There's a lot of untapped potential there...

And WillyChyr, I'm sorry that my description wasn't of more use to you. If you want me to elaborate feel free to ask!^^ I just didn't want to put all the clutter into the first post... would have done more harm then good, imo.

[Belimoth]

Cool idea! It'll be fun to see what emerges from this.

[William Chyr]

And WillyChyr, I'm sorry that my description wasn't of more use to you. If you want me to elaborate feel free to ask!^^ I just didn't want to put all the clutter into the first post... would have done more harm then good, imo.

Oh hey - no need to apologize. I wasn't saying your description wasn't good. The description is fine. I was just saying that you have a pretty complex game premise, and it takes a bit more concentration on the part of the reader to understand, as opposed to a game where you just shoot zombies. 

[locknic]

This looks fantastic. I've always had an interest for assembly language and low level programming, but never really learnt much about it. The closest I've come to this was probably with those little kits you get where you have to solder everything together, or maybe redstone in minecraft. A game like this would be a really cool way to introduce people to stuff like that. :D

[Prads]

For example a core has only 256 words of memory. But instructions can manipulate it directly. No MOVing of data in and out of registers is necessary. There are no registers! (And neither are there Flags or Interrupts or whatever)

You stripped all the fun!!!
lol
Interesting project, I like low level programming and will be watching this project.

[jonbro]

ooh, corewar-likes! I am curious to see where this goes, it is an interesting idea. Definitely niche, but nothing like niches, right?

[lithander]

Last night, for the first time, the pieces came together in something that could almost qualify as a 'game-like' experience!

The current version of the protoype looks like this.



In the Core Grid window you see a small grid of empty cores. There's a certain amount of Grid Power (50000 in the screenshot) that will be distributed to the cores and spend executing instructions. The instruction set contains a 'special' instruction (ISC) that will increase the Score by a specified amount (between 0 and 255). The amount to raise the score by equals the energy cost of executing the instruction. So if all Grid Power would be spend exclusively on ISC instructions you'd end with a perfect final Score of 50000.

But here's the challenge: You may only write a programm to ONE SINGLE CORE!


How can you achieve a high score?


A naive approach is to write a program consisting of only 2 instructions. The first would increase the score by a certain amount (like e.g. 31) the second would move the instruction pointer back to the first.



This strategy generates only 2914 points. The main problem is that only one of 16 cores actually contributes to achieving the goal of a high score while the remaining 15 waste all the energy they receive on No-Op operations.

A more clever solution is to create a program that will first copy itself to adjacent cores and only then work on increasing the score. That way the program will spread all over the grid and eventually all available cores can contribute to the overall score!

That way I managed to convert 80% of the available energy into score, achieving a score of 39931.



Writing that program (you can see it in the first screenshot) and optimizing it was pretty entertaining. With more work on the IDE, documentation and coming up with interesting challenges I can imagine this to be a lot of fun if you're crazy enough to like that kind of stuff!

So in a playable version there could be a set of increasingly difficult puzzle-levels to beat. There's no reason why all challenges should start with a blank grid and there's the whole energy transfer and shielding thing that the above example doesn't even touch so it shouldn't get boring quickly.

Questions

I'm unsure about how to wrap this core gameplay up to make it appealing.
Would players be more interested if the challenges were embedded in some kind of cyberpunk narrative?
Is it cool to break the fourth wall and address the player directly by giving him the tools and documentation like he would interact with any other 'serious' program on his computer? Or does it need to be presented in a fullscreen, traditional video game style?
Do you want immersion ("I'm this crazy talented decker hacking an alien AI or whatever") or rather an intellectual real-world challenge, maybe in a competative style (highscore boards, a community forum) like playing chess as a sport?
Do you know any similar games that I could have a look at for ideas? (Space Chem comes to mind)

I'd really love to hear your opinions on this!

[Kurt]

This looks great, commenting to watch.

[sublinimal]

Woah. This is great stuff. Looks fun, sort of educational (or at least makes you think in new ways), very niche and certainly interesting.

[lithander]

Thanks a lot for your positive feedback! It means a lot to me! I've never had a project that was harder to explain to friends and family. "And you consider that a game? Shouldn't games be about having fun?" I mean this isn't the next Call of Duty but there *are* people having fun with programming and elictronical engineering as hobby.
But of course usability and UI are the biggest challenge if I acutally want the game to appeal to anyone.

Are Mnemonics a good idea? Traditionally each instruction in assembly language is represented by an acronym of 3 capital letters. But of course this means that you have to remember two things: what an instruction does and the acronym it stands for. But would "set instruction pointer to 10" instead of "SIP 10" really make anything easier?

Next problem: Hex numbers. The core has 255 words of memory that are conveniently adressable by a two digit hex number. But I guess that people aren't used to working with hexagonal numbers. I could use a decimal number system just as well. It might be easier to pick up but in the long it just doesn't fit a world of bits and bytes as well as hex numbers. So what would you prefere?

For now I'm going to run with the hex number system and 3-letter-mnemonics. But I'm reworking the way adresses and number literals are distinguished. Currently a 2-digit hex number is treated as an address and a 4 digit hex number is treated as a literal number, but all those leading zeros hurt readabily and are more typing work.
So instead I'm considering to just prefix literal numbers with an '!' - without the prefix any number is considere to be an adress.
Also I'm going to introduce labels to make branching easier.

With these changes the code of the program from the last post would look like this:

Code:

1: 1
:eval_target
TGT 1
RDW 0 2
IFS 0
NXT next_target

:prepare_copy
SIP !10
SET 0 !1
:copy
STW ~0 ~0
INC 0
IFL 0 !17
JMP copy
SIP !2

:next_target
INC 1
IFL 1 !5
NXT next_target

:work
ISC F
JMP work

... and here is what the code means ...

1: 1	Put the number 1 at address 1 (a core has 255 addressable words)
:eval_target	Label the following address (2) 'eval_target'
TGT 1	Take the number at address 1, interpret it as direction, and use the adjacent core in that direction as the target for future instructions
RDW 0 2	Put the number at address 2 in the target core at address 0 in the executing core
IFS 0	If there is some number other then zero at adress 0 execute next instruction
NXT target	Set the instruction pointer to the address labeled 'target'
:prepare_copy	Label the following address 'prepare_copy'
SIP !10	Set the instruction pointer of the target core to 10
SET 0 !1	Put number 1 into address 0
:copy	Label the following address 'copy'
STW ~0 ~0	Treat the number at address 0 as an address. Transfer the number at this address in the target core to this address in the executing core.
INC 0	Increase the number at address 0
IFL 0 !17	Execute the following instruction only if the number at address 0 is less then 17
JMP copy	Set the instruction pointer to the address labeled 'copy'
SIP !2	Set the instruction pointer of the target core to 2
:target	Label the following address 'next_target'
INC 1	Increase the number at address 1
IFL 1 !5	Execute the following instruction only if the number at address 1 is less then 5
NXT target	Set the instruction pointer to the address labeled 'copy'
:work	Label the following address 'work'
ISC F	Increase Score by F (decimal 15) which will cost 15 energy.
JMP work	...and continue to add score by setting the IP to the last instruction.

You might wonder why there are 3 different instructions for setting the Instruction Pointer. Well... SIP sets the instruction pointer of the target core. NXT and JMP set the IP of the executing core, but NXT stores the absolute address and JMP the offset from the current address.

Any suggestions how to improve readability?

[ekun]

This looks pretty neat, I see a lot of potential in this game as an educational tool.

Any suggestions how to improve readability?

I think it's readable enough as it is, although what would help a lot is syntax highlighting/validation in the IDE. Also, maybe if you hover your mouse over an instruction it'll tell you what it does as well as its arguments?

[lithander]

Thanks for the kind words and good sugestions, ekun!

Syntax Highlighting and validation should be easy enough to add. Currently I was planning to make a PDF documenting all available instructions. But of course that could be integrated into the IDE aswell. In the IDE, instead of looking up generic descriptions based on the Op-Code, I could generate explainations like "Put the number 1 into memory at address 0" when "SET 1 !1" is encountered.

[lithander]

Here's a documentation of the complete instruction set including an explaination of the syntax etc.

http://files.pixelpracht.net/coresociety/CoreAssemblyManual.pdf

I'm currently trying some test scenarios and challenges. Beating them can be quite fun already but I guess for someone with less insight into the system it would be pretty hard to get started right now. I actually have a hard time to assess it from an outside perspective. So... if anyone wants to get an early look at the game and try for a highscore just PM me!

[lithander]

Decided to make some tutorial-style videos to explain the concept and usage of CoreSociety.

Here's the first installment:

[ekun]

I watched your first video and found it interesting, I look forward to more in the series.

After watching the game in action, I was considering how to make the game more visually appealing and accessible. One idea that came to mind is to anthropomorphize the cores and give them some personality. Something as simple as a facial expression on a core that shows the 'health' or status of the core's program could be enough. But basically I think the game could use another visual indicator of the state of the grid besides the instruction pointer and the charge bar.

The mechanics look fun so far though, keep up the good work!

[lithander]

Actually there's allready a pretty sophisticated visualization of the core state in place. The problem in the introduction video is, that the core's memory is blank.

I agree that everything that helps to make it more acessible is a good thing. But I'm not sure how to implement your suggestion to anthropomorphize the cores to gain insight into it's state. The state of a core is mostly defined by it's memory but it's not clear what that state means. Is it good or bad? You can write programs that modify their memory to change the behavior or change their neigbours. You never know wether a word is value or instruction. So the only honest visualization seems to be a visualizatin of the memory's content on the word level. But it's not ideal... because despite all the colorful pixels it's not really human-readable.

Here's how it looks like when the cores are actually doing something.



The scenario works like this. The red ones execute a very simple program that lowers the overall score. The blue ones try to shield themselves and only when the shield is fully charged they also decrease the score. The green core is the only one the player can write to. And there's 100.000 energy to spend.

What you see in the animation is how my reference solution solves the challenge. First it copies itself to the north. The copie does the same. Secondly it starts copying itself to the right and when it's done with that it will transfer all energy to it's right neighbour. The right neighbour is adjacent to the shielded "enemy" cores and with it's own and the transfered energy starts to weaken the shield. As soon as the shield is down the program starts overwriting the enemy cores, when that is done it will also transfer all energy to the right neighbour. So once the second row of shield is reached the attacking core has a good chunk of the row's power at his disposal to weakin it quickly. Once a row is fully overwritten the program detects a friendly core ahead and starts to use all energy to raise the score. After a while all "enemy" cores have been hijacked so all cores are now either raising the score or providing their power to help. This program manages a score about 25k. And all this seemingly complex behavior is defined by only 66 bytes.

[ekun]

But I'm not sure how to implement your suggestion to anthropomorphize the cores to gain insight into it's state. The state of a core is mostly defined by it's memory but it's not clear what that state means. Is it good or bad? You can write programs that modify their memory to change the behavior or change their neigbours. You never know wether a word is value or instruction. So the only honest visualization seems to be a visualizatin of the memory's content on the word level. But it's not ideal... because despite all the colorful pixels it's not really human-readable.

That's a good point.

Maybe there could be a way to designate "ownership" of cores? Like if each word in a core had an owner, the owner being whoever wrote that word in that position. If the owner is another core, than it uses that core's owner. This would mean introducing new metadata to the memory container of a core, but it would allow for some way to show a state of a core besides its memory. Mostly thinking out loud here, not sure if it would work...

The GIF explains what a scenario would look like much better, thanks!