the31

LD16

MiniLD16 First Day: Combo Trader

I started late, last night at 7pm, and I’m going to work until 7pm Saturday.  So now I’ve had just over 15 hours of possible work time. Of course, I’ve used very little of that–how much I’m not sure.

I have done something at least. My goals will have to be a little scaled back, but I do have a working framework for the majority of the action part of gameplay.

Before I go into what I want this game to be, here’s a link to the current version and a screenshot.

TradeBuilder screenshot 1

The screenshot doesn’t do a great job of describing it. The goal (for now) is to go as fast as you can. You can do this by combining two “fuel” boxes and one “oxygen” box (yes, that’s what they’re supposed to be). If your bar is full of oxygen, you get a big speed boost and it’s all randomized. Any order can be used in the fuel-oxygen combination, but if you combine anything other than 2 fuel and one oxygen, your speed decreases. Your ship also decelerates over time. And for now you can ignore the “you’re going to fast” message, because I haven’t implemented damage yet. There will be enemies and weapon combinations eventually, as I put in damage.

Eventually I’m going to make the game live up to the “trade” in the name by making this sort of arcade side-scroller take place between planets, between which you carry cargo.

And as for the rules, I’m sort of breaking the palette one. As you can see in the screenshot, when moving fast the background gets blurred. I just put this in to make tearing less noticeable, but maybe I’ll remove it later with different backgrounds for different general speed categories.

Oh, and don’t bother trying to win, all that happens is that “You won! Congratulations!” appears in the text box in the lower left and the distance remaining goes negative.

Hope the game will turn out to enjoyable.

Comments

27. Feb 2010 · 17:27 UTC
Looks like a really cool idea. It took me a while to get used to the controls and figure out what I was supposed to do, but it’s an interesting mechanic for speeding up, and the art looks pretty cool.

LD17

Finished my game!

My first and last post for this LD48 happens to be about my game’s completion! Go on over here to see the submission page and play it.

Before the weekend, I didn’t think I’d have the time for it. But I suddenly had an idea, and after a friendly reminder from Phil Hassey on IRC that it’s never to late to enter, I decided I’d do what I could. So, after a few struggles with mouse picking and getting the y position on a terrain grid, I gave up on both and moved on to make a game that, while using a semi-awkward control scheme and an inaccurate terrain-tracking pointer, is complete now.

It was originally going to be themed on the Iceland guy, with his face on top, responding to how fast you’re clearing the levels. What are now forks were originally supposed to be fists, but I couldn’t figure out how to texture them that way. So now it’s themed on exquisite dining rather than a Iceland-pounding rage.

I had fun, no matter the result, and that’s what counts, right?

LD19

LD19: Perfect Timing!

At my school, finals week is the 13th through the 16th. The LD starts the 17th. This time I have no excuse to miss it: I have no homework, my schedule’s clear–and I can’t even study (normally always possible).

Even if the theme is something I really, really hate, I’m going to participate. This is going to be a great weekend.

As a side note, I’m semi-planning on doing this with an entity system. This really depends on the game I decide to make.

Looking at the world map, I think it’s pretty obvious I won’t be able to meet with anyone. But I will take this space to say that the map should be made bigger! WAY bigger, if possible. Maybe just a resizable popup?

MiniLD 23

It’s done! After working on it at an airport, on a plane, and finally at a hotel, I’m posting my game. At first I didn’t think I would have time this weekend to do the MiniLD, but it turns out I had more than enough even while travelling.

(I probably was only able to finish this game because it was incredibly simple, but still.)

C0A57ED

Read it upside down calculator style. Except right side up.

You can go here to play 0xC0A57ED on Kongregate.

(Rule-following is as follows:
Year as title: it’s set in year 0xC0A57ED, so far in the future that we use hexadecimal for years.
Spring physics: the movement and connection between you and the squares seems like a spring, even though it isn’t really. Let’s just say they are year 0xC0A57ED hyper-springs.)

LD20

My idea and a script

I got home from go-karting with my family to see the theme. Didn’t have any ideas beforehand for “It’s dangerous to go alone, take this!” but I think I have one now.

First thing I did was lose my script for creating AS3 files for all the png files, mp3 files, etc. in a directory. Second thing I did was rewrite it in Python (as opposed to the Ruby original). So… that was fun.

