JJ Treadway - OneGameAMonth
-
October Submission - Perpetual Motion
Addictive little game where you fly around constantly (hence the title - stopping is the hard part) and battle enemies with your lock-on lightning gun to collect coins and upgrade your ship.
Next S-NET coming next month, and hopefully ending this fun year with the final Steel Warlord.
0 Comments -
September Submission - Steel Warlord (version 2)
New version of Steel Warlord - unfortunately still not completely finished. More enemies and weapons, switches, and bigger/prettier world map. Final version will contain even bigger/prettier world map, flying enemies, more music, and the boss fight I promised before.
Also, you can download the world editor here (just put it in the same directory as the main “steel warlord.jar” file).
0 Comments -
August Submission - S-NET (version 2)
Welp, it finally happened. An improved version of a game from an earlier month. And hopefully an even more improved version will be coming in a later month, after I do the improved Steel Warlord. New features in this version include enemies, weapons, powerups, and one-way platforms.
0 Comments -
July Submission - Steel Warlord
(It recently occurred to me that most people would probably rather just download the game than read my poorly written blurbs, so from now on I’m putting the download links at the top of my posts)
Steel Warlord is a point-and-click shooter that I made in accordance with the July theme of “metal”, by setting it in a metal facility filled with metal robots, and by adding as much audiovisual badassery as possible. Aaaaand, it looks like I’m pulling the old “I’ll give a better version in a later month” again, though this time I’m pretty sure I’ll actually do it, because a) this and S-NET are by far my most promising in-progress games, and b) I have an epic final boss fight planned which I’d hate to not actually get around to implementing. In keeping with that spirit, I’m refraining from cashing in on the metal theme achievement points until the month I release the final version (most likely September).
0 Comments -
June submission - S-NET
The game that I briefly mentioned falling through the cracks last month has pulled itself back up through said cracks, and can now be presented by us (that is to say, by me and my buddy Mac). In its current state, it is a short exploratory platformer, but we plan on making another version in August which will include enemies, weapons, a much larger world, and various polishing touches. And yes, I know I’ve promised such improved versions in the past, but I think it’s easier to keep such promises when there’s another person involved to keep you on track, no?
(in other news, I managed to rock a solid 95 on number chains a few days ago)
0 Comments -
May submission - Number Chains
I was worried for a moment that I’d have to break my submission streak this month, because the project that my buddy Mac and I were working on for May fell through the cracks (temporarily, at least). However, I was bored in class yesterday, and was entertaining myself playing a little game I had made up using pencil, paper, and the random number generator on my calculator, and it occurred to me that the game I was playing was entertaining, innovative, and extremely easy to program.
So, I now present the simple yet challenging puzzle game: Number Chains. When playing in class, I managed to get a score of 94 (100 is the maximum possible), but the best I’ve managed to do on this screenshot-able version is 91:
0 Comments -
April submission - Crazy Ninja Gun Dude Who Is Orange For Some Reason
CNGDWIOFSR for short.
A very simple yet very addictive platformer. This is probably the most audiovisually polished game I’ve made to date (which is sort of sad considering how long I’ve been interested in gamedev). Can you beat my highscore of 110?
0 Comments -
March submission - Battle Simulator
Alright, I lied in my previous post - I won’t be doing the rogue-like for March (though it’s very likely that I will do it for a later month). Instead, I dug up a project that I started a couple years ago and made some improvements to it. The game is a battle simulator that was inspired by the Merlin’s Revenge series of games. There is no objective - you simply put a bunch of units on the screen (some on the red team and some on the blue team) and sit back and watch the two teams duke it out.
The game currently operates only in a sort of “sandbox mode” where you can click to place units on the screen (without any limits on which units or how many units you can use) and you can pause/unpause the simulation. What I may do at some point is create a more goal-driven play mode in which each team has a certain amount of money with which to purchase units. If you look at the source file “Main.java” and look at the comments at the beginning, you can see some of the science I’ve done in determining which setups are approximately balanced, in an effort to determine what would be fair monetary values to put on each unit. If I do end up making such an improved version, it would hopefully also have some audio, as well as better graphics.
0 Comments -
Procedural dungeon generation
I said before that I was going to try to make a version 2 of Trinity Tower Defense for either February or March, but I’m feeling somewhat disillusioned with that game. I might end up doing a version 2 of it some later month if I just can’t think of anything else to do, but for March I’m planning on doing something more in line with the optional March theme of “Rogue”.
Rogue-like games often involve randomly generated dungeon layouts, and that’s what I’ve been working on since yesterday. Here is an example of a dungeon layout generated by my program:
The solid white square is the player starting position, the hollow white square is the end of the dungeon, grey doors open automatically, and colored doors require a corresponding colored key in order to be unlocked.
The first step in generating the dungeon is to take a blank rectangular dungeon, randomly slice it into two smaller rectangles, and recursively repeat this process with the smaller rectangles until the rectangles reach a sufficiently small size.
In order to avoid having too many very thin rectangles, I weighted the random slicing so that tall, skinny rectangles are more likely to get a horizontal slice and short, fat rectangles are more likely to get a vertical slice.
We want our rooms to have more interesting shapes than just rectangles, so we repeatedly join random pairs of adjacent rectangles, making sure the resultant rooms do not exceed a certain maximum size.
That establishes the room layout, but we still need to decide where we want to put our start point, end point, doors, and keys. We do this by looking at the adjacency graph of the room layout. The adjacency graph for the example above is shown below, but it’s not very interesting, so we’ll use a new example for the remainder of this explanation.
The first thing we do is establish the “main path” which is a sub-graph of the adjacency graph and is a “tree” meaning that it contains no cycles. We start by picking a random room and following a random path from that room that does not cross itself. The path ends when there is nowhere left for it to go without crossing itself. This process is done twice, both times starting at the same room, so we end up with a nice long path that meanders around the dungeon. One of the two endpoints of this path is set as the starting room (shown as a solid white rectangle below).
Now we add some extra “branches” to this tree. For each branch that is added here, one lock/key pair will be added later. There is a certain threshold that is determined by the current dungeon level (in the game), and we keep adding branches until the number of lock/key pairs reaches that threshold, or until there is no room for more branches. Let’s say the threshold is 3 in this case. We will pick a random room in the tree and do the same process of random path following we did before, and this will be done 3 times.
This completes the structure of the main path, but we still have 4 rooms that are not on the main path. We want to ensure that, between any two rooms on the main path, the only path between them is the main path itself. In other words, cycles are only allowed if they do not include any room in the main path. To enforce this, we look at each room off the main path and determine which room on the main path it is closest to (if it’s equally close to multiple rooms, we choose randomly).
Now anywhere we have a red or cyan connection, a door is built between the two rooms. The dark blue connections are discarded. We still need to determine which doors are locked, where their corresponding keys are, and where the dungeon end point is. To do this, we only consider the main path, and use a recursive algorithm to repeatedly place “goals” (the first goal being the dungeon end point), lock them up, and set the keys needed to unlock them as the goals themselves. A high level overview of this algorithm would look like this:
The ending point, as well as all locks and keys, would be placed with a single call to placeGoal:
placeGoal(main path (with start room as root), end room, number of keys)
0 Comments -
February submission - Warp Tunnel
Warp tunnel is very simple, yet very addictive. Steer your spaceship with the mouse and don’t crash into walls.
0 Comments