• Advertisement
  • entries
    10
  • comments
    30
  • views
    2883

Entries in this blog

Play it! | View on GitHub

Now that I am slightly recovered after the Week of Awesome, I want to share my thoughts about what went well and what I have learned after this experience. A quite important part of my project was to experiment with functional reactive programming in games, and I promised to share some reflections about it afterwards. I'm going to talk about that in the second part of the post-mortem, which I expect to publish early next week.

What was great

Community support and feedback

The absolutely best thing about participating in this contest was all the encouragement and feedback I got from the community. Big thanks to everybody who took the time to play my game, read my blog entries, post feedback and encouraging comments, and even find and report bugs!

My game would have been a lot worse without that feedback. Many people suggested features I hadn't thought of or I had dismissed earlier because I didn't think they were that important. The ability to move to the left and better control of the landing position when jumping are clear examples of this. It was also really motivating to see every day people playing the game and posting new feedback.

Browser game

I think that going down the browser route was a good idea after all. The cool thing about the browser is that everybody has one. Distributing your game is so easy: no installation or configuration required, and everybody can play it regardless of operative system or installed runtimes. I could upload the game to my VPS since day one, update it often, and have people trying it out, which was great and I think that it made a difference in the amount of feedback I received.

What I would do differently

Have a level editor

The game I delivered is inexcusably short. Once I had the basic mechanics going, it would have been really easy to add more and longer levels. The only reason holding me back was that I didn't have any visual tool to create and edit them. I created the only level in the game by manually editing a JSON file. As you can imagine, that was a tedious job and I decided to invest the little time I had in solving other stuff. Not having a level editor also prevented me from iterating the level and making sure it was fun and challenging enough.

Next time, I will make sure to have a visual tool to create levels and maps at hand before the contest starts.

Test the delivery format early

When I set off to make a browser game, I set up a local development web server to serve the file and recompile and reload the changes quickly. I knew that I would end up delivering an index.html file with a .js bundle and that the judges would load that file from the file system instead of a web server. That should make no difference, right? Wrong! Turns out that Chrome, among other browsers, doesn't allow AJAX requests when loading a file directly from the file system. And guess how the rendering library I used loads spritesheets? Exactly: AJAX calls.

I should have tested running the game from the file system since day one. Instead, I only tried it when I was about to upload the final submission. If I had known about the AJAX issue earlier, I could have written my own resource loader, or bundled the game with electron. Instead, by the time I noticed the issue, I didn't have the time nor the energy to do something about it.

Even though the game can still be run locally with Firefox, I provided a python script to run it on a local web server, and some judges didn't mind playing it on my VPS, my developer soul still hurts because I wasn't able to deliver software that runs with a single click.

Conclusion

This community is awesome. I got far more interest and feedback than I expected. I liked the experience of making a browser game, even though at the end it wasn't as smooth as I thought, and I definitely need to get a level/map editor next time.

If you are interested in reading my musings about using functional reactive style in games, stay tuned  for the second part of the post-mortem.

Play it! | View on GitHub

Strawberry Alert is good enough to go. I didn't have time to fix everything I mentioned in my last post, but I could add the following:

  • Support WASD to move.
  • With arrow down (or S) the character crouches, making it easier to avoid enemy fire.
  • The game state is not updated anymore after the level lost dialog appears.
  • There was a bug that the aliens could fire after dying. This is no more.
  • Another bug reduced the player's hit points when a bullet collided from behind (like when an alien fires and the player is slightly past it, the bullet appears with the tail colliding with the player). This isn't happening any longer.

Overall, I'm quite satisfied with the end result. The only thing that I really wish I had time to do is improve the collisions that are still a bit wibbly-wobbly.

Also, I realised today that the rendering library I use loads the spritesheets via AJAX and, guess what? Some browsers (hello Chrome ¬.¬) don't allow AJAX calls when executing an html file directly from the file system. I'm sure there is a way to fix this, but I don't want to spend the few hours of Sunday left digging into it. The game works fine when running it from the file system with Firefox, at least, and I provide a python script to run a simple web server otherwise.

strawberry.zip

Play it! | View on GitHub

One more day to go. I think that the game is in a pretty good shape already. There are a couple of issues that should be fixed, and I can add more features, but I think it's close to something deliverable.

Today I've acted on the feedback I received in my previous entries (big thanks to @slicer4ever, @Thaumaturge and @Scouting Ninja!):

  • I fixed a bug that allowed the player to double-jump while in the air, which, mixed with the wibbly-wobbly collisions, could make it fall through the platform. No more double-jumping.
  • I implemented a proper camera. Before everything was just rendered relative to the player position. Now there's a camera object that moves forward when the player gets to a certain distance from it. Currently, that distance is quite short (100px), I'm considering making it bigger, maybe up to 1/3 of the screen.
  • Thanks to the feature above, now the player can also move to the left. The camera doesn't move back because then it would be too easy to chase aliens that escaped the player.
  • Now it is possible to move a bit the player while in the air, hopefully making it easier to control the landing position.
  • Aliens now shoot. The player loses a life if a bullet hits her, and the level if she loses all her lives.

