Welp, I’m conceding defeat.
A huge draw bug has occurred.

Simply, units you can control live in an array. You have a dragbox to select them.
Once the dragbox falls over them, their respective select() method is called. This turns flips a boolean to true and changes their colour.
Simple.

For all units (except the final one) doing the select procedure calls the method select() but the colour does not change. You can actually issue individual commands to them still.
If you select the final unit in the array, all units are coloured but only the final one has the select() method called.
Bizarre…

I tested by creating a different way to select them (using the exact same methods) and it works. Reducing the population to 1 also works (the only unit is the end of the array.)
It seems like the dragbox doesn’t it EXCEPT that the select() methods on the units that should be selected is called at the correct times.

Painfully aggravating.

I’ve run about 10 different tests and I end up with the same issue so I’m thinking it’s a draw issue. Still, it could be something glaringly obvious.

So, that’s that.
Final screenshots
RPG Mode:(Ignore that minimap issue…)

RTS Mode:

As this will be my last game for quite sometime, this is most disheartening. But hey, in my 3rd attempt to make an RTS, this is by far the furthest I’ve gotten. A shame to be cut down by such a silly bug.

After the cut is me rambling on about the concept. (Which I actually rather enjoy.)

Okay. This all began with the idea of isolation.
You are an inhabitant in a town that has no connection to the outside. This had a couple of variations:

• The town was forced to be closed by a military-like force. Would have had patrolling guards. Also would have had recruitable units.
• The town had been cut-off for thousands of years but no-one ever dared to venture outside. Also would have had recruitable units.

The key difference between those two is the motive of the protagonist. The former is purely the protagonist’s yearning for freedom outside once again. The latter’s is the protagonist is tired of tradition and people’s contentedness to remain where they are without knowing anything of the world around them. (That last one sounds a little familiar but I came up with it before watching SNK.)

The former I thought was a goer for a little while. Little being the operative word here.
I started off using this concept and by day 2 (I think) I was very sick of it. Why? It wasn’t very good from a narrative stand-point.

So, I spent a little bit thinking again. I went back to the 2nd idea.
I then remembered I have a concept for something kinda similar but instead of physical walls, the walls lie in the protagonists mind and it’s a metaphor for learning how shitty the world is blah blah blah.
So I combined them.
And named it [eyknir].

So, I’ll describe how it goes in an procedural fashion:

• You start in RPG mode. You can talk to inhabitants of the town and learn their views. Eventually, you’ll speak to everyone and you’ll go to sleep.
• Next, in a subconcious state (dream or not…) you’ll have to do battle with various aspects of ones self in RTS mode. In your arsenal you have Confidence, Knowledge, Curiosity and Willpower. The enemy has Mediocrity, Tradition, Laziness and Subservience.
• There are resources, sort of. Energy and Motivation. Energy decreases over time and is halted by destroying an enemy. Motivation increases everytime an enemy is destroyed. Once Motivation reaches its max, you can build a new unit.
• After the RTS mode, you go back into RPG mode where the inhabitants speak in a slightly different tone. The colours of the town also change slightly.
• You talk to the people, do battle and so on, all the time the town is getting worse and the people are getting weird.
• If you lose, you return to a perpetual state of mediocrity.

So, that’s how [eyknir] goes.
It deals with ignorance, truth and perception.

The world is not always as we perceive it to be, but we strive to perceive it in a way where ignorance and truth can be balanced out. A total truth can be just as harmful as total ignorance.

Because I have to make all my games deep or something…
Fuck, I might find time to make a Twine game from this idea.

Hi guys,

Well, that was one hell of a ride.

To facilitate my testing better, I divided my web builds into two: Release, and Experimental version.

This is pretty much the same idea with stable, and development versions: the Release version is the latest that has no (showstopper) bugs, while Experimental is the bleeding edge version with new features for testing.

Right now, the Experimental version is the one that has the Bone Wheel unit.

Here’s me and my friend doing a playtest:

I’d appreciate if you gather some friends and test the Experimental version if it runs ok! Send me messages on my Twitter, or comment in this page.

You can check out my entry here.

Tags: progress, screenshot, Strat Souls

So after 7 days I have a game of sorts. Win Condition and 8 levels! of madness.

Things that went well:

