iDevGames Forums
Convergence (update: finished!) - Printable Version

+- iDevGames Forums (
+-- Forum: Community Zone (/forum-4.html)
+--- Forum: Contests (/forum-19.html)
+---- Forum: uDevGames 2011 (/forum-22.html)
+---- Thread: Convergence (update: finished!) (/thread-9121.html)

Pages: 1 2 3 4

Convergence (update: finished!) - ThemsAllTook - Jun 30, 2011 08:24 PM

Latest playable build (1.2.0)
Final uDevGames build (1.1.0)
uDevGames source code zip (1.1.0)
svn repository

Hello everyone! I'm going to use this thread as a blog for my uDevGames 2011 entry. I'll do my best to keep it updated with my progress throughout the contest.

The plan for my game: It's an action-oriented 2D dungeon crawler, somewhat inspired by Dragondot. The game will have many levels, each with a unique challenge. The twist is that when you enter a dungeon, you choose a character, and each has a drastically different playstyle (melee, ranged, stealth, etc.). Completing the game fully would involve defeating every dungeon with every character. Dungeon goals may even change depending on which character you're playing.

The game is being developed using my open source game framework, Stem. Even in the first few hours of the contest, it's proven itself to be tremendously useful compared to writing from scratch: Within a few minutes of the start time, my game was compiling and running with a blank OpenGL window. Normally this takes me about an hour, including figuring out why my graphics won't draw. I was able to skip right past that initial hurdle and get to the game coding right away.

Progress so far: Player is drawn onscreen (with a placeholder graphic) and can move smoothly in four directions. I'm planning to upload a playable binary every time I make a post here (unless I'm in the midst of a major refactor or something and the game can't be built). Here's today's:

Next thing to do is to decide on a level file format, make some test data, get it loading and displaying, and implement basic collision detection.

RE: untitled uDevGames 2011 entry - AnotherJake - Jun 30, 2011 09:24 PM

Works great! Best game I've played in the contest so far. Cool

RE: untitled uDevGames 2011 entry - Skorche - Jul 1, 2011 08:24 AM

It was pretty fun until I moved off the screen, then I sort of lost interest. Is it part of the game to see how well you can avoid hidden obstacles? I guess you could probably make some unique puzzles that way. I also had a hard time feeling connected to the player avatar in the game. I'm much more partial to nonagon shaped ones for some reason.

Looking good so far though.

RE: untitled uDevGames 2011 entry - ThemsAllTook - Jul 1, 2011 08:57 PM

You guys crack me up! LOL

I'm working now on figuring out what sort of data model makes sense for the game's levels. I did a sketch just to brainstorm and have a starting point for the sort of thing I want it to look like:

That breaks down, roughly, into these pieces:
  • Walls
  • Starting location
  • Exit
  • Pickups (powerups, keys)
  • Doors
  • Enemies
    • Type/stats/behavior
    • Starting position
    • Facing
    • Patrol route (if applicable)

I was thinking of modeling the walls as a vector outline, but after thinking about it and discussing with the folks in #idevgames, tiles seem to make more sense. So, a level will probably consist of a tilemap png and a json file that maps colors in the png to wall/floor tiles, and defines the non-static objects and entities in the level.

No new playable in this post since I've just been doing design work, but once this is all implemented it should be a lot more interesting to play. Once I have a test level loading and some basic collision detection, I'll probably work on enemy AI and combat. I have in mind what I think will be a very cool and unique combat system (at least for one of the character classes; they'll all work differently!), but I won't describe it here just yet. No need to ruin the surprise!

RE: untitled uDevGames 2011 entry - ThemsAllTook - Jul 3, 2011 08:42 PM

Might as well post this now since I'm not going to get any more work done directly on the game tonight...

I got (the beginning of) a level file format defined, implemented deserialization so I could load my test files, and added some code to draw them. So, you can see and move around the level geometry now (with the BEST TILES EVAR).

Collisions come next, once I can get back to the game itself. I'm mired in technical details at the moment trying to transition away from GLUT to a native Cocoa wrapper. Should be able to wrap that up quickly enough and get back to the fun stuff!

RE: untitled uDevGames 2011 entry - maximile - Jul 4, 2011 03:31 PM

Would you mind doing 32-bit builds (or at least take post some screenshots)? I'd love to see what everyone is working on.

RE: untitled uDevGames 2011 entry - ThemsAllTook - Jul 4, 2011 11:59 PM

Today I finished transitioning away from GLUT, so the application is now running on a shiny new Cocoa wrapper. After that was done, I implemented collision detection and response. Having implemented a lot of collision systems before, I know the patterns to use, so I was able to do something reasonably sophisticated (for a top-down 2D game) in an evening. Here's how it works:
  • When the player's position is updated, the previous position is stored.
  • After updating the player's position, I pass it and the dungeon tile map to the collision manager for resolution.
  • The collision manager takes the union rect of the player's old position (+ radius) and the player's new position (+ radius), and iterates through every tile in the dungeon which intersects that rect.
  • If the tile is a wall, I check to see if the player's intended line of travel will cause it to pass through one or more of the tile's outer walls.
  • Whenever a potential collision is found, it's compared against the best potential collision that has been found so far. One or the other will be discarded. Comparison criteria:
    • Early collisions win over late collisions.
    • If the two collisions have occurred at the same time (within a small margin of error), whichever has the largest "coverage" wins. Coverage is calculated as the amount of overlap between the player and the tile on the non-colliding axis. This is done so that if you're trying to move diagonally, you won't collide with the "crack" between two tiles that form a solid wall.
  • Once all potential collisions have been considered, the best one (if any) is applied. The player's position is moved back to the closest non-colliding point, and velocity on the colliding axis is set to zero.
  • The timeslice is subdivided. The player's last and intended positions are updated, and collision detection is run again for the remainder of the timeslice. This repeats until either no collisions are found, or an arbitrary subdivision limit is reached (to prevent the program from halting in a degenerate case where collisions are unresolvable).

(Jul 4, 2011 03:31 PM)maximile Wrote:  Would you mind doing 32-bit builds (or at least take post some screenshots)? I'd love to see what everyone is working on.

Can do! Today's build is i386/x86_64:

I liked the smaller executable size with just x86_64, but that's not worth causing people to be unable to run it. I suppose I could go with i386 only and forego the 64-bit benefits...hmm, will have to think about it.

RE: untitled uDevGames 2011 entry - aarku - Jul 5, 2011 11:08 AM


The emptiness of the blue void reminds me of the loneliness that can evoked when we stray from society's norm. It is powerful to realize that we can always find comfort again in the floor and walls of our structured culture if we only know which direction to head. We are faceless cogs of society's machine just like the white circle. There is evidence that we are not alone from the structures built around us, but yet we isolate ourselves and choose to not truly see each other. We are more than white circles, but we must see ourselves as a white circle before we can truly begin to see others as more than faceless cogs.

The game artist is strongly conveying the emotion of hope in allowing the character to come back to the game world after voyaging into the void. Hope is never lost and one day society will be able to see past the "white circle" and be free from the walls and floor. The void will become the norm and we will begin to see the void for what it really is: walls and floor.

10/10 would play again

RE: untitled uDevGames 2011 entry - Zorg - Jul 6, 2011 09:02 PM

Do a 64-bit build if you don't care about 32-bit users. Do a 64/32-bit build if you care about both. If your code is 64-bit compatible, file size is not a good reason to doing a 32-bit only build...

RE: untitled uDevGames 2011 entry - ThemsAllTook - Jul 17, 2011 05:31 PM

I've had a lot of distractions in the last week, and haven't managed to get much work done on my game. I finally got a chance to sit down this weekend and make some real progress. I've replaced the horribly ugly tiles with something a bit more appealing (though still very plain), using Colour Lovers to get a nice pleasing color scheme. A few of the enemies from the level sketch I posted earlier are now in the game. They patrol on a specified route, but don't do much else yet.

Today's build

I thought I was nearly done with collisions when I made my last post, but trying to get all the kinks worked out of moving object <-> moving object collisions raised a bunch of issues I haven't fully solved yet. Discussion about my collision system on the tigsource forums led me to write this tutorial, which took way longer than I expected and is one of the reasons I wasn't working directly on the game for so long. It's not quite finished as of this post, but once it is it'll be at the same URL. Part 1 deals only with moving object <-> static object collisions, so I need to resolve my moving<->moving problems before I can finish part 2.

I'm particularly excited to start working on enemy AI - I've only written one other game that required it, and it was so long ago I barely remember and much more simplistic. Going to be a lot of fun to discover what it takes to get things to behave how I want!

RE: untitled uDevGames 2011 entry - OneSadCookie - Jul 17, 2011 05:39 PM

the little wiggle the top guy (who patrols an oval) does when he returns to horizontal movement does is pretty funny

RE: untitled uDevGames 2011 entry - ThemsAllTook - Jul 23, 2011 10:25 PM

A bunch of miscellaneous stuff in today's build:
  • Player and enemies now have an arrow indicating which way they're facing.
  • moving<->moving collisions are enabled, though they're buggy; pushing against an enemy will in some cases cause you to pop to a different part of the level.
  • Enemy speeds and patrol behavior tweaked, which eliminates the funny wiggle.
  • Player can now "attack" (spacebar), though it has no effect yet other than the visual and sound.
I need to get collisions in a bit better shape, then I can start on combat and enemy AI.

RE: untitled uDevGames 2011 entry - SethWillits - Jul 26, 2011 03:17 PM


RE: untitled uDevGames 2011 entry - AndyKorth - Jul 27, 2011 08:17 AM

The attack animation is really cool!

RE: untitled uDevGames 2011 entry - ThemsAllTook - Aug 7, 2011 07:53 PM

A mountain of distractions continues to slow me down, but I finally made some solid progress this weekend. I had to do a lot of refactoring and other work that isn't generally visible. The most notable new things are that attacks have an effect on enemies now, and you have a second projectile attack (press f). If you kill all of the enemies and get bored, you can reset the map with r.

Collisions are still a little bit wonky in places, but they're good enough to be workable for the moment. I wanted to get attacks working before I really started on enemy AI, and that's the very next thing on my list. Next build will have enemies behaving more more interestingly.

(Jul 26, 2011 03:17 PM)SethWillits Wrote:  MOAR SCREENSHOTS.

[Image: screenshot_2011-08-07.png]

(Jul 27, 2011 08:17 AM)AndyKorth Wrote:  The attack animation is really cool!

Thanks! It took me quite a while to get it to look how I wanted. I'm not completely sure I'll keep it as it draws only the portion of the swing that hasn't been drawn yet, which means it looks different depending on your frame rate (and can turn completely invisible without VBL sync).