journal-colin.txt

2/5/16:
	This week I studied what we can do with Heroku, and
	whether it's going to be suitable for our project.
	So far, it appears that it will work, since it has
	support for plenty of technologies, including
	Node.js, websockets, and PostgreSQL, which we'll
	probably be using.  I wrote a rough protocol
	specification outlining generally what we're going
	to do for client-server-communication.  I also put
	together the initial server implementation, with a
	very bare-bones web server and a slightly more
	useful WebSocket server.  It's no game yet, but
	we're getting there.  As far as I can tell, Heroku
	only works with HTTP traffic, which is why the
	server is using WebSockets instead of normal
	sockets.  It's likely that we'll need a web server
	anyway though, so I think it's a good idea.  I also
	set up a PostgreSQL server on Heroku and my laptop.
	I studied db-migrate and it looks quite useful.

2/13/16:
	This week I started working with db-migrate and
	used it to set up the users table in the database.
	I also briefly studied password hashing methods and
	(probably prematurely) settled on bcrypt.  Not that
	we store any sensitive data at all, but prevention
	is simple and good practice.  I found
	bcrypt-nodejs, which should simplify trying to use
	it.  It seems to store the salt as part of the
	hash, so we don't need a separate column for that.
	In other news, I did a little more work on the game
	server, laying foundations to make it easier to
	handle messages from the client, and using that to
	allow users to join game rooms, though they're not
	actually useful yet, currently they only notify
	other users of your presence.  I also tried to
	detect disconnections and remove those players
	from their rooms.  I think it's working, but
	that's what testing is for!

2/21/16:
	This week (I start these with that phrase every
	time...) I worked more on the socket server, making
	it possible to start a game, though all that means
	right now is generating a few nodes with random
	positions and sending them to the clients.  We
	decided to make the battlefield have width and
	height of 100 internally for simplicity, and we'll
	scale it up to the screen size in the client once
	that actually exists.  I also changed the initial
	authentication message to actually do logins from
	the database.  Hopefully soon we'll figure out how
	the game mechanics are going to work well enough to
	implement them.  I'm not sure how much to leave to
	the clients and how much to handle server-side,
	since there are advantages to both, and both will
	have to do some computation.  We learned that the
	database is probably not scrublord, and can do
	queries.

2/28/16:
	Not much to say for this week.  Not much really
	happened, but we did get more visible work done
	than usual.  The signup page works now!  Probably.
	Last week, the progress was limited to having a
	page and checking whether the user "post.username"
	exists because Tony did it wrong.  Now, we check
	that their chosen username doesn't already exist
	and that it doesn't contain a colon, because we
	use that as a delimeter in the auth message, then
	adds the user to the database.  Perhaps we should
	ban other characters, but we haven't yet had a
	good argument either way.  Initially, the database
	had an id column, but we didn't really need it, so
	I added a migration to delete the table and
	recreate it because db-migrate is annoying about
	messing with the primary key.  We had an issue with
	a race condition causing the post data to never be
	recieved occasionally.  Hopefully it's fixed now.

3/4/16:
	The game client exists now!  It doesn't do much,
	but it's something.  It currently just displays a
	dialog that can accept credentials and connect to
	the server.  I used Java-WebSocket to handle
	connecting to the WebSocket server, as it appears
	to be almost the only library that attempts to do
	it.  It's a bit different than using WebSockets in
	JavaScript in several ways.  It requires
	subclassing the WebSocketClient class to use it,
	instead of the JavaScript approach using event
	handlers bound to the object.  It also doesn't
	actually do the connection until you call a method.
	The subclass idea was a bit of a problem for the
	way I was planning on making the client.  My plan
	was similar to the way I did the server, using an
	event handler to handle the initial auth message,
	then changing the handler to the main one.
	Unfortunately, that's not really possible with the
	subclass approach, so I made the subclass have a
	listener for the first message.  It's a bit weird,
	but it should work well.

3/30/16:
	It almost looks like a game now!  The client now
	has a more useful window than just "Welcome to the
	absence of a game", allowing joining rooms, seeing
	the other players in the room, starting the game,
	seeing the nodes, and winning by having everyone
	else leave.  The node info is provided by the
	server in JSON format, so I'm using JSON.simple to
	parse that from Java.  I had an odd issue with
	scaling where it jumped in scale instead of being
	smooth, but it turned out to be just an issue with
	using integer division where it shouldn't be.  The
	server has been improved slightly as well to make
	it easier to write the client and fix some other
	issues.  It now informs the client of leaving a
	room, sends a message when they win, and shouldn't
	crash when you create a user.  It also no longer
	allows you to start a game without another player
	in the room.

4/9/16:
	The game works!  You can play!  You can now send
	units, see units, and destroy units.  You can
	capture nodes and win.  I found lots of issues
	with the server code that I hadn't noticed before
	because they didn't matter, including placing
	nodes horribly, never destroying unit groups, and
	some others I forgot about.  I also wrote a few
	unit tests because that's always nice.  It also
	means we get a nice "build passing" badge in our
	README from Travis CI.  Eventually we might get
	it to automatically deploy when we make a new
	release.  Eventually we'll need to change the
	connection handshake to ensure protocol versions
	match, but I haven't done that yet.  For testing,
	I wrote a small script to connect to the server
	and join a room so I can start a game without
	running the whole client twice, since my computer
	is really bad at that.