Happy about the music I wrote for the main theme last night.
happy with my title screen
glad I made some more levels then one.
Play testing! I had two friends play it and that was a great learning experience.
Recording my own sword fighting folly(ok my gf helped luckily she didn’t hurt me)
Learning to analyze creative thoughts quicker, still have lots of room to grow.

Things that didn’t work out:
Enemy pathing AI etc (much harder then I thought)
Ballance? (I can beat the game but it’s pretty ridiculous for other people)

Graphics, really really wish I had more time or was just more efficient. I’m use to taking a day per frame of art… there was so much more I wanted to do.
Basic time management, I learned a lot but working solo on a project like this it was really eye opening.
waiting till the last day to make levels.
spending too much time on music/graphics all the things I really like.
animations that I can make quickly and not look like seizures.
Not sure if Game Maker is best for RTS

My biggest take away for me was the point after day one, when I had to drop all my cool Ideas and just try to make something that barley resembles a game.

Thank you to all the people that streamed and posted really was nice not to be alone doing this and I learned lots from you guys.

Windows: sorry about the exe file

http://www.ludumdare.com/compo/minild-44/?action=preview&uid=24829

I’m not going to bombard you with paragraphs so here are quick points for a postmortem:

SO SO: I used old base code from my turn-based strategy game experiments. It was not the best fit. There were some few unused pieces of code that I had to clean up (“I don’t think I’m using this function, I should delete it, it’s distracting me… but is this part really not used? I have to check…”).

GOOD: Clearly define the scope of what you’ll do. That goes without saying, and yet some people don’t get this. When I see others saying “I’m gonna add this and this and this, I think it’s ambitious for the time-alloted, but I think I can pull it off LOL” that’s already a red flag right there. Do you even have a concrete plan to do all that?

I put it out there that I can create either a singleplayer game or a multiplayer game, but not both. At least, not within the 7 days. So I asked in the Ludum Dare website which they want first. Of course I want to add both eventually, but I have to choose what to finish within the 7 days.

GOOD: Create a “testbed” level to quickly prototype ideas. A sort of playground level without victory/defeat conditions so you can test things quickly. I do this all the time. Shigeru Miyamoto does this, so why wouldn’t you? Don’t you love Miyamoto-san?

GOOD: Sound software engineering practices. Abstract low-level details with high-level convenience functions! Reduces clutter, makes it easier for you to think! I’m going to write a separate article about this.

GOOD: Used NGUI! Worth the $45 (got it on sale)! NGUI’s WYSIWYG workflow allows you to design GUI layouts fast!

GOOD: Used free art assets from the Internet! Some editing was required but still lessened amount of work!

GOOD: Made my own 3d animations! Better control on how I want attacks to move.

GOOD: Used primitive shapes for my 3d models on purpose. Didn’t add legs to lessen work! No need to animate legs! Looks cute according to some people! (?)

GOOD: Made use of free 3d models from blendswap.com (i.e. the skulls of the units) to lessen amount of work.

SO SO: I probably should have made use of a state machine to facilitate low-level behaviour of units. But with the behaviour tree plugin I integrated, I think I can make use of that instead. I did not choose to do this though, as I concentrated on multiplayer instead as requested.

GOOD: The good thing is all the ugly code is hidden behind a clean interface & facade class. So eventually I can clean up my ugly code without adversely affecting the rest of my code.

KIND-OF BAD: Should I name my function FaceUnit() or TurnToUnit()? Can’t decide! Drives me crazy!

GOOD: The network code I made includes a lobby and match-making service, which I could use later on for other games.

GOOD: Although I use the built-in Unity network library, I modularized my code so I can swap it for a different network library instead (Photon or uLink, maybe?). This is probably likely as I’ve heard many complaints that Unity’s built-in network library is buggy in real-world use (when there are dozens of connecting clients).

SO SO: This game jam forced me to learn git subtrees. I lost sleep wrestling with the damn thing, but now I can use it.

BAD: Live streaming? With the quality of Internet connection in this country, forget it. Tried it. 90% of my streaming video’s frames were getting dropped.

GOOD: Keep two versions of your builds: one for the clean, playable, version, and another for your experimental version where you are adding new stuff. In case what you’re adding won’t make it to the deadline, simply use your last clean, playable version.

I usually release my Unity web builds on Dropbox. But I realized I should have put two versions on Dropbox, i.e. the two versions I mention. There would be a StratSoulsRelease folder and a StratSoulsExperimental folder. Once I’m sure of my experimental version’s stability, I simply copy the necessary files over to the release folder.