As for my idea, what’s important are the items the player is given.Things to take.

Take These

Of course, those gloves aren’t ordinary. The rocks aren’t either. Net’s strange too. It’ll become clear in time.

Finished! Well, finished enough.

I started by focusing on the “it’s dangerous to go alone” part of the theme. I thought it would be easier to make a game where you have to make a group than one about taking things. So, I did that. I decided to essentially make a pokemon clone, except more evil.

Then, with a little bit of trying-too-hard-to-be-serious storyline (Phantom Keeper? What?), I put in the “take this” part both ways.

This was a very difficult project to take in 48 hours, because the genre is basically fueled by content and I hadn’t made a game like it before.

In the beginning, I doubted I could finish the game. 48 hours (and 48,000 terrible hacks) later, I find that I was correct to doubt it. I barely got a lot of the core features packed in there, and the game is terribly unbalanced. If I ever find an artist who would want to do a game like this in the future I’ll think about it, but I think Phantom Keeper is done until then.

It was a fun LD, but I’ll be scaling back to a simpler game for the next minild.

Finally, a link to the “finished” game.

MiniLD 26: Minerbot 2

Instead of taking the normal route of making a whole new, original game for this minild, I’m going to make the sequel to Minerbot.

Of course, I’ll be using AS3.

(A) Name of the game: Minerbot 2 (for now)

(B) Description (140 chars): Your job as an employee of AMEC is to mine asteroids. Use tools of the trade to get the job done quickly and after a little profit, upgrade.

(C) Mockup image: Well, I kind of did three, but it’s all in one image. This outlines the basic flow of the game.
The basic flow of Minerbot 2

(D) Definition of Done:

  • Player ship able to move through the asteroid world.
  • Collectors can be shot, and attach to walls.
  • Collectors send beams through ore pockets, mining them. (Just like Minerbot’s collectors did it.)
  • Collectors have to recharge, and have a maximum capacity.
  • Upgrades have effects on their respective stats.
  • Ore and gems are generated randomly, and when collected add to the commission received.
  • The flow works as shown, with the exception of contracts.
  • There is a way to end the “mining round” to upgrade and select new contracts (if possible).
  • Configurable controls for those with weird keyboards.

There’s more to do to make it a complete game, but if I get those things done by the end of the MiniLD I’ll be happy. Notably missing is anything about contracts–they would take a while to implement and give variety to. Also, the big red bar in the lower-left of the gameplay screen is unused, although it would be for health.

Hopefully my extensive mockup will help me get through the art more quickly. :D

MiniLD #27: A Little Demo

Well, over the past few weeks I’ve worked a little on an engine to use for this mini ld. There are still bugs, but I made a little example program with the thing to hopefully help motivate you to enter the mini ld.

Without further ado, here it is, a little sample of what my engine can do.

EDIT: Here’s an updated version!

Hope you enjoy it!

(I’m the31 in IRC, by the way.)

LD22

Final Round of Theme Voting

I was curious which theme would win based on the total votes they got in the previous rounds. So I put them in a google doc, sorted them, and guess which came out on top…

KITTENS!

Wait a sec… the numbers… oh. I had it sorted in ascending order.

Unfortunately, it appears that random generation wins based on previous votes, but I hope this prediction turns out to be false.

I like making games that use random generation, but that’s exactly the point. My games already always have random generation, so this theme does nothing for me. If this theme wins, it’ll be a boring contest for me. Secondly, I bet that artists wouldn’t like it much, because random generation is something that you have to code/logicize/whatever. Although I’m sure a few things could be done with art style for random generation, it doesn’t really seem fair in that regard. There is a third reason that essentially disqualifies it, but I won’t mention that, because it’s kind of too late.

I got a message about this from a friend, in fact… maybe it will convince you.

“There are consequences for this evolution of theme voting… alone will randomly generated be the antihero of decay, for only in a parallel universe, in some forgotten place, will the mechanism of my dreams shape-shift into the territory where, upon reflection, the self-replicating fall towards a theme travels in time with me, to the tunnel of the conscious world. Then… then the teleporting moon-kittens strike, their underground movement taking force.”

He has a thing for bolding words. He’s weird.

Survival Log #348

today i found an abandoned apartment complex. thick doors, locks to hard to pick. not problem, likely no food in rooms anyway