Tomorrow is the last day. I'll be happy if I can add half of the features below:

  • Stop updating the game when the level is finished or lost. Currently, the player can keep moving and fighting even when the level lost dialog shows up.
  • Add a crouching action when the down arrow is pressed, to make it easier to dodge alien fire.
  • Balance the difficulty. I've been able to finish the level with the current settings, but I haven't really tested how hard it is. I want to try out different combinations of alien shooting speed and hit points.
  • Add some sort of feedback when the player is hurt. Maybe a short animation or similar.
  • Make the collisions less buggy. Currently, the sprites sometimes end up on the middle of the platforms instead of the top.
  • Fix walking animation. This one is going to be hard. By the end of the level, the walking animation usually looks slightly off. I'm probably doing something wrong with the rendering library, but I have no idea what it is.

Play it! | View on GitHub

End of day five. The current state almost resembles an actual game. I added some platforms so that the player can jump around and a flag at the end of the level.

Next things on my list to implement:

  • Move backwards.
  • Scoring.
  • Hit points and alien attacks.

I will be happy if I manage to finish these three things by the end of Sunday.

Play it! | View on GitHub

Today I finally added aliens to the game! There is no level design or hit point system whatsoever. There are four aliens walking to the left. If the player attacks them, they die, otherwise they keep moving until they are out of sight. It is some progress, at least. I couldn't do much more because I spent most of the time chasing a silly bug. I created a template for the aliens with, among other properties, the speed. And since all aliens were created from that template, when I modified the speed in one alien, it changed of course the speed for all aliens, because it was a shared reference.

The cause wasn't obvious to me at the beginning because what the bug caused was that the second alien, fell through the ground. The issue was that after the collision check for the first alien, I correct the position and then I set the vertical speed to 0. To correct the position I simply subtract the current vertical speed from the vertical position. So the second alien had the speed already set to 0 when correcting the position, therefore the position didn't get corrected. It's been a while since I felt this stupid.

My plans for the future are:

  • Create a bit of a map, with platforms and aliens coming from different places.
  • Add a hit-points system. The hero would have 4 hit points and lose one each time she collides with an alien. If she reaches 0 hit points, the game is over.
  • The player will only be able to move forward. Once he gets to the end of the level, the game is over and the final score depends on how many aliens were slain.

 

Play it! | View on GitHub

I couldn't do much today, but at least I added collisions and jumping. You won't see much difference, but now there's gravity pulling the character down and she's colliding against the floor instead of having a fixed y position.

After jumping or attacking, the character doesn't resume movement if the right arrow is pressed, I will try to fix that tomorrow (Fixed, I should totally go to sleep now). Also, either tomorrow or Friday I should be able to start adding enemies and stuff.

My initial idea was to let the player move freely through the map and have as a level goal clear it of alien enemies. I'm thinking now that an easier option might be make it endless runner style and have a certain amount of time to kill as many enemies as possible. I wish I had time to try out both and see which one is more fun, but I doubt it will be possible.

Play it! | View on GitHub

There is not much progress today. I styled the main menu view, added the attack animation and a moon in the background.

Now I need to figure out how to add collisions and make aliens chase the player with map-reduce. Tomorrow I'm kind of busy, but hopefully I will be able to sketch some diagrams.

Strawberry Alert: Day 1

Today I have started working on the Week of Awesome V challenge. The working title for the project is Strawberry Alert. I generated it randomly and it is very unlikely to change due to time constraints.

The Project

The themes I want to try are Alien invasion and Castles. My intention is to create a side scroller where the hero must defend her castle from an alien invasion.

With this project I want to explore whether functional reactive programming can be successfully used in games. I intend to capture the user input and time effects into streams, apply map-reduce to these streams to generate the game state, and finally render that game state to the screen.

I will be happy if I can deliver something playable by the end of the week. Unfortunately, this week I'm back to work after vacation and I've got a few social commitments that I must honour, so I expect to be able to dedicate only about twelve hours more to the project.

So far, I have managed to put together a parallax background and the walking animation for the hero sprite.

The Art

I am using a hero sprite and castle tiles created by Jetrel. I still need to find sprites for the alien enemies.

The Tools

I will target the browser and create my game using JavaScript. My weapons of choice are:

  • pixi.js: a rendering library for WebGL and Canvas.
  • cyclejs: a functional reactive framework.
  • xstream: a stream library designed to work well with cyclejs.

The Links

The code is available on GitHub and, since it is a browser game, I will deploy my daily progress so that you guys can try it out.

 

Hexagons

I have recently started working on a new side project. My goal is to develop a simple turn based strategy game with a space-y theme.

I'm set on using a hexagonal tile map, because everybody knows that hexagons are awesome. Developing a hexagonal tile map looked like one of the first technical challenges I would have to face, so I started coding. And by coding I mean working out the math with pen and paper.

The first thing I needed was a coordinate system to assign coordinates to each tile. I decided that the origin (0, 0) would be the tile at the left-center corner. Every tile to the up-right diagonal would increase the x in 1 and every tile to the down-right diagonal would increase the y in 1. Now I can store the tiles in a dictionary identified by these coordinates and use math to retrieve the nearby tiles and calculate the distance between two tiles very easily.

The image below illustrates how the coordinate system looks like.
hexagons.png

Having that system, I had to find a way to translate these coordinates to the screen coordinates and back to render the map and interact with the tiles using the mouse. This took a fair amount of drawing and multiplying things by sin(30o) and sin(60o). It is probably easier than it felt at the moment, but my rusty geometry skills made it look hard. I can't say it wasn't fun, though.

I put together a simple script to generate and render a hexagon tile map. In the video below you can see the current functionality I have.

That's all for now. My next step will probably be to put together some mechanics so I have something to prototype on.

  • Advertisement