Tags: postmortem, Strat Souls

Schaak!, my 7dRTS for MiniLD 44, is complete and submitted. Coding started at 9pm on Monday the 22nd, and ended at 9pm on Monday the 29th. Very little of the process went to plan. The repository is online at https://github.com/essarrdee/Schaak.

DAY 1

Day 1 was mostly taken up with scribbling and typing design ideas, and emailing my collaborator about CMake, ideas, and names. Various bad puns and portmanteaus were rejected without comment, Persian and Spanish words were considered, and a Dutch word was settled on. Coding started at 9pm, and mostly consisted of copying SFML boilerplate from a previous project.

DAY 2

Coding continued into the night. Board drawing was set up pretty quickly, followed by board drawing with cover indications (showing whether a square is guarded by black or white pieces). I took an unusual approach to board rendering – a texture the size of the map is stored on the graphics card, and updated regularly with the cover information. The board size had to be halved to fit this texture in my CPU-GPU bandwidth.

After a sleep, scrolling to zoom was implemented in the evening and piece definition files were planned – just a name, sprite information, move speed, and list of move/capture locations.

DAY 3

Implementing the piece data loading was pretty quick. Next I made a dummy piece, the Doomed Wanderer, that jumps around the map in Knight moves and tests the protected-square display’s correctness. With one piece working, it was time to plan how thousands of pieces would work – not a trivial consideration when all of them will be AI controlled. The plan was to exploit the grid nature of the board – if you need to know whether a piece is in a square, you just look up the ID of the piece in that square. This simplifies capturing and collision avoidance. I also wanted to keep the vector of units compact, minimise the number of gaps formed when pieces die, and minimise the time it takes to spawn a new piece.

With the help of some people from the IRC channel, I settled on a three-part structure to hold pieces:

• The vector of piece objects, indexed by piece ID which never changes during a piece’s lifetime
• The double-ended queue of free slots in the piece vector, which just lists all the piece IDs that don’t correspond to a live piece
• The 2D array of board occupants, mapping each square to the ID of the occupying piece (or -1 for no piece). Pieces also store their own board coordinates.

With the first two of those implemented, the Doomed Wanderer met his fate – deletion. I now had random walkers spawning a few times per second. There was no collision detection without the occupancy grid, though.

DAY 4

I had been making attempts to recruit artists to draw chess piece graphics since day 2, but everyone either joked about how their pixel graphics skills were so good that they could draw 1×1 sprites, or made an attempt and gave up. Or told me to use a font that doesn’t scale small enough, or attempted to shrink vector sprites down to 8×8 and smaller (with antialiasing).

Halfway through the challenge and I only had a board full of invisible random walkers. There was no way around it, I had to make the sprites myself, today.

It took about 3 hours to get them right. I looked at low-resolution chess sprites from around the internet for inspiration, and for the larger ones visualised my grandfather’s chess set. The knights look pretty stupid. Drawing pixel horses is difficult.

The high-resolution sprites have outlines, and to smooth out the zooming I made the 16×16 ones have half-outlines. They looked *terrible* like that. I added a bit more outline to them, but I’m not really sure what to do with them.

Code written today: zero lines. Halfway through the challenge, I only had a board full of random walkers and a spritesheet.

DAY 5

Progress towards drawing sprites. Still no chess pieces on screen. Time to get concerned about whether I’ll finish the game.

DAY 6

Continued coding into the night. First thing accomplished was pieces being drawn. Squashed bugs. Got a linux makefile from a new collaborator, who exists. Implemented scrolling. Decided it would be a bad idea to develop epilepsy while coding an RTS, set scrolling speed to prevent horrible flashing. Made pieces mortal. Made a video demonstrating the zoom functions and piece sprites: http://www.youtube.com/watch?v=XIKouIOXPtY

Pieces are mortal – time to make them capturable! Planned and implemented the generic piece AI, capable of 4 out of 5 of the behaviours I want (the “protect” behaviour requires an extra, more difficult feature). Loaded behaviour definitions from files (but I only wrote two of the 4 behaviours). Took me a while to notice that the value-based AI was actually picking its *least* favourite move. Discovered this because a lot of pieces set to “Kamikaze” were ignoring all opportunities to capture enemy pieces…

