About bytegrove (twitter: @bytegrove)
I’ve now added OSX and Linux ports for my entry: Astral Offset!
With Astral Offset I tried to experiment with the idea of representing the game world in an alternative minimalistic way, alongside the normal one, and also allow for some form of interaction between the two.
I also put together a small gameplay+timelapse video, enjoy:
Minimalism. Quite a tough theme in my opinion. I tried to come up with an idea that utilised it in gameplay as much as possible, instead of just applying a minimalistic graphical style. After several scrapped ideas I decided to create a game in which two worlds are visualized at the same time,one being in 3d and one being simple and minimalistic 2d, and in which objects in both worlds could travel between these worlds. I thought about making some kind of puzzle game in which the player could “construct” the 3d world from the 2d representation. But as puzzles are not my strong suit, and feeling the amount of work grow too fast, I decided to condense it down to having an enemy which could travel between the worlds and which had to be destroyed using an object which could be “sent” to the 2d world.
The way I solved it was to have the world in which the player exists to behave a little like the later Animal Crossing games, ie. the world curves abruptly near the screen and in the horizon. While the 2d world(the astral plane) behaves a little like Tetris, and when a 2d representation hits the 3d world it materializes. The player can not move to the 2d world but instead has its position in it represented by a sun-like circle. The player can then use the circle as a marker to interact with the 2d world.
I’m still fond of these ideas and concepts, but I’m not sure how wise they were for me to try to realize in 48 hours. Lots of experimenting were done and a lot of stuff were scrapped, my priorities on what to spend more time on might have been a little skewed as well. And I feel that there are still a lot of stuff missing from the final product, especially in terms of tutorials and visual feedback from actions in order to ease the player into the gameplay. I do feel however that it’s a lot more interesting than my previous entries.
If the game and the concepts seems interesting, give the game a go and tell me what you think!
(Timelapse and more ports coming soon)
Also, there are evil potatoes in the game.
This will be the third time I participate in potato.
I’ve grown quite fond of Unity so it’ll be my potato of choice this time around as well. I’ll keep Chronolapse running as usual, and I’m thinking of having a stream this time around as well.
Potatoshop or Procreate along with Blender will probably be used for graphics, and Visual Studio for code. All sounds will be recorded with a potato for best quality, of course.
I’ve compiled a timelapse video of my entry; “Primordial Soup”.
This was my second LD, and this time my idea was a little too ambitious for me, and I got stuck with a lot of frustrating bugs the first day.
However, I more or less managed to tie the features I had by the end of day 2, together.
The game might be a little finicky to play though, so I made a gameplay video as well to
showcase what features I managed to implement.
Thanks everybody for another awesome Ludum Dare!
I’m looking forward to the next one!
I knew this idea was a little too ambitious (for me at least) from day one, but I got stuck during the brainstorming and wasn’t able to come up with any other idea.
Anyway, I somehow managed to put everything together, smash at least some of the more annoying bugs and add a thin layer of polish.
The game; “Primordial Soup” is some kind of half-done-roguelike-like. Explore randomly generated dungeons, fight randomly assembled enemies, and steal their body parts and attach them to your little fish-person. O.o http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=11939
I’m going to upload a timelapse and write a post mortem in a couple of days, but now I need to sleep…
Finally starting to get somewhere though.
The player can build upon its avatar using a building block system, player input is signalled through all blocks from its root. The blocks have specified connection points, so the building system is not limited to blocks. In the screenshot below the player has two heads, both shooting bullets when space is pressed:
I’m in! LD 23 was my first try. It was really fun and it felt like I learned a lot! I managed to finish my project then and I got a lot of good feedback. However, I might just have overdone the shoehorning, and after having played a lot of really clever entries, I’ll try to focus more on making something more theme-related this time around.
I ranked fifth in the graphics category last time, and a lot lower in all the other categories. So now I know what I have to focus more on, let’s see if I can manage to do that.
I’m planning on using these tools:
Unity 3d with c#, Visual Studio 2010, Photoshop/paint.net,
Blender, inudge, bfxr, Audacity, chronolapse
This was my first Ludum Dare, and I was psyched!
I had the days before the competition more or less decided that I wanted to do a 3d-shmup. The theme “tiny world” got me thinking of giant bugs, and all the other stuff I thought up along the way. Now, in hindsight; after seeing all the clever theme interpretations of the other submitted games, I think I’ll devote more time to the brainstorming during the next compo. I had to do a little too much work with the shoehorn this time.
Now, I should warn you, this post mortem turned into a wall of text, but I’ve also made a timelapse video:
I live in Sweden so the competition started at 3.00 am. I got up at 4 and had a look at the theme, and then decided to sleep some more. After some sleep, some breakfast and some brainstorming; I finally got started at around 6:45 am.
I decided early on to try and make the game heavily component based, instead of trying to juggle around with inheritance and whatnot during this short amount of time.
So I began by making a player input handler and a movement module. The movement module for example was going to be repurposed in all moving objects, for instance. And I made sure to keep this mindset when coding the rest of the game.
I then proceeded to make aiming-, mouse input- and enemy behaviour modules. To give another example of the modularity of the project: the enemy behaviour in this case replaces the player input for telling the movement module what to do, and the enemy behaviour uses information from a sight module, instead of relying on mouse input, for targeting.
As I also had health working by now, I added a game over state, as things like end-states and score-keeping should not be saved until last. However, it was still very temporary-looking, and while I didn’t want to put it aside until last, I more or less ended up doing it anyway. Sigh.
I kept working on player-enemy interaction until around 5.00 pm, fiddling around with enemy aiming, adding camera and object shake upon hit(I made the shaking as a kind of transferable effect-module). I also began working on the triple weapons system, and the weapon switching. A module for rolling was added as well, I decided to keep it separate from the movement module.
I had this idea from the start, as I wanted to keep the game on rails; to make the player and all the enemies to follow a path along a spline, thus enabling me to easily make loopy level designs. Implementing the spline and spline traverser was not that hard, but it took me about six hours. And it would prove to be causing a little too much trouble later on, compared to how much use I actually got out of it. However, should I ever decide to make more levels it will certainly come in handy. For the next LD I’ve got to tone down on the long term planning. :]
As it was nearing midnight by now, I decided to call it a day, and went to sleep. I had gotten a lot of the mechanics in place. During day 2 I had to get all the graphics done.
Got a solid eight hours of sleep, and after some breakfast I began creating the player model; the, ahem, Tiny Gryphalope!
It took me until noon to get the mesh done. Although it was fun and a nice change from all the programming from day 1, I still feel like I could’ve put that time to better use. During the next compo I’ll try to make simpler character designs, with less feet.
Screenshots, in chronological order, of the making of the main character.
After I had the model, I began looking into keeping player and monsters from getting to far off the path. This was one of the biggest mess-ups in my opinion, one of the things which I spent far too much time on. I began by trying to make the constraint purely distance based, but I never managed to get it to work smooth enough, so after two hours of failure, and feeling pretty stressed out, I decided to put it aside for a while and start making an enemy model and calm myself down.
I decided not to spend as much time on modeling the enemy as I had spent on the main character. As I previously stated the theme got me thinking of giant flies (for some reason), so I decided to make a fly-like monster. I made it a very simple model, without any legs and a loosely defined, pudgy “face”, based on a quick and dirty sculpt. It took me about two hours to make the model from scratch and UV-map it. An improvement, but oh had it felt good had I only spent one hour instead. xD
After that I went back to battling the problem of making the level constraints. I decided to switch to using only mesh collision as it is already provided by Unity. However, since I had made my movement code completely separate and not based on Unity’s physics engine, I got a lot of twitching and shaking when implementing collision. I had to go back to the collision handling several times for small fixes and fine tuning during the rest of the development time, and I never got it just right before the deadline, sometimes it freaks out. *I think* I fixed it in the post-compo update, but to be more certain I would have to make movement physics based.
I long for the day when I no longer will have any problems whatsoever when implementing collision handling. Ha ha.
I then decided to get the textures for the Gryphalope and the fly-monster done. As I had grown quite weary of wrestling with ill-behaving code, it was a nice change to just draw for a while. I found a really good reference picture on Wikipedia for drawing the wings.
Yay, colours! =D
I now had 7 hours to go, and so much left to do.
I decided I had to start making something that could pass as a level, instead of the randomly placed boxes. The level ended up of consisting of only one mesh, duplicated, rotated and scaled in different ways. I began by making a tube in Blender, subdivided it like crazy and began sculpting tree-like grooves and roots into it.
After one and a half hour of sculpting and painting, I had this:
I then began making some sound effects for the game, using Bfxr. I also started the long overdue task of completing the game over- and victory-states. To sweeten the menus I implemented my own button system, so I could easily animate them and make them compatible with gamepad thumbsticks. I wanted to make the game totally playable using only a gamepad.
When making these end-states I got the idea to present all the monsters the player had killed, by lining thumbnails of them up, kind of like how it is presented in Spelunky between levels. I figured that this could then be expanded into showing some kind of score based on kills and loot. I never got the time to implement more than the line of thumbnails though.
With game over- and victory-screens done, the big crunch began.
During the last three hours I made a title screen, particle effects, rigged and animated the main character, “designed” a level, created music (thanks, inudge), playtested, squashed some minor bugs, and uploaded.
I was pretty happy with the end result, it being my first Ludum Dare, and all. The game ended up with pretty nice looking visuals but suffered from a lack of gameplay. It was great to get such a large amount of good feedback from the community, and it helped and spurred me to make and release an updated version.
What went right
- Going for a component based architecture.
- Getting all the core mechanics done by day 1.
- Reusing the same mesh for the whole level.
- Getting the spline system done pretty quickly.
- Actually managing to make some simple music(first time I made my own music).
- Having some friends over during the compo, kept me sane.
- Right amount of food and sleep. ^^
- Managed to make something playable. Next time: something enjoyable.
What went wrong
- Spent too much time making the main character.
- Spent even more time wrestling with collision handling. >.<
- Ended up not really needing the splines for the simple level that I made. (May come in handy later on though)
- Got some performance issues in the game on some computers.
- Realised after the deadline just how dark the game actually turned out, and how sluggish the movement was.
- Never got the time to make a pretty HUD.
- The project might have been a little too ambitious for being my first LD, it was hard to predict what to prioritise in only 48 hours.
- I should’ve brainstomed some more to make something a little more connected to the theme, and more innovative.
You can visit the entry page here, and play/rate the compo version. Web and download available.
Updated post-compo version
Click here to play the updated version if you’ve rated the original.
All in all, the compo was a great experience and I felt that I learned a lot, and as usual; still so much to learn. =D I’m really looking forward to the next compo!
And this concludes my post mortem, kudos to you if you read it all!
If you still got some energy left, and if I managed to pique your interest, please give the game a go, and I’m very thankful for all feedback and constructive criticism. If there’s enough interest I’ll probably keep working on it.
Thank you for your time.
This was my first time participating in Ludum Dare, and it was an awesome and fun experience. I wasn’t aware of that I was able to get so much work done in that short amount of time!
And here’s the timelapse: