Nice little rogue like.
So I'm not the only one that made a round based game :)
I like the turning mechanic (that you need an action to change the direction you are facing).
Very simple, but also very fun - at least for a while.
My only complaint would be, that it seems to be a bit random - but then again that is the nature of such games.
I would put it into a category with flappy bird :)
Overall: Nice job!
I liked it. But.. is there an end?
I play medium, I have the screen full with towwers and over 2k of each resource.
No more place to build and no upgrade options.
So it would also be nice to be able to:
- upgrade the towers
- use 3 differnt keys (keyboard) to build towers (so you don't have to mouse around so much)
- have the enemies grow stronnger faster - I'll now just wait if i will die at some point :)
Wave 83 right now.
I have made a making-of timelapse for my game (it does have voice over comments):
It shows most of my development (except when I forgot to turn the tool on ;) )
It consists of 4572 screenshots - one was taken each minute.
So that means it took me about 76 hours to make this game.
Hey, your game saved me.
I just wanted to say thanks! :)
You maybe wonder why:
My game wouldn't take any keyboard input on itch.io .. but I remembered that I played yours, and that it worked.
So I went and had a look at your index.html - and found the stuff needed to get it going.
I also posted the solution here: https://github.com/leafo/itch.io/issues/58#issueco...
Because that's what google came up with (but they didn't have a solution).
Thanks again, have a very nice day! :)
I already had the first version posted to itch.io...
... when my wife suggested we do the audio recordings for the "mission command" radio texts.
I had already scrapped the code (but that was back pretty quick, thanks to git) and we did it.
She recorded the messages, I removed the noise (cheap mic headset) and edited the sound a little. Then I cut it all up and converted to oggs.. and now there is voice acting in the game!
Give it a try here:
PS: I had a hickup (took me 5 uplaods to itch.io to figure it out) that the game wouldn't take any keyboard input when embedded on itch. The solution (I got it from the index.html of sanoke's jam entry) was to put window.focus(); in the index.html within the handleMouseDown function.
I optimized my menu buttons.
Before I was using modified default skin buttons - but they only have a 1 pixel border.
When downscaling the menu, the border was sometimes lost. It didn't look good.
I have now made my own 9patch buttons, that are packed via texture packer and loaded via the skin.
Still not perfect when downscaled, but they work better :)
All my levels are done.
Tomorrow I will write the last mission control texts and then it's done.
I plan to publish to itch.io tomorrow night and then have a nice and chill weekend.
(Maybe some bug fixing, but it looks good so far.)
Here are all 6 levels:
The last one should be taken as a thank you nod to the great lib we are given :)
Also: the last one has no health packs, it's you or them, no healing :)
Let's see if anybody can make it there and back again.
I had a friend playtest the first level.
Based on his observations I changed some stuff, mainly no longer can you can uneven amounts of action points. - Because that would mean you have to walk 1 tile each round, or end the round by clicking on yourself. (because shots cost 2 points.) - So now every upgrade to AP is 2 points at once.
Also some smaller stuff was found, like dead enemies were hiding upgrades under their bodies (now the upgrades are rendered over dead enemies).
And to better show the goal of each level, I added a teleporter device that you have to get to.
Other than that I finished level 2 monsters, started level 3 .. I still plan to release 6 levels.
Lot's of playtesting involved to find the right enemy strengh - for that I added a mode where you walk much much faster :)
Here is another level editor screenshot - with the teleporter level end point.
Just had a two hour bug/problem hunt.
The gwt version (html5) wouldn't run anymore.
The problem was the Json I am using for the game texts. (If I had just used simple string constants...)
<extend-configuration-property name="gdx.reflect.include" value="net.jppresents.space.TextResources" /> <extend-configuration-property name="gdx.reflect.include" value="com.badlogic.gdx.utils.Queue" /
This had to go into the SpaceMain.gwt.xml.
The first one for my json class (this class is filled via reflection when loading the json file). The second one.. no clue why, but ArrayLists can't be deserialized otherwise.
Wow, man I am happy it's up and running again.
After taking a break yesterday today I started building some levels.
The first level is pretty much done - you go around, shoot aliens, get two Action-Point Upgrades (you start with two action points and end the level with four).
For level two to five I did the layout in tiled, but haven't placed enemies yet.
I'll try to get feedback on level one.. too hard? too easy?
And then design the finish the rest of the levels.
I am still thinking about putting in some voice acting - but I am not sure that will make the final cut.
Other then that I only plan on finishing up the levels and do some play testing. - No more new features from now on.
You can skip the checking for level and then setting it, if it's not available. Instead you can (where you access it) give a default value, if it's not in the prefs:
I know it just saves two lines - but the more values you save, the easier it makes your life :)
A quick last update for today:
I have finished implementing shooting enemies (both stationary and moving).
For the stationary ones I had to design a new graphic - so here we go, the turret:
Implementing it wasn't too hard, since all the mechanics were already in place (line of sight, shoots flying and hitting) but it still took some doing.
Good start into the sunday.
Last night in bed before falling asleep I came to the conclusion, that levels without doors & keys are too boring.
So today I made them, the doors & keys I mean (and sounds. and event trigger and user interface display of key cards).
Since we are in space (well on mars) it's key cards instead of old fashioned keys:
Today went quite well.
The game is now at the point, where the list of my mission until the end of the jam is quite short:
a) creating levels (I have the first one, I plan on delivering 5 - 6)
b) fixing bugs
c) possible audio recordings for radio content
Today I finished the menu and some important game events.
The menu now shows all available level (currently three.. but that's just a test, the menu is growing whenever a new level is introduced - up to 12 fit perfectly.)
The game safes when you complete a level, so you can come back later and not lose all your progress.
New stuff in the game from today:
level transitions trigger - you teleport from one map to the next
text box trigger - a textbox with a certain text form the gamedata.json is displayed
win trigger - the game ending screen is displayed
all three can be placed and configured in tiled (as big objects, the area they cover is the trigger area).
I also made the player and the enemies completly configureable via tiled. For enemies this means ap, hp, dmg and looks.
The last thing I did today is an optional audio system for the text boxes.
I am not sure there will be audio.. but if it comes to it, the system to play it is in place.
Breathing some life (pun intended...) into the menu.
I found this youtube tutorial for libgdx menus and it pointed me to exactly what I needed:
... and the stage fades out.
One line is all it takes. And there is more, have a quick look as I show off the menu here:
What took the most time was to find a tutorial on how to do a planet and stars - and then actually doing them.
The planet is actually inkscaped (I didn't even know about the filter menu for noise..) and the stars are hsv noise from gimp with some manual edits.
If you need infos on how to hack together a main Menu, have a look at https://github.com/jpcloud/lifeInSpace/blob/master...
But to be clear: This is hacked together learning as I go, so there is no real structure. But hey, only 9 days left, what can you do. Gotta get things done!
Today I added a main menu (my first time using libgdx ui elements like stage, table & buttons).
It worked out okay - but it's boring. I will need some background.. at least the music is playing.
I also added json loading of texts (this was super easy, libgdx json support is awesome) - 2 lines to load from json into a custom class.
This is used for credits & help screens right now - but I plan to use it for dialog/story in the game too.
I also experimented a bit more with android - i tweeked the scrolling for different resolutions, added support for the back-button (also for ESC on desktop).
And that's it.
Overall this took all evening.
So regarding the plans:
1) didn't change it.. for now it will stay this way, maybe later (if I get a better Idea than just to copy the heal animation)
2) it's in - it's the same way shots work, so if you can shoot it, it can see you
3) I am leaving this out.. if you can see it (including scrolling) you can try to shoot it - I don't think I can manage a good range indicator and stuff like this until the deadline.
4) I made 6 unique weapon upgrades, for now they all increase damage by one, that might change later
Here they are in a very short video:
5) haven't balanced aliens yet to match player power (with all the available upgrades)
Unplanned progress: Andreas reworked the background music, it's now even cooler than before.
Today (and last night) I had problems with the tilemap.
I hope they are now resolved. - One of the issue was, that all tiles where of by 2px due to fiddeling around with the packer options and not adjusting the tiled ".tmx" file.
This wasn't visible immediately because I had bleed enabled, so those 2 pixel had the correct colors - but when changing the resolution sometimes there were weird tilemap artifacts. Now the tmx file and the texture packer settings should be matching.
Tip: If you package your tileset with texture packer (you should!) always set "grid" to true - this way if you add new tiles (number them with leading zeros) new tiles always go to the end of the list. Why is this important? So you don't have to redo your tiled tmx map everytime! (If you don't use grid mode every new tile will mix the indices of the old ones.)
Tip2 (I noticed I still had rendering problems):
Settings for texture packer:
paddingX: 4, paddingY: 4, bleed: true, edgePadding: true, duplicatePadding: true,
Settings for the tile set in tiled:
My problem was, I had margin in tiled set to 4.
Since all the the tiles are padded you don't really notice that all centers are off by 2 pixel (at least with my 64x64 tiles). It only led to rendering errors when zooming out. I hope that's gone now.
Today was pickups / upgrades:
The first pickup is a medkit, it heals the player and is not picked up if the player is at full health.
The next too are permanent upgrades (one max hp, one max ap).
The last one is a weapon upgrade (this switches the weapon graphic for all player animations & increases damage right now).
Plans for tomorrow:
1) change the upgrade animations to be multiple small arrows (kind of like the heal animation) - that looks cooler.
2) Implement line of sight aggro, aliens that engage in combat through walls aren't fun (it interrupts the free movement.. and then they never reach the player)
3) weapon range (right now range is about 1 and a half screens) + indicator (and inability to shoot) if something is out of range
4) weapon upgrades -> damage, range (I am thinking base damage = 3, base range = 4 - and then the upgrade will increase by 1) - I want a unique weapon for each level.. (maybe via colors, let's see)
5) aliens have to be balanced to the new weapon levels (and AP / HP upgrades)
The idea sounds cool, I liked cookie clicker (for one afternoon of mindless clicking :) )
The gifs so far look extremly technical/abstract. (I guess you started with the stuff I am trying to avoid :) - I have a mostly finished game, but still no menu of any sort.)
So (of course) I didn't actually develop the stuff on the list from the last post.
Well, I did do the health pickups (and they paved the road for further pickups).
Instead I did these things:
Muzzle flashes, they were needed because if the enemy is right next to you you never see the projectile fly.
This way there is visual feedback for the attack in all cases.
The muzzle flash is part of the shooting animation (in spriter). The interesting part was to make it fit with the big gun and the small gun.
The gun change is done via character maps (where you can replace one of the animation's sprites with another picture).
Since the size of the guns isn't the same the muzzle flash wasn't appearing at the correct position.
Solution: Also switch the picture for the muzzle flash when switching the gun picture. (Both muzzle flashes are the same size picture, but in one there is lot's of space left to the flash, in the other to the right - this changes the position in the animation to fit the gun size.)
Another thing I experimented with is ninePatch in libgdx.
For this message box:
The background of the box including the round edges is a ninePatch image. This way there is no blurring even when resizing it.
(And it is resized in this picture, because no one wants such a big box in their spritesheet.)
Notice how the edges are the same and only the repeatable part gets stretched out.
And this requires you to quickly mark the strechable parts with the android's sdk 9patch editor - and exactly one line of code with libgdx:
ninePatch = textureAtlas.createPatch(name)
So then.. maybe I do the weapon pickups tomorrow :)
The last two days have been quite productive again (and they needed to be, because I have to go to work again starting tomorrow).
I have another short video dev log for you:
I show off the round based combat complete with attack animations and different action point costs.
The user interface is also improved, it previews how much action points a shot will cost and it shows numbers for health and action points.
This is done via libgdx BitmapFont (you can easily create a bitmap font from any font on your system using Hiero. There is also the option to use freeType which creates the fonts on the fly, but as @nathantolbert discovered, this does not work if your game is compiled to html. That's the reason I stuck to a normal bitmap font.
Some plans for the next update:
- health pickups (easy)
- weapon pickups (moderately difficult, I want to modify action point cost, laser color, damage and weapon design)
- suit improvement pickups (moderately easy, I want to give the player more max health points and more max action points)
If there is time I would like to implement a story - most likely you get radio messages (with voice acting? - #libgdx say they would prefer orders from a female voice - we'll see.)
Thanks for the input!
Both has actually just been implemented today :)
Depending on level the enemies now not only have different hp & looks, but also varying amounts of action points.
If you target an enemy, you can now see the health percentage. I am not sure if I will show actual values later.
On my list for today are also: an indicator how much of your action points a move / shot will cost and health & weapon pickups.
"9" and "4" look nearly the same in the editor
JOHNCENA is too loud (it's so loud that there are artifacts)
when closing the editor the symbol (red x) indicates that you would lose all changes (but it is indeed the "safe" / "done" button) that is a little counter intuitive.
That's always a problem for me too - I mean finishing a game.
But that's why I join game jams .. they do motivate me (and should motivate you too) to really finish a game within the timeframe.
So come on, it's 16 more days till the deadline - you can do it :)
Okay, so today I managed to do:
- a few variations on alien body parts (2 new heads, a new leg) so that not all aliens look the same
- aliens now attack the player
- the player can now die (with animation) - but the game is stuck on death (no restart yet)
- aliens have levels (for now they determine damage, hp and visuals)
- the game map can be changed (but there is no trigger for it yet)
- the html:dist works!
And this means, you can check out what I have here: http://jppresents.net/static/temp/space/
If you try it, keep in mind: This is not a well designed level, it's just five aliens from lvl 1 to lvl 5 .. so you will die (because you are only lvl 1), if you die, only reloading the browser page (f5) will restart the game.
You control everything with the mouse.
Any feedback is of course welcome!
I have checked the java documentation, and it just says it's to avoid conflicts with class names.
Quote: "Package names are written in all lower case to avoid conflict with the names of classes or interfaces.")So as long as you don't have classes named the same as your packages you are fine!
I am going the same route as you - first getting my game working in a premade level and after that (maybe) random generated levels.
I think that is very important, because if time runs out we have something playable.. and not a great level generator with no gameplay ;)
Just had a little (2 hours wasted) hickup.
I noticed that I managed to use capitalization in my package name "net.jppresents.lifeInSpace" .. package names should of course be all lowercase.
So quick fix, IntelliJ refactor "lifeInSpace" -> "lifeinspace" .. and that's when things went wrong.
Root cause of all the problems: windows
Windows does not care about case in filenames / directory names. It does save it, when you create a file/dir.. but when changing it, things go weird.
The refactor changes the case in all files that reference the package, but can't (due to windows) actually change the directory names. This (with some unexplained gradle behavior) killed the main class from my desktop build.gradle and made commiting the name change to git impossible.
easy fix: Refactor to a different package name, I choose "net.jppresents.space" and fix the build.gradle.
But getting to that fix took some swearing and complaining.
Today was all about combat, action points and a bit of user interface.
The only thing missing for complete combat is that the monsters attack (they already follow the player around, but they don't bite yet).
When that is done I'll make another video.
I made some more progress today.
Mainly pathfinding and the beginnings of a ui (indicator what your action will be, walking, not walking, targeting).
Also player and monster positions are now read from the tiled map file.
I made a quick youtube video to show the current state:
Okay, after the family visit over Christmas I got back to the game.
I continued working on the tech, there is now a light system (thanks to @orangepascal and his tutorial http://techblog.orangepixel.net/2015/07/shine-a-light-on-it/).
I made tiles (which I don't like, but they have to work for now) and managed to load the tiled map into the game.
After animation, light and map were up and running (as a big chaos in the main class) I have begun moving stuff into classes. (Right now the light class is done).
Here is what this looks like in the game (scaled down 2:1):
Did the library setup for my game today..
.. I packaged the spriter runtime ( https://github.com/Trixt0r/spriter ) into a jar, to include it.
And I set up texture packer to get nice atlas files for my animations.
Both things took really long.. but they are done.
So maybe I can actually start to code tomorrow!