Next problem with the generic AI was that the move-choosing method sorted by target coordinates when values were equal. This meant that *everyone* beelined for the bottom-right corner of the map. And captured their friends. Fixed. I added a behaviour that causes pieces to seek friendly pieces’ cover, which made them form clusters. Made a video of that: http://www.youtube.com/watch?v=ght5eUgH3QM. I changed the friendly/enemy cover colour scheme from green/red to green/magenta to improve colourblind usability.

6 days into the 7 days challenge, I had exactly zero ways of letting the user interact with the pieces. This needed to change, and the first thing to do was implement selection and commands. Dragging boxes with the mouse is pretty awkward on a scrollable zoomable map, but I managed it. Set selected pieces to flash regularly. I didn’t have time to implement complex things like orders to attack specific units or groups of units, so the only command you can give (and really the only command you need) is to set a destination box by right-clicking. The distance from the destination box feeds into the unit’s value system and lets them follow orders – within reason (trying to stay out of enemy-covered squares, taking capture opportunities, etc.). I made a video of the epic battles possible with this command system: http://youtu.be/LA75nbdoZU4

At some point there was some sleep. I also started ignoring the TODO list and scribbled down a list of priorities for giving the game some semblance of strategic depth on the last day.

At some point this day or yesterday I decided that playing this game against an AI was a terrible idea, and that playing this game over a network was not something I could code in 2 days. It had to be local multiplayer. Switching control between black and white and playing against oneself or a real-life friend.

DAY 7

Epic battles are only meaningful if you can tell who came out on top. Added piece counters for both players.

Added an interface, the screen looks so much nicer at minimum zoom now. Buttons to select all units (which gave me trouble when I recorded the previous video), or to select all units of a given type, or to restrict the current selection to units of a given type. 20 minutes left.

Added buttons to switch pieces between behaviour types, with no feedback of any kind as to what behaviour they now follow. Added a key to delete pawns and earn money, and buttons to upgrade piece speed and pieces’ chance to cheat death. Again, no feedback. 5 minutes left. No chance of adding feedback for these features now. Users will just have to keep track themselves…

Updated the readme, took screenshots, submitted.

I really want to add those few sf::Text objects to make the game more intuitive. Maybe a button to display the controls in-game. This will all have to wait for a non-7dRTS update.

Hey Guys,

I’ll be continuing development on my MiniLD game, and thought it’d be nice to stream the entire process, therefore, go to this link to catch the action: twitch.tv/0creds

Hope To See You All There,

– 0Creds

After some seriously mind-blowing time spent on basic math failures (I’m looking at you, logistics functions), I’m back to showcase the project heading into its final hours.

First of all, I’d like to thank everyone that worked on the project here at the University of Minnesota’s Video Game Development Club, all of whom are listed in the credits on the main menu. Good work team!

Meanwhile, in Space… is a javascript RTS game set in a 1950’s B-movie universe, where you select the different head and body of your “race”, and then take over planets and do battle vs the basic CPU enemy. Due to time concerns, the extensive battle scenes have been cut, and fleet battles are now determined by whoever has the greater health. Galaxy generation has also been reduced to one pre-made galaxy due to time concerns. Damn you 7 day format!
The decision was made to continue development past the 7 days (through the rest of the summer semester), but we will be submitting the 7 day project around midnight tonight.

Next, I’d like to show some screenshots of the galaxy menu:

You can see the rotating planets here as well as a sample fleet of three ships. As you can also see, the race modifiers are not implemented yet, but the assets are done, and merely need to be programmed in. We should have this done by late tonight. You can also see the buy window on the right, but since we have no planets captured in the screenshots, we have no resources to build with.

Everyone here is making one last push, and I need to rejoin my team, so I’ll cut this one short. I’ll be back with a link later tonight. Thanks!

 Entry Page for MOBIUS // Oreganik Home Page // Dev Blog

If you’ve ever been fishing, you probably know the feeling of hooking something big, pulling it to the surface, getting it almost to the shore and… splash! The hook is out and the fish is gone, deep into the weeds, cartoon curse words bubbling up in its wake, and real ones blotting out the sun from the hands holding the rod.

Normally, that’s how I feel after 48 hours of Ludum Dare: like something got away, and I lost whatever I was after. But by stretching this out over seven days, even though the fish got away (like it always seems to do!), I really enjoyed the fight to bring it home.