4/16/16:
	A lot of stuff happened this week.  We got some
	playtesting in so we could find issues, and we
	found issues.  If a player left during a match,
	the players after them became shifted up and
	switched their colors.  If a player sent a unit
	group from a node that then got captured, the
	units would change to the capturing player's
	color.  If two players' units were on a neutral
	node, nothing would happen.  Hopefully all that
	should be fixed now, and several tweaks have
	been made to the gameplay.  We now have a
	matchmaking feature, so you can just play with
	people without using the rooms.  The initial
	handshake now verifies your client version
	matches the server.  Units now take longer to
	generate, and even longer if they're being
	attacked.  Nodes now take a few seconds before
	they can be claimed.  You can now make your
	units retreat.  I redid how the client handles
	multiple owners' units on a node so it matches
	the server, then added a sync feature so the
	server can send updates about where all the
	units should be.  I also set up Travis CI to
	automatically deploy code to the test server
	and build a client jar whenever we commit.

4/23/16:
	stupidclient.js now has stupid AI.  Originally,
	it just spammed the server with attack commands,
	but that just caused chaos, retreating, and FPS
	drops for other players.  Now it keeps track of
	the nodes it owns and sends those nodes to
	random places.  It's still pretty bad at winning.
	I added support for spectating a room so that I
	could watch two bots play each other without
	adding nodes of my own.  I added support for
	chat, but it hasn't gotten support on the client
	yet, so I also made the server accept slightly
	older versions of the client because they
	technically still work, they just won't receive
	chat or start spectating rooms.  I improved the
	web stuff a little, now there's a header on each
	page and the signup page uses ajax so you don't
	have to go back if you get an error.
	Unfortunately, that made the form data have a
	different format, so I added the multiparty
	module to parse it and used form-data to test it.

4/28/16:
	This week we implemented chat.  It's pretty
	simple, but swing doesn't make it easy to make
	things lay out the way I want them to.  Long
	messages caused the sidebar to extend, and even
	longer messages could completely obscure the game
	area.  If enough messages were sent, they wouldn't
	show up because they would overflow the container.
	I think it's all fixed now.  I replaced the
	JLabels in the chat list with JTextAreas, but then
	long messages would be partially covered by
	subsequent messages.  I ended up doing weird
	things with sizes, and somehow it works now.  I
	put the chat area in a JScrollPane so you could
	scroll, but the scrollbar would cover part of the
	message and it didn't autoscroll.  I set it to
	hide the scrollbar and stay scrolled to the
	bottom, which I guess is good enough.  I rewrote
	the tests so they make more sense, but now they
	have tons of nested functions.

5/7/16:
	This week we discussed the possibility of adding
	spells.  I think the current plan is to sacrifice
	units for energy that can be used to cast spells
	from a set along the bottom of the page.  I also
	added a simple "How to Play" page to the server
	and added support for serving arbitrary files to
	support that.  I wrote an Android client, so it's
	a mobile game now.  I moved all the GUI related
	classes to a new package so I could take the rest
	and include them in the app.  That helped a lot,
	since that meant I only had to reimplement GUIs,
	not the whole game.  If we ever need to support
	another platform, it won't be that easy.  I've
	noticed it's difficult to diagnose Android
	crashes, since they only show up in the device
	log that also has warnings and errors from every
	other app on the device, and sometimes the error
	doesn't seem to show up at all.

5/16/16:
	This week, not much happened.  The game is pretty
	much done besides possibly adding spells.  I seem
	to have broken winning by changing == to ===,
	because somehow the variables used are changing
	types between numbers and strings.  I changed some
	back, so now it should work.  I also modified the
	bot so it could be included from the server code.
	Now, if you wait too long in a matchme room, the
	bot will join you.  I also added commands that
	can be issued by an admin in chat.  It looks like
	Android apps can check whether they were compiled
	for release or debug, so the app will connect
	to either the main or test server based on that.
	We also need an icon for the app.  Right now, I'm
	using a green circle, since that's the best I came
	up with.  This sentence is only here for word
	count.

5/22/16:
	I decided to rewrite how drawing works.
	Previously, drawing was done using AWT Graphics
	for the desktop client, and Android Graphics for
	the Android client.  This meant that everything we
	draw had to be implemented twice.  That's not too
	bad, but it's still an annoying extra step.  Now,
	I've added an abstraction layer so that the
	drawing is consistent between both platforms.
	Currently, it supports drawing circles and text,
	since that's all we need.  This also means we can
	take screenshots as SVGs, which is not something
	you see a lot.  I also worked on login tokens.
	We can now generate tokens that can be used to
	log in multiple times without saving your actual
	credentials on the client.  I've done some work
	on using it, but only for Android, since the
	desktop client has a server selector, which makes
	things weird.  I also fixed spectating, which has
	been broken since the game start redesign.