lobby had stuff, though:

  • 7x water bottle
  • 2x polaroid camera (wtf?)
  • 5x fritos chili cheese [-1, breakfast]
  • 4x potato chips
  • 2x snickers
  • more ruined in vending machine
  • wrench
  • !!!screwdriver set!!!

no enemy presence found. maybe in the rooms, but I listened at all the doors and didn’t hear anything. not worth the noise to bash them in either, since i can’t pick the lock

getting cold, got to find a place with windows left. don’t want to have to return to house G. don’t want those memories

a bag of fritos

ate this for breakfast. note to self: get a better camera

i feel so alone

LD22: A dual-project dare

This LD (like LD20) I decided to make an adventure sort of game. Not an arcade game like I usually make, but something that involves a big space to move around in.

Needless to say, I failed both times. The first time because I tried to write an efficient tile map renderer from scratch, and the second because I got caught up in making my chunked, randomly-generated map work while avoiding floating-point inaccuracies.

Randomly-generated House

A randomly-generated house. I spent way too long on this.

So, after a particularly nasty bug involving the doors and still not having collision, I decided to scrap that project about 6 hours before the deadline and make a different one.

This new project, Asteroids: Alone Edition is what happens when you take the theme too literally and apply it to an old game. Simply put, it’s asteroids minus the asteroids. Well, except the main menu, where the AI plays.

I finished it up in about four or five hours, and submitted early.
…Success?

(Most of that time was spent tweaking the AI. Make sure not to ignore it when you play my game!)


Play my entry, Asteroids: Alone Edition.

Or play the original, unfinished project, Return to Solitude (Controls: WASD, hold shift to run.)

MiniLD 33 “Doodle”, Minerbot 2

It’s spring break, so I’m in! The fact that it’s spring break will probably interfere with my work, but it’s worth a shot.

I started my doodle not really remembering what a doodle is, and made a mockup. I realized that it wasn’t a doodle about halfway through, but thought it might be a better use of time just to keep going.

My minild doodle--well, mockup sketch.

Behold, a sketch of some basics for codename Minerbot 2.

LD23

LD 23? Hopefully.

I’m in. Although I may be out at a moment’s notice. Hopefully not. I don’t have major plans for this weekend, but I’m still in college so anything could pop up.

I’ll probably be using AS3 with Flashdevelop and my personal library of random junk. I might decide to use C++ (with SFML) if it’s more suitable to my idea, or even go the other way and use HTML5 + JS.

Can’t wait to see which theme wins!

LD24

LD24: A tale of catastrophe and woe.

To get this settled right off the bat: this LD was great fun, regardless of my troubles. I’m happy to say that I finished the (very much incomplete) game Beyond Our Sacred Sun.

The Beginning

I begin this chronicle with my initial plans. Shortly before the LD, I heard about Google App Engine. I had done a little javascript, css, python… so I thought I’d use it for the LD.

I did some coding, and frankly was amazed at the functionality GAE provided. I had to do some tinkering to set up a Lubuntu VM as a development server (I’m bad at configuring dependencies in Windows), but after that, I was able to continue on a decent pace for a while.

Showstopper

At about 36 hours in (and countless showstopping bugs) I had a decent framework to make my game in. Stars moved in a stellar map, and were synchronized by the server automatically. An event system was apparently functional. “12 hours left–I’ll have to cut down on features, but at least I’ll probably have some gameplay by then! With multiplayer in a persistent world, no less!” Of course, things soon tanked.

ld24 Game, at its highest point

My game, at its peak of development.

At around 36 hours, I hit my first solid, unbudging handicap. I exceeded a GAE server quota: database reads. My code wasn’t efficient (not surprising, it being my first web application) and I had committed some unmentionable sins during solar map generation. If the google servers couldn’t handle development debugging, there was no way they could handle LD traffic.

“…there can be no true despair without hope.”

At the realization that I couldn’t use GAE for my LD game, I frantically scoured the internet for another way to host it. When I found AppScale, I breathed a sigh of relief. But then I saw the downloads page. “Torrents? Well… ok, I guess.” I started it up, and to my dismay found that there weren’t any seeders–only 16 penniless peers. After more searching, I found something promising: a blog post from Wolfire on AppScale. Unfortunately that post was 3 years old.

