Fellowship by TheMonsterFromTheDeep
Fellowship is a game where you are a wizard with a purple top hat who thought he could travel back in time and create copies of himself but ended up only being able to magically bring boxes, bridges, and springs into being from another dimension.
Essentially, I started with an idea where I thought I would make the single control send you back in time, but rather, I ended up making it so you could build stuff.
The name came from the theme that sadly didn't make it past slaughter - "fellowship of the whatever."
As it is, I started the whole project when the theme read "One button control", so that's the one I based it off of. If you like, my second button is the mouse pointer.
This is my first Ludum Dare entry to:
-Have music
-Be winnable
-Be losable
-Have levels
-Play at an almost sane pace
--> I really need to get better at optimization: My game takes up the entirety of 120 * 90 pixels at its raw resolution, and yet it runs slower than like any other game I've played.
NOTE: THE GAME CAN BE RESIZED. Maybe next time I'll have it start maximized.
The only real control is clicking; the menus in the game are self-explanatory.
(This is also my first game to have real menus)
Additional controls:
R -> Reset level (never necessary)
P -> Pause level
Known bugs / things:
-The last level will no longer be unlocked once played. This is because the integer that stores the highest unlocked level will then have the value of 18, but to check if the last level is unlocked, the game only checks if said integer equals 17, rather than if it is greater than or equal to 17. The last level can be played again by playing level 16 or by changing the number in "fellowship-save.txt" to 17.
-"fellowship-save.txt" is saved in the RUNNING directory of Java - so for some linux distros, this is by default something like the root folder or something (I'm not really sure - I don't use linux yet) but so if you want to make sure the file is saved in the same directory as the jar file, run the game using the java command from the command line while inside the directory with the jar file.
EDIT: I've uploaded a post-compo version of the game.
Right now it:
-Is more standalone: no longer requires a library file
-Has a fully working level select screen
-Has two command line arguments: size and difficulty. Size is an integer specifying screen size. 5 is the default. Difficult is an integer representing how slow the game should go. 1 is the default. 2 will make it go half as fast. 3 will make it go one-third as fast.
To use the command line arguments, do java -jar Fellowship (Post-Compo).jar
EDIT 2: If you want to have a sort of "walkthrough" of the game, watch this:
https://www.youtube.com/watch?v=drW_QckUuCQ
Essentially, I started with an idea where I thought I would make the single control send you back in time, but rather, I ended up making it so you could build stuff.
The name came from the theme that sadly didn't make it past slaughter - "fellowship of the whatever."
As it is, I started the whole project when the theme read "One button control", so that's the one I based it off of. If you like, my second button is the mouse pointer.
This is my first Ludum Dare entry to:
-Have music
-Be winnable
-Be losable
-Have levels
-Play at an almost sane pace
--> I really need to get better at optimization: My game takes up the entirety of 120 * 90 pixels at its raw resolution, and yet it runs slower than like any other game I've played.
NOTE: THE GAME CAN BE RESIZED. Maybe next time I'll have it start maximized.
The only real control is clicking; the menus in the game are self-explanatory.
(This is also my first game to have real menus)
Additional controls:
R -> Reset level (never necessary)
P -> Pause level
Known bugs / things:
-The last level will no longer be unlocked once played. This is because the integer that stores the highest unlocked level will then have the value of 18, but to check if the last level is unlocked, the game only checks if said integer equals 17, rather than if it is greater than or equal to 17. The last level can be played again by playing level 16 or by changing the number in "fellowship-save.txt" to 17.
-"fellowship-save.txt" is saved in the RUNNING directory of Java - so for some linux distros, this is by default something like the root folder or something (I'm not really sure - I don't use linux yet) but so if you want to make sure the file is saved in the same directory as the jar file, run the game using the java command from the command line while inside the directory with the jar file.
EDIT: I've uploaded a post-compo version of the game.
Right now it:
-Is more standalone: no longer requires a library file
-Has a fully working level select screen
-Has two command line arguments: size and difficulty. Size is an integer specifying screen size. 5 is the default. Difficult is an integer representing how slow the game should go. 1 is the default. 2 will make it go half as fast. 3 will make it go one-third as fast.
To use the command line arguments, do java -jar Fellowship (Post-Compo).jar
EDIT 2: If you want to have a sort of "walkthrough" of the game, watch this:
https://www.youtube.com/watch?v=drW_QckUuCQ
Ratings
| Coolness | 68% | 3 |
| Overall | 3.24 | 474 |
| Audio | 3.10 | 271 |
| Fun | 3.12 | 509 |
| Graphics | 3.09 | 475 |
| Humor | 2.65 | 353 |
| Innovation | 3.58 | 229 |
| Mood | 3.08 | 393 |
| Theme | 3.26 | 796 |
I like the building mechanic, but holy hell it got tough quick!
A little cheat: holding down the mouse will automatically build new blocks when it touches them. This works really well for the jumping-lava-gap-span-thing.
The game music is slightly more complicated than the menu music - the menu music is something like a 4 or 8 second loop or something.
Clicking on the white blocks was really difficult because the camera snaps around so much, if you added a little bit of smoothing on it, the controls would feel less frustrating.
You also started introducing new mechanics and ideas while the player is under a lot of pressure, and often after tricky sections. It's always a good idea to introduce a new concept in a safe environment so the player doesn't freak out and stop.
Overall good attempt though, it's clear you put a lot of hard work into the game!
The point of the level design, of course, was to be very tricky and creative. There are three things you can build: solid blocks, bridges, and spring-jumper-things. So, of course, the first thing I did with the introduction of bridges is make it so that a bridge had to be un-built - this was the first real little trick. Level 4 brought more of these - for example, the player has to jump over one of the pre-built springs such as not to be launched into lava.
I really did want to make the controls less of a mess, but I really didn't have a good way to - the camera tracks the player, and that's really that. I don't really know how that could be improved - suggestions would be much appreciated. :) The controls are slightly less frustrating if you use a little trick - holding down the mouse button. This means you don't have to aim *and* click, you just have to aim.
I'd suggest either making the allowed click area for the targets to be a bit bigger, or doing something to be a bit more player friendly in the early game.
I also couldn't give you a high score in the Theme. Why...?
BECAUSE THERE WAS ONLY ONE BUTTON!!!
...Either way, it's a good game, even if it's really unnecessarily hard, and I didn't let the theme screwup (Though, I must say. I didn't catch when it said "One button control," nor have I seen anything relating to that.) affect the overall score in any way. Keep it up.
Of course, I'm not really expecting to get a high score in the theme anyways. I figured that would happen once I later learned the theme was actually two button controls.
Or you can pretend that there are actually two controls - build and destroy. :P Yes, it isn't two *buttons*, but it is two controls!
...
In general, I may be updating this game in a post-compo version that improves a few things. I am incredibly NIH, and as such, I will never use a third party library for Ludum Dare, but I will definitely work on optimizing my stuff.
If I do release a new version, I will attempt to do the following things:
-Make controls easier / better
-Make difficulty controls (different speeds)
-Improve game play consistency (less lag)
-Fix small bugs (level select screen)
I'm still not sure what to do, then, to make the controls easier in terms of horizontal direction - as the player only ever loses horizontal velocity when touching a wall.
Right now, it still is very easy to do those vertical jumps if you know they are there simply by holding down the mouse button where the object will appear - the object will be automagically built as soon as the mouse touches its little box.
http://pastebin.com/YVhtZUtC
I'm still looking into the issue with the audio exception - however, it's impossible for me to know if I've fixed it or not.
If it doesn't work on your computer, can you please give me whatever information possible about why it failed? It may be due to something simple, like the wrong version of Java, or something more complicated.