This was my first compo entry since I officially founded Oreganik LLC as a business. When I started, I tried to balance working all day on one game (Chess Heroes), then coming home, being a good husband and father for a few hours, then working on this game. THAT WAS EXHAUSTING. Then I realized: hey, I make games for a living! I can just do this as my day job! So Thursday and Friday were full dev days, as were Sunday (after waking up deep in the forest) and Monday. All told, this represents about 40 hours of work, and hey! It’s a great foundation! Now I get to see if enough people are excited about what Mobius could have been to see if it’s a candidate for full-time development at a later date.

I also learned some good rules to follow for next time. And, because this is officially “what I do” now, I can take the time to properly write it all down. Stuff like “how to write an extensible transaction model that simplifies functionality and centralizes data.” And then MAKE that model, and then have it in the pocket for the next compo.

^_^

Well…didn’t meet the deadline ;__; but I did enjoy doing it!! But I have a base for something so I will keep with it :). With school and work I had to squeeze what I could.

Stage 1

First I focus on the player moving and controlling their little box man.  I wanted to the building to hold a certain amount of units in side a building and when they sensed the player was too close for comfort they would come out and start to defend the building they took over.

Stage 2

I got tired of testing on a blank background and took the time to make a scrolling cloud back ground and to draw out the level land. Was looking at upgrading the building models but didn’t being that I wanted to have the building code more functional.

Stage 3

So started working on the code to get the man to come from the building and attack the player once they got to close and if the player got to far away the unit would return back to the building that they are defending.

Stage 4

Wanted to code the player unit to be smart enough that if they are being attacked or see the enemy that they would go into defense mode and start to attack.

Stage 5

Add a 2 more units so I could code the multi-selection tool that was very tricky and I ran into trouble to get to work.

Stage 6

Started to code the commands the player could give to their unit. Sadly only coded the movement.

What I think that slow me down was I kept trying to refine the code I already had instead of going forward with the project. So I always found myself going back to something that might have not been perfect but functional and trying to make it  as best as I could. Maybe next time I can try to refrain from this habit during a competition.

~~Yasmeen G~~

12:40 A.M. and I have finally finished a simple build of the game. I didn’t have enough time to give the game all of the bells and whistles due to work and schedule conflicts, but the build is functional and entertaining. In the end, that is good enough for completion, and “Quebec” is ready to roll.

Above all, this project has shown me that I have the ability to finish a project. This is my first real game jam that I have done, and it was awesome. It really taught me that one of the most important things to consider is the scope. There is only so much that developers can do within a week, especially a beginner like me. In the end, it comes down to timing, the code and a prayer.

Here is to taming the game dev wilderness. Good luck to everyone in the judging!

It’s been a crazy week, but we finally have a (arguably) playable prototype. Still plenty of work to be done, but here is our first version: http://www.ludumdare.com/compo/minild-44/?action=preview&uid=24975

Sail the high seas and defend your booty from other pirates!

Booty Defense (working title) is a prototype programmed by Rob Williams, with art by Dustin Brown and music by Jordan Beischer.

Heavily inspired by Plants Vs Zombies but with a lot of different features planned for the future.

Updates coming soon! Stay tuned to http://bootydefense.tumblr.com/

Tags: #7DRTS

[View my entry : Age of Rice]

I’ve not develop it during the seven days and lot of features are not implemented.

Well, that was a busy week 😛

We already had some RTS codes in our codebank, so making one didn’t seem like a problem. 7 days? Bring it on!

Oh, we were wrong. Very, very wrong.

First of all, most of the codes were rewritten anyway. Previous RTS was too different and much simplier than this one.

Crime 1930 features four players trying to capture the control points. AI needed to capture points and fight 3 opponents, thus alot of time went into writing the worthy opponent.

Secondly, we wanted to make a game with shared economics, where one player’s purchases would influence prices of all other players.

This system ruined our testing immediately, sending and receiving NaNs. We fixed in a very last minute.

Thirdly, in the middle of the process our artist suddenly departed.

We needed character skins and fast, so I had to take her place, remembered GTA Vice City modding times and used VC skins as references.

Well, that’s pretty much it!

Here’s the game: Crime 1930

I hope you enjoy it!

We’re planning on expanding the game further, so if you have any suggestions, let us know!

Hey guys, just wanted to take the opportunity to write a bit more about World’s Aftermath, and the process behind it.

Assets

One thing we strived for when we were planning this project was that we really didn’t want to use any content that wasn’t our own. So, from day one, Nicolas set out drawing pixel art, laying down guitar tracks, and doing voice overs for the character deaths. He kept a steady stream of content coming in, and I plugged away endlessly programming it all together. Every day when I returned home from work Nick told me he’d been up till 6am drawing dozens of animations. One night he stayed up all night animating 30 strips of animations and laying down the entire soundtrack. By the end of it all, we had 300+ frames of graphics, 6 original songs, 50+ original sounds, and half a dozen levels.

Code

All of the source code is original too. I’ve been working on a 2D game engine since 2007 that I’ve been using for all my other projects. The night before the competition I gutted out one of my projects of all it’s content so I could start with a blank canvas. I used my custom World Builder (level editor) to design the levels. The engine is written in Java, and uses the Java2D graphics library for rendering (which I’ve optimized immensely). The most important thing, I realized, was that I would need to be able to create units for the game as quickly as possible, and that I wanted hundreds of units and hundreds of bullets on the screen at once. The game was going to be visceral and gratuitous and I think we hit the mark.

Every single variable, animation, sound, and unit/bullet type is defined in the INI files in the /gamedat/ folder (which leaves rooms for mods). By the time we were finished, units, bullets, sounds, levels, etc. could all be added without a single line of programming. To make sure the units could pile up without slowdown I wrote a spatial partitioning algorithm that sweeps over all the units at the beginning of every frame. Each unit is put in a different “bin” for every 100 pixels.  This way, unit vs unit or bullet vs unit comparisons are made only on those units in the surrounding area by getting only those “bins” in range.

Gameplay/Mechanics

We really looked to Command and Conquer as a source of inspiration for this bad-boy. We wanted to capture the vibe of the original Command and Conquer, but we also wanted to make a game that could be played by anyone, without ever having played an RTS. So, we simplified the control scheme and mechanics quite a bit from a traditional RTS. This is where we feel we’ve innovated. Without direct control of unit placement, we were able to reduce the gameplay down to three actions (purchase, attack, defend), but made sure we left room for emergent gameplay and strategy. This created a very casual gameplay experience but also leaves room for a great amount of depth.

From the start, we realized the importance of making sure it was completely clear how to play without any sort of tutorial. So, we designed an intuitive and simplified control scheme that is ultimately compatible with touch screens. In this fashion, the entire game is playable with only a mouse, only a keyboard, or only a touch screen. Unfortunately, we had to ditch the tower defense and defend actions for this version, but adding them in our final release will give that additional layer of control that will really bring the gameplay together as a complete package. Forcing the player to commit to an attack makes each decision of what units to send, how many, and how often, that much more important; and the immediate urgency to capture towers right from the start sets the pace from the start of a match. Finally, the need to unlock tiers of units, as well as the importance of purchasing and defending your harvesters ends up making each purchase critical.

Finally, I’d like to mention that a design decision was made very early on to use object oriented code design to cleanly separate each aspect of the game. In this fashion units are separated from teams, and teams from players. We will be able to add in network support fairly easily for the full release, as the code is designed in a way to make networked control of a player trivial. Something we wanted to do from the very beginning was to play versus each other, so the full release will certainly have online multiplayer.

Music/Sound Design/Ambiance/Inspiration

We’ve both always been huge fans of the earlier games in the Command and Conquer franchise. And even though Nick won’t play me anymore because I dominate him every time, we wanted to draw from these games for inspiration. We intentionally left out a unit cap, and made sure the game could facilitate as many units as a player could afford. The music and sound design were crucial, also, in creating an homage to these games. We laid down some guitar tracks ala Frank Klepacki (see below), and did our best imitations of the Wilhelm scream that Command and Conquer used so charmingly for it’s infantry death sounds. Getting the artistic direction of the two factions and the mood of the game just right was critical–since graphic design makes or breaks a first impression–so we worked hard to capture a dystopian “Red Alert Vs Tiberian Sun” feel. We decided the more conventional “Rebel Scum” vs the domineering and futuristic “Allied Collective” would be a good representation of this. There isn’t a story explicitly stated in-game, but we feel we hit the mark with our “show don’t tell” approach that we meticulously crafted through the subtle use of our art direction and the limited wording/naming we sprinkled throughout the game.

In closing

