rborsite's Introduction

RBOR website info!

Info on why Jekyll is cool, what Jekyll does, and how to set up your own Jekyll site locally and on GitHub Pages is in my Programming Historian lesson.

Skip to a section:

Tasks

Stuff we need/want to do for the website.

Sooner:

Change team section from bullets to avatars and short bios
Video time!

Later:

C++ syntax highlighting should be automatic via Rouge, but isn't working for some reason
Change 4 social buttons (under blog posts) to shades of red/dusky purple
Test webapp icon on mobile homepage
Google Analytics: advanced site setup (e.g. tie button clicks/downloads to analytics?)
Twitter profile text, finesse avatar/header image, change email to RBOR Games/B&N email

Done:

Get email field => Google Sheet working; share sheet with team
Remove typing (for now)
Readme info on how to blog
@RBORgames profile customize (added avatar and header image from title screen image, went through settings)
Blog page => each post in full (or expandable excerpt), rather than list of titles PLUS include email-linked author name with each post
After domain setup, check that Google Analytics is filling correctly
Created separate dev repo (only needed for testing things accessing web like email field->Google forms, otherwise test locally)
Check the RSS feed is generating correctly (http://beanandnothingness.com/feed.xml)

I just want to blog

You'll need to create a new file in _posts, using the same naming convention (e.g. 2016-05-9-title-using-hyphens-does-not-need-to-match-post-title.md) and including the same header info inside the file:

change the title
write one of the following tags: news, development, or release (I can set up others if you want them)
make the author line say either nic or jordan (just first name, lowercase)

You can either create this file locally and then push it to the repo (and it'll appear on the site in a few seconds), or you can visit the _posts folder in this repo and use the "create new file" button to write and immediately publish your post.

Markdown cheatsheet

You can style just code that appears inline if you want, or you can...

Create a whole block of code
Tooooooo
Just—like—this

The following markdown:

### Post non-title header
#### Subheader below that, etc.

* Bullets!
* Bullets bullets!
  * Bullety Bullets
* Etc.

1. Ordered list
1. Here's number 2! (you should also be able to type 2. instead of 1. but it could work for both)

For external links:
[A familiar website](http://www.google.com)
Don't forget the http:// in your links or the site will append the link to the blog URL

For external images (not in our website repo):
![](https://www.usa.gov/sites/all/themes/usa/images/Logo_USA.png)

**Important bold information!**
*Italics just get one asterisk on either side.*
For internal links and images (blog post, code, file, etc. that lives in the website directory), you should do something different (which won't work in this README, but will work on your local version of the site and on the Jekyll-generated site):

![]({{ site.baseurl }}/img/teleport.gif)

Note I used {{ site.baseurl }} in that link instead of the full http://beanandnothingness.com/img/teleport.gif
That lets internal links and images work both when working on the site locally and on the live site, instead of breaking on one or the other.

Post non-title header

Subheader below that, etc.

Bullets!
Bullets bullets!
- Bullety Bullets
Etc.

Ordered list
Here's number 2! (you should also be able to type 2. instead of 1. but it could work for both)

For external links: A familiar website

Don't forget the http:// in your links or the site will append the link to the blog URL

For external images (not in our website repo):

Important bold information! Italics just get one asterisk on either side. For internal links and images (blog post, code, file, etc. that lives in the website directory), you should do something different (which won't work in this README, but will work on your local version of the site and on the Jekyll-generated site):

![]({{ site.baseurl }}/img/teleport.gif)

Note I used {{ site.baseurl }} in that link instead of the full http://beanandnothingness.com/img/teleport.gif That lets internal links and images work both when working on the site locally and on the live site, instead of breaking on one or the other.

Local work

You only need to work locally if you want to try stuff not on the live production (public) or dev sites. If you want to do this, you'd need to install some stuff locally using my Programming Historian lesson.

cd to your GitHub/RBORsite folder

bundle exec jekyll serve --watch

Open localhost:4000 in browser (or http://127.0.0.1:4000)

See changes on the local site as you make them: While the site is running, after making changes to website files: save the files and refresh the webpage to see the changes—except for the _config.yml file, for which you must stop running the website and restart running the website to see changes.
Stop local site: Hit control-c on the command line.

Live site

To move local changes to your live site (new post, settings tweak, etc.):

Make the desired changes to your website’s local files.
Open the GitHub Desktop app, make sure your website is chosen in the left sidebar’s list of repositories, and write your commit message summary (and description if desired).
Click “Commit to gh-pages” in the lower left.
After the commit has completed, click “Sync” in the upper right.
Allow 10-90 seconds for your changes to reach GitHub’s web servers, then visit your website and refresh the page to see your changes live. If the change isn't showing up after that, check your email for a failed build message (I will add everyone as repo collaborators and I think that should let you get these notifications?).

rborsite's People

Contributors

Watchers

rborsite's Issues

Text from old blog, to move into about section

@vonkorff said yall may want to move some of this into the about section:

—
layout: post
section-type: post
title: What is Bean and Nothingness?
tags: development
author: nic
—

Welcome to the Bean and Nothingness development blog! Future posts will cover smaller things that come up during the development of the game, both engineering- and game-design-related, but as we kick off the blog it seems good to spend some time talking about the idea behind the game as a whole and how it came to be.

The Game

Bean and Nothingness is a real-time, 2-D, tile-based puzzle game. It looks kind of like this:

![]({{ site.baseurl }}/img/game-look.png)

The puzzles are built around the behavior of the nine types of monsters. The monsters are created by the player out of combinations of beans — the exact beans required to make each monster depends on the puzzle you’re playing — and each one behaves in a unique but predictable way. (For example, the orange dinosaur up there in the corner will run at the main character whenever it sees her, and the sleeping yellow thing below it can explode when it’s pushed.) The monsters interact with the player, the beans, and each other, and most puzzles involve understanding and exploiting these interactions to get to the end without being stampeded, eaten, zapped, drowned, frozen, or blown up.

History and Goals

The project began a few years ago when most of us were in the math Ph.D. program at the University of Michigan. The original plan was to throw together something small over the course of a few months as a distraction from research and teaching, and maybe, if it was fun and we worked well together, we’d try to tackle something bigger after that. Pretty quickly, though, it was apparent that the game we were making wanted to be much bigger, and the project has evolved from there. Now, a few years and jobs later, the development process is very far along; we’ve written almost all the puzzles and landed on a basically final set of mechanics.

The central design decisions behind the game were based on the things we love about the puzzle games we’ve enjoyed the most. Specifically, it was important from very early on that Bean and Nothingness be:

Challenging: A lot of puzzle games start out with a good difficulty curve that plateaus pretty quickly, and the final puzzles aren’t as hard as the mechanics allow.
Deep: The best puzzle games have mechanics that interact with each other well and that can be mined for interesting puzzles for a long time. For us, this means careful consideration of the way each monster will interact with every other (and with the all-important beans).
Deterministic: The puzzle mechanics in Bean and Nothingness are very tactical: they depend a lot on the exact relationships between the positions of the objects involved. For this to work, it is important for the game to behave predictably — for the player to know that giving the same inputs at the same times will always have the same effect.

Stephen’s Sausage Roll and Snakebird are great examples of games that got these things right. Bean and Nothingness has one aspect that these games don’t, though: all of the action takes place in real time. This decision, which was also made quite early, made achieving these goals quite a bit harder, especially the determinism. Most real-time puzzle games have looser mechanics than a step-based game like Snakebird, but in designing Bean and Nothingness it’s been important to us to never sacrifice the sort of precision that allows for deep and complicated puzzles.

What’s Left To Do

Bean and Nothingness is still in very active development, and there’s a lot we haven’t done. We’re continuously polishing the graphics, the sound, and the puzzles, and as of this post we’re hard at work on the story. Keep following for more news!

Recommend Projects

amandavisconti / rborsite Goto Github PK