My development process’ new theme: Abandoned

With that discovery, I took up another of the suggested LD themes and abandoned my project. With only 4 hours left, I decided to replicate some of the basic ideas of my game and make Beyond Our Sacred Sun.

And that, my friends, is how I ended up with a stripped-down Galcon clone.

LD25

LD25: A delayed retrospective

For LD25, I tried using Unity for the first time. Well, that’s not quite true–I had tried using it a few times before, but never got anything done. As a programmer, the seemingly content-oriented interface threw me off, so before LD25 I read a lot of documentation to ensure I knew what Unity is all about.

Where's the code?

Where’s the code?

So, what did I learn about Unity while making my game, Entropic? Quite a bit, but in summary: Unity is awesome, it handles its component engine well, and I look forward to using it again in the future.

I made a few odd design choices near the beginning that I’d like to share, since the rest of the LD was the usual “started off well, hit a major issue in the middle, almost jumped ship, but came around in the end and finished it off.”

Entropic is, at its roots, a space sim, and in science fiction space ships tend to have gravity independent of ship acceleration. If a starship starts spinning, actors typically just stumble around a bit.

How is this accomplished in a constrained physics engine like Unity’s while retaining physics-powered movement both inside and outside the ship? One way would be to have multiple physics worlds (aka spaces), one simulating the exterior and the other the interior–but Unity only allows one world to exist. The next best thing are physics layers, which can be configured to only allow interaction between objects in the ship and objects outside the ship. Simple enough, and Unity makes this easy to configure.

I then (too eagerly, in hindsight) decided to add scale into the problem. Ships move at much greater speeds and have much larger sizes than humans within a ship, so I thought it would be a good idea to scale down the “space” world to account for potential accuracy issues. Easy enough, especially in Unity–just turn down the scale on all the “ship exterior” and “asteroid” meshes, and it’s done.

It does look really weird, though. (I hid some of the ship bridge's walls to get this screenshot of both layers combined.)

It does look really weird, though. (I hid some of the ship bridge’s walls to get this screenshot of both layers combined.)

One problem that I had early on is that there was very little visibility on the bridge. On the Enterprise, that little screen was enough because they could tell is to look at anything around the ship–with an equally-sized window on a ship, it’s surprisingly hard to tell what’s going on.

High visibility. The player can actually see “out” of the bridge at almost any direction.

To make the field of view much higher, I decided to apply an idea I had been holding onto for a while. By playing with the depth buffer a bit, I made some surfaces that hide the parts of the ship behind it. This dramatically improves visibility, and is also cool since it creates the effect of having an “impossible geometry.” (My explanation is that the ship is covered with tiny cameras that capture the state of the ship’s exterior, then display on interior screen-panels what the system extrapolates you would see from that point.)

It's bigger on the inside.

It’s bigger on the inside.

With some more advanced ship designs, I think that could get really cool, really quick. (Battle bridge, anyone?)

One thing that made this effect much weaker is the cloudy effect I had to use to represent the volume of the ship. They look somewhat like stars, and it is a little weird that they form a box around the ship. This is meant to represent the volume of your craft, since you don’t have any other reference with the fancy windows active. Need to find a few artists for the next time I do something like this, so it doesn’t confuse.

Overall, I’m happy with how it turned out, although as a game the project was sorely lacking. For the next LD I’ll avoid ideas that need fancy but non-value-adding programming. I hope. It’s hard to resist a challenge.

LD31

Orb Fetch: GOLD, behind the scenes (LD31 Compo)

For this LD I made Orb Fetch: GOLD, a game that looks like a newtonian “thrust one way, ship goes the other” game, but isn’t. At all. And it’s hard to get used to how much it isn’t. (I still end up trying to “thrust” in panic on the more dangerous levels.)

2014-12-07_20-04-27

Here’s a peek at how I made the graphics: a trick I’ve been wanting to try with grid paper, a pencil, and a felt-tipped marker. Black and white filters easily get rid of the blue lines, leaving the lines to be filled (or not).

Usually graphics aren’t my strong suit, but I think it worked well! It was very easy to get some graphics that weren’t my usual lame programmer’s pixel art, and because it wasn’t pixel art, it wasn’t a pain to scale up for fullscreen mode.

Only downside is that now I have to apologize for my poor handwriting.