Looking back, we feel very satisfied by what we’ve accomplished here. In 7 days we’ve completed a game from start to finish with all the technical aspects of game development accounted for (sound, music, graphics, level design, victory conditions, menus, AI), and a strong core set of game mechanics. We’re geared up to now create a proper release of the game, having proven our prototype, and in the coming weeks we’ll polish the game with all the love in the world and release a free version of the game with all the bells and whistles.

Download

Download/view our entry here:
http://www.ludumdare.com/compo/minild-44/?action=preview&uid=24948

Tags: #7DRTS, #indiegame, #MiniLD44, 2D, compo, final, game, gamedesign, gamedev, jam, java, Ludum Dare, MiniLD, post-mortem, postmortem

Unfortunately, we were not able to meet the mini LD 44 deadline. This was due to several factors, the main two being part-time work and windows drivers related casualties.

Though we did not finish Pile O’ Pirates in time to have a working game, we fully intend to complete it. So look out for progress updates and videos in the coming months.

Twitter: https://twitter.com/ElementalZealGS

Website: http://www.elementalzeal.com

Game Features so far

–        Zoomable 2D game

–        Selection/Movement of pirates constrained to boats.

–        Movement of Ship without screwing up pirates.

–        Saveable settings (Such as resolution and Fullscreen)

–        Over 300 styles of male only (as of now) pirates

–        Random name picking from list of popular male names.

Here are some screenshots of what we have managed to accomplish.

The beginnings of Pile O’ Pirates title screen.

A zoomed in view of a selected unit and his comrades.

Selecting some units in Pile O’ Pirates.

Moving a ship in Pile O’ Pirates.

See you all for the next Ludum Dare.

Tags: 2D, game, progress, screenshot, Windows, xna

Hi!

This is my first postmortem on my first LD game. I am not going to write much text, here it is some facts and thoughts.

“Rock, Paper, Geometry!” – is a real-time tactic game based on “rock, paper, scissors” rules with random generated levels and impulse movement.

What went right

1. I’ve finished it!
2. Feature cutting. I’ve cut more than 80% of  all planned features, leaving the most important and delicious. Time restriction is a powerful productivity tool
3. Surprisingly the game balance was achieved very quickly.
4. Very poor random AI generates different fun situations.
5. I think the gameplay has a good combination of skill and luck, providing a replayability.
6. Sound effects made the “feel” better.

What went wrong

1. I was distracting by my real job and 7 days unfortunately became 3 days.
2. No ambient music.
3. Hard to remember the rules of the game at the beginning.
4. The art. I hadn’t enough time to improve it.
5. Poorly written code. There is a little chaos

Conclusion

I’m very proud that my first LD experience was fun and I finished the game against the all road blocks! Thanks for reading!

Tags: #7DRTS, postmortem, rock paper geometry

Hello Everybody!

We’re really happy about the next Ludum Dare, it will be our 3rd Ludum Dare, I am absolutely sure that it will be our best entry yet

We are finishing up our last entry’s game.

North Korean World Saviour (Our last Ludum Dare)

Korean maneuvers over Canada

Mission Selection Room

Cheers

Team Something Beautiful

Unless by some miracle, I get struck with a surge of energy, I’ve been completely worn out. I have everything except the actual AI ready, so its just basically you walking around taking other bases with no real point or flow :'( To be completely honest, the games scope was a feasible one given that this was a normal week, but as some of you may know, it is Ramadan, and I’ve been fasting while working on it, so ultimately I just didn’t have the energy to properly finish it. I will be working on it past the due date though, and just release it as a normal RTS. Here are some pics and stuff.

While its all still without graphics, I have all graphics and sound already done and will be putting it in when I’m finished. It will literally take 5 minutes.

Well, Congratulations to those that did finish, I look forward to sharing the finished version of this game on a later date :D.

Hey Everyone,

Continuing work on my 7dRTS game, and streaming the entire process, you can check it out here: twitch.tv/0creds

Hope To See You All There,

– 0Creds

Ludum Dare 27… Here I come!

I participated in Ludum Dare 26 and I had loads of fun although my game wasn’t too good.  I am looking forward to Ludum Dare 27 quite a lot and cant wait for it to begin.

Since LD26 I have been working on a couple more games and hopefully one now that will be a bit bigger than a weekend project, THi².

I feel now that after a year of canvas game development I have progressed quite a lot and I feel now that I can create a full game, not just a small canvas animation.

Ludum Dare, here I come!

P.S. There is no “LD #27” category yet.

EDIT

Moved to “LD #27” category