If you haven’t had chance to play my game from last LD Compo 24, I have finally managed to find some time to record and upload a video. Game is called “Aeon” – evolved classical snake game.

Ludum Dare 24 – Aeon gameplay

I “finished” my entry, as in I don’t know how to make it any better without rewriting it from scratch. :-/

I was focusing on making the game resembling real-life genetics, and I forgot to make it actually fun to play. I wanted it to be about survival and adapting in a harsh environment, but I couldn’t make it work, so I just added a bunch of random enemies to shoot. It became completely repetitive and the genes aren’t affecting the game as much as they should.

Next time I should simply focus on making the game fun, without worrying about the theme so much.

On the flip side, I think my drawing skills improved a bit. In the past I preferred to use vector graphics, but in this game I was using smaller sprites, so I thought pixeling them made more sense. It was a risky decision, because I never really used pixel art in the past, but I’m happy with the results. See for yourself:

Also, I never worked on a code base before that included classes like Allele, and methods like Breed.

Here is my entry: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=8403

Yes! Finally cleaned the house and I am ready to start programming.
Downloaded the XNA Platformer 4.0 base from http://xbox.create.msdn.com/en-US/education/catalog/sample/platformer
Also, got the level editor from https://bitbucket.org/FinalMirage/xna-platformer-level-editor/wiki/Home

Thanks a lot for these valuable things. I can now concentrate on doing my own thing and getting things to roll on!

Ok now, go ahead and admit it — who created 1543 fake accounts and upvoted Evolution?

(╯°□°）╯ ︵  uoıʇnןoʌǝ

But on a serious note. As a late time-zone starter and unhealthy oversleeper, I’m 3 hours in now. After (obviously) dumping my first idea, I’m going take the evolution concept to a more controlled, fabricated fashion (read: I can only draw rectangular shapes).

I wonder what will go into the pipes?

P.S. I didn’t know if I was going to participate in this LD and I skipped the last one (tsk tsk tsk). So I guess this is my “I’m in” post. I’ve previously submitted one 48h entry (Soulscape) and one collaborated Jam entry (Braille). I’m aiming at the main compo this time, but we’ll see.

I decided to make a roguelike game, with randomly generated content (levels, items, monsters). With each level, your opponents will try to evolve in such a way to put more and more of a challenge for the player. They will adapt to the experience level of the player, his strength, speed, gear, etc..

So far I barely finished level generator, but I’m not happy with it. I propably write it again from scratch, but only if I don’t run out of time.

Next thing on my TODO list : Player mechanics. But first, time for breakfast.

I’d been meaning to write this a lot earlier, but I’ve been way too busy to do it until today. Anyways, I made an online persistent world game in 48 hours. I wonder if it’s been done before during LD? We really need a tag system for games or something, it’d be interesting to be able to look up games with
specific elements. This post will be a bit of a combination of a making-of and a post-mortem; I’ll explain how this game came to be and comment on it.

Before Ludum Dare
This was my second Ludum Dare, so I had a decent idea of what to expect. Last time I used Unity, which had both its advantages and disadvantages. But since I’m the kind of person who wants to be able to customize everything and doesn’t want unnecessary things forced into his game, I prefer not to work with Unity. Fortunately, since February I’ve been doing an internship where I’m working on an XNA game, so I got pretty familiar with it. In making that game, I wrote a simple sprite engine which turned out to be very useful, so a week or so before LD23, I took the engine, removed some game-specific functions, added a tiny bit of documentation and released it as VBXSE. A short while ago I’d also been working on a simple netplay engine named GNI in my free time, so I decided to release that as well.

The original idea
After waking up at around 9-10 AM (competition started at 3 AM for me, but sleep is very important if you’re doing a 48-hour solo project), I checked the site to find out the theme was unexpectedly ‘Tiny World’, a theme I hadn’t even considered a possible winner in the poll. After thinking about it, I decided to make a roguelike-ish survival game similar to UnReal World where you and a couple of NPCs were stuck on a tiny island and had to get food and shelter to survive. That’s right, the original concept was nothing like what the game eventually became. I wrote down the basic game design in a text file, if you want details. So, I started working on the survival roguelike…

World and Graphics
Since roguelikes tend to be played in console windows, I decided to keep the area size small enough to fit in one. After some thinking, I decided square areas would make the most sense considering you also need room for other game information, and I ended up at a 22×22 world with each tile having 22×22 subtiles.

After a rough interface sketch, some calculations and some guesswork I decided the tiles would graphically fit best at a 32×32 size. However, I’m terrible at drawing stuff, so I decided to turn ‘lack of skill’ into ‘style’ and went for a pixel art look; I drew every tile and item in 8×8 and then resized it to 32×32 to make it look ‘retro’.

I made all of the art in GIMP because the Paint that comes with Windows 7 tries to be too hard to be a real drawing program and in doing so actually becomes worse for making pixel art…and it still doesn’t have any transparency. Brushes were surprisingly actually very useful when making tiles like grass, sand and sea. Just keep using random brushes and you have good-looking grass. Definitely something I should use more often.

Sound and music
The music for the game was made in FL Studio 9 using only soundfonts from DSK Music‘s HQ Instruments set. Although the effect is very subtle, the game actually contains dynamic music; although throughout the entire game the same track keeps playing, there’s three slightly different versions of them. They play simultaneously, and the volume adjusts depending on where you are.

Normal track
Forest track
Beach track
FLP (FL Studio Project) file

The music used the ‘Celtic Harp’, ‘Ney Flute’, ‘Percussion 1′, ‘Oboe’ (forest only) and ‘Harp’ (beach only) soundfonts. It was inspired by Paavo “Tarantula” Harkonen’s soundtrack for obscure MMORPG Dransik (now a shadow of its former self and named ‘Ashen Empires’) and a random street performer playing on a harp the day before LD23.

The sound was created by rubbing or hitting various objects around my desk against eachother in different ways, recorded with my laptop microphone and edited in Audacity (amplitude change, pitch change and echo). Like the music, it was mainly inspired by obscure MMORPG Dransik, where you would hear a simple but satisfying sound whenever you did things like cutting trees and mining.

But how did it become a persistent world game?
Development started out well. I started by making simple ‘world generation’ (filling the entire world with grass tiles). Then I made movement work, then proceeded to add sea and forests to world generation. I added the axe and item usage, so you could chop wood. Then I also needed support for dropping and picking up items, which also required a menu to let you choose between items. I also made sure you could save and load your world, so I made functions to serialize the entire world to a long string and load it again.

At that point, day 1 was already over (LD goes from Saturday 3 AM to Monday 3 AM here, so it’s 2 days instead of 3 as it is in some time zones), and there was no sign of crafting, construction, the hunger system, NPCs, wildlife, fishing and similar methods of food gathering, liquids, an age system, building recognition or pretty much anything beyond the very basics of the game. Whoops. So, what is the logical thing to do when your plans seem way to ambitious?

I went with the logical solution: I changed my game into a complete persistent world building game. Of course it’s a ridiculous decision to take halfway through development, and even more so when your project is in that state due to being way too ambitious, but all things considered, it ended up being not as unreasonable as it sounds. I had recently created a netplay library, and though network communication is always tricky and it was not tested much, it did seem to work perfectly from the small amount of testing it did get. As a game design decision it was more logical than anything; I was just a tiny bit of code away from making a game where you can build stuff, and games like Minecraft, Terraria, Active Worlds, a whole slew of BYOND building games and many more games have pointed out that just building things for other players to see can actually be fun in itself. Add to all that that I could already serialize any part of the world to a string, and the decision was made overnight to go all-or-nothing for an online persistent world game.

The first thing I did on the second day was finish the crafting and building system (otherwise even having a persistent world would be futile). Then I used my GNI library to write a server program and a client class. The client would ask the server for the serialized string representing the world map, and then for the serialized strings of each of the areas in the tiles (each tile on the 22×22 world map contains an inner area consisting of 22×22 ‘subtiles’, if you haven’t played the game). I found out the serialization had some errors, but after some bugfixing, it actually worked perfectly. Then, to make client changes affect the server and have the server keep the client up to date, instead of at the start the server would send the client the inner areas only whenever he zoomed in or walked to a different inner area, and the client would serialize the entire inner area and send it to the server whenever a tree was cut, an item was dropped or picked up and whenever something was built. It’s an inefficient approach (the reason it lags whenever you switch between areas or do something area-affecting), but it worked great for a 48-hour game. I then proceeded to add functionality for chat, player names, seeing each other, et cetera.

After the netplay features worked, I decided to add what little extra content I could still safely push in (mountains, stone, and anything that requires stone – yes, originally there was only wood) and release it.

What I like about the game
-It’s a persistent world game. That by itself is awesome.
-It’s my first succesful attempt at a non-BYOND online game. There was one other finished game were I attempted netplay, but its netplay was a horribly buggy mess that desynced for any players that were more than 2 meters apart.
-The world generation is nice. I’ve barely done any random world generation before, so the fact that I managed to get a properly shaped island with properly shaped beach and mountain areas out of it is pretty nice.

What I dislike about the game
-Lack of content. And I mean utter lack of content. There’s two kinds of walls to build, two kinds of floor plus four natural floor tiles, one tool to make and one decorative item. Ludum Dare games aren’t known for their extreme length, but it’s very minimal here; it’s a building game, but there’s hardly any variation in what you can build, so you get bored very easily. This is especially disappointing after my previous LD game, which could be played for significant lengths of time and still be interesting.
-It’s buggy and laggy. Whenever you zoom in, lag. Whenever you build something, lag. Whenever you cut a tree, lag. Whenever you move from one area to another, lag. And those 4 natural tiles I mentioned at the previous point? Good luck getting three of those without relogging a minute later, as they mess up something in the graphics (still not sure what causes it).

Things I should do again next LD
-Use VBXSE and GNI again. Especially the latter came as a surprise in how powerful it can be in just a small amount of development time. I was afraid of netplay functionality before considering the debugging hell it can cause, but now I think I’ll just plan for netplay from the start of the theme allows it.
-Use pixel art. I can’t draw, but ‘style’ turns out to work as a pretty good excuse to hide my lack of skill.
-Record random objects using my laptop microphone and edit them in Audacity for quick sound effects. I’m pretty satisfied with how they turned out; they subtly add a lot.
-Be overly amibitious. Partly because I’m just an idiot, but also because going beyond what you know you can do allows you to learn new things. It would be better for the game if I didn’t, but in the long run this is very useful.

Things to keep in mind for next LD
-I should make sure there’s enough content. LD is for games, not for tech demos.
-I should try to get the day after LD off work. Starting a week with a serious lack of sleep hurts your productivity for the entire week.
-I should update and improve VBXSE and especially GNI. They’re awesome, and therefore they must become even more awesome.
-I should make sure I’m used to the the tools and libraries I’m working with. I thought I knew XNA, but it wasn’t until halfway through the project that I realized I didn’t know even how to play multiple music tracks at the same time and change their volume. I also wasted a lot of time debugging an issue that happened because I didn’t take into account that using auto-poll GNI’s client class handles received data in a different thread.

Beyond here
I was initially considering updating the game a bit, adding some extra content and fixing some things I didn’t like, but there are so many things I’d like to change and so many things that need to be changed to make the game actually fun that it’d just take too much time. I think it would be interesting to one day make a complete game based on this, but that’s the kind of plan that will either never see the light of day at all or won’t be used until years later.

By the way, I forgot to do it initially, but I’ve slapped a Creative Commons license on the game so you have the right to mess with it in any way you want. Well then, see you all next LD!

Appendix A: Tools/libraries/etc used
C#: The language the game is written in.
XNA: Engine used for the game.
Microsoft Visual Studio 2010: The IDE I’ve used to make the game in.
VBXSE: XNA Sprite engine, used for all graphics stuff.
GNI: Netplay library, used for client-server communication
FL Studio 9: Used to make the music. I’m a fervent supporter of pattern blocks, even as Image-Line gets rid of its unique features.
DSK Music’s HQ Instruments: Set of amazing soundfonts I use for music. The music for this game was made solely using DSK HQ Instruments, using default FL Studio VSTs as effects.
Audacity: Pretty much the best audio editor around. Used for sound effects.

Appendix B: Network signals
If you’re interested in how exactly the server and client communicate, these signals are sent back and forth. Each signal has a ‘key’ denoting what the signal is about, and a ‘value’ containing other info.

Server to client
(None) – A signal with no information to check if the client is still connected.
identify – Asks the player for his appearance and location, in case some other players requests it later.
goplay – After version check and sending the necessary maps. Tells the client the player can start playing.
gspfinish – Indicates the server is finished sending inner tiles and the client can enter the subterrain the player was about to enter.
message – A chat or system message. Output the value to the displayed messages.
people – A list with the unique player numbers of all players that are currently online. If a known ID is missing, that means a player has disconnected. If there’s an unknown ID, the client sends a ‘who’ signal to ask for information on the new player.
person – Information on a player (ID, appearance, location) as a response to the ‘who’ signal. The client will then add the player to the list of known IDs.
pos|X – Where X is the unique player number of a different player. Tells the client where the specified player is right now.
subter|X|Y – Where X and Y are integers representing coordinates. Replace the inner tile at X,Y with the serialized inner tile in the value string.
subteru|X|Y – Same as above, but the change is vital, so if the player is in the area, it MUST update the inner area before letting the player continue doing whatever he’s doing.
versioncheck – Asks the client to send his version number, to make sure he isn’t using an outdated client.
versionmismatch – Tells the client he can’t play on the server because the versions don’t match. Which version the server is running is in the value.
where – Requests the client to send a ‘here’ signal, telling the server where the player is.
worldmap – Sends a serialized world map as the value. Allows the client to build the same world map client-side as the one that exists server-side.

Client to server
The server automatically sends these signals without the client saying anything to it:
Every 2 seconds – where – Ask for the player’s current location.
Every 2 seconds – pos – Tells the player where other players are.
Whenever a client connects – versioncheck – Asks the player for his client version.

The server can receive the following messages:
cmsg – Client wants to send a chat message.
getsubplus – Value contains X and Y coordinate. Client asks server for the inner area at (X,Y) as well as the 8 areas around it. Server sends them followed by a ‘gspfinish’.
here – Client tells the server where the player is.
ident – Client tells server information about the player (appearance and location). Server stores the information and sends ‘worldmap’ and ‘goplay’ signals to let the player start.
nick – Sets the player’s nickname.
usub|X|Y – Client tells server they updated the inner tile at (X, Y). Server updates world and sends a ‘subteru’ signal to all players.
version – Client tells server what version they’re using. If it matches, the server will return an ‘identify’ signal, otherwise it will return a ‘versionmismatch’ signal.
who – Client asks server for information on a player. Server sends a ‘person’ signal in response.

Mage duel is a game about playing with yourself.

Play it here.

This was my second Ludum Dare.  My last Ludum Darewas a 48 hour stress-fest.  Although I had a blast and created a pretty cool little game out of it, and given the fact that I have a lot of other stuff going on right now, I really wanted this one to be more of a relaxing experience.  Before I started, I took some inventory of my last experience to see what I could do this round to make things a little easier on me.  First big thing that stuck out was scope.  Voxterium was a simple game, but had a lot of hidden elements that greatly complicated it.  Another big issue was experience.  That first time, I really had no idea what I was doing time-wise… no real idea how long anything would take.

With the knowledge that I could spit out a menu system and add music and sound in a fairly small amount of time, and I could cut down on rendering time (a big chunk of the first one) significantly by going 2d, I decided to go with a simple 2D game, with some simple basic mechanics, and use the remaining time to add in a few cool tiddlibits.

The Concept

I had messed with the concept of “recording” playthroughs and playing them back as opponents a few years back for a completely unrelated game.  I had that idea, plus a few others on my mind before the competition began.  I had a rough idea of how to apply that to most of the themes on the final list, but didn’t want to get too invested in planning on any one theme, as I made that mistake the last time.  When the theme was announced, I was instantly drawn to the idea of an artillery game on a small map, an artillery game is one of those where the “playback” mechanic would actually work out well.

The Build

Overall, it went really smoothly.  A few snags along the way, one involving a nasty gravity bug and another with particles, but all in all I had more than enough time.  The map generation worked out well and was simple.  The mage firing mechanics and collision were easy to implement.  Art was simple.  The playback mechanic turned out to be really easy to implement.

Then I changed my mind.   Originally, the game was turn based like Scorched Earth.  (Sorry to all the kids in the room for the “Scorched Earth” references, maybe put in “Worms” where you see that title.  I never played Worms, but it looks similar ).   So, blue mage would fire, bullets would fly, collisions would occur, gravity processed, Red mage’s turn.   It was true to the genre, and really easy for the playback mechanic.  But it was slow, and really didn’t hit the actiony feel that the game was telling me it needed.  I then decided to switch everything to real time.  Was a little worried at first, but turned out to not be so bad, and I really think it added a lot.

The Polish

Two mages were fighting… why?   Mages just seem like the types to disagree a lot and get into long and boring discussions, so I came up with the idea that these fights were over a way for these mages to settle these little disagreements.  I added a list of little petty things that they could disagree over.  Wish I could have come up with more and better, but you know… the whole time thing…

Menu system, sound and music is now pretty much second nature for me,  and so many nifty tools are available, that that part was  cinch.  Spent some time balancing, but not nearly enough.  It could have used a lot more, but I believe it checks the ‘acceptable’ box.

What went wrong

Early refactoring of my terrain generation code introduced a bug that made tiles fall through the bottom of the map.  Seemed simple enough, but was a real pain to find and kill.  Wasted a good hour on that one.  An hour that I could have been better used somewhere else.

I made the mistake of assuming rendering 2D in XNA would be a lot like an easier 3D render.  It’s not.  Should have done some additive blended particle practice before this all started.   A 48 hour deadline is not the best time to learn something new.  Eventually, using multiple render targets, I was able to get a result that was close to what I wanted… but in the end, it was not what I wanted and it took up waaaaay to much time.

I was hoping to work out a way to introduce the “play yourself” mechanic organically in the game.  I could have used the time wasted above to actually do that.  I considered leaving as it is was and not pasting warnings over the place.  However, since most people spend like what?  30 seconds with each game, I figured players not getting to the core concept was more damaging than players feeling that I gave them a “spoiler”.

Wish I could have spent a lot more time balancing the spells.

What went right

You never have enough time to do everything you want, so even with the hiccups above I believe my time management was great.  Although I didn’t get to everything I wanted.. I got to everything I needed.

The “play against yourself” mechanic turned out way better than I expected.   It blends in well I believe, and builds in a natural difficulty curve.   As you get better, it gets harder.

The art and sound are great (For me).  I’m particularly pleased with the spell icons.

I liked the way the terrain generator turned out.  Not all matches are great, but you always have the option of blasting it away.

Conclusion

Another great Ludum Dare.  Many thanks go to everyone involved.  I really can’t think of a better way to spend the weekend.  I’m very pleased with the way the game turned out, and left the weekend knowing a little more than when I started.

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7470

Day 1 Time Lapse:

Day 2 Time Lapse:

After 72 hours of development (including skipping school Monday), I have finally finished by Jam entry.  You can play and rate it here.  Overall, I am very pleased with how this LD went down.  I wasn’t expecting Tiny World as the theme, so when I was looking down the theme list I neglected to pre-think of a game idea – but it didn’t really matter.  My brother, who also did the game’s soundtrack (download link on game page) helped me do a lot of brainstorming to get a good idea, think up pun-ny names for the abilities, narrow down the feature list and expand it again, and in general was a fantastic second opinion on making game design choices.  I am proud of how the game turned out.

I’ve learned a couple things:

-Happiness is intrinsic to success.  Last LD I gave up on the last day of the Jam because I was depressed and couldn’t handle the constant solitude and sitting involved with a 72-hour game jam.  I was going to do the 48-hour Compo this time for that very reason, but I went back to doing the Jam because I wanted to include my brother’s music.  Everything ended up better than last time: since he was hanging out in the office I had occupied, I wasn’t so lonely (ironic considering LD22 was Alone).  I also was oddly optimistic Saturday and Sunday.  It’s important to be happy and make a game that makes you happy – I’ve seen a lot of people now give up because they didn’t like their entry.

-The small changes make the big differences.  The difference between the finished-looking product I have now and the clearly-in-development game I had two days ago isn’t much about the features I added – it’s more about the small graphical niceties.  For instance, the background: it was just blue, but then I made an image filled with blue-ish noise.  I let you know when the camera was scrolling and, as a bonus, looked kind of like a microscope.  That similarity led Lectvs to comment that it looked thus, which gave me the idea to add the scope graphic – something that made it look even more like a microscope.  The great Notch once said the difference between a prototype and a finished game is about ten thousand particles, and that was true of this game too – particles added to the aesthetic quality.  Similarly for the change from armor being a tint to a shield-like graphic.  Small things like that, or sweeping menu transitions, make a game look professional.

-Microsoft XNA deployment is unnecessarily complicated.  I mean, seriously, Microsoft?  There’s so much stuff to customize and fit into big-budget company things where they know what they’re doing, but there’s no simple “Make a .exe out of this, kthx” button.  I hope my installer/standalone thing covers all the bases.

-It’s really easy to make something that isn’t a platformer. I went with a top-down game not only because it was what the game idea entailed, but also because there’s no collision engine.  It’s really easy to do stuff without having to worry about what happens when it hits something.  The closest I have to collision is things running a query for the closest bacterium to a position – nothing really complicated.

Short description from game page - You are a bacterium struggling to survive, thrive, and evolve. Attack other bacteria with a variety of weapons, get a variety of upgrades and buffs, and for goodness’ sake watch out for bacteriophages.

There are 2 references to kittens.  Can you find them?

Had a great time making “Ant Slayer”, the shrunken exterminator game, finishing about thirty minutes before the deadline with a critical bug fix in the extra hour they gave us.  Here’s my timelapse:

What Worked:

• Cutting Risks – I experimented with particles and toon-shading, and ended up nixing both with only 30ish minutes lost.  This turned out to be a great decision.  I’ve written both in the past but I try not to look at old code during the compo.
• Familiar Toolset – XNA and my base code libs are what I use most these days so the familiarity meant I could just spew code like a fire-hose and have it come out decent.
• EZMuze – An xbox indie game (though not really a game) that lets you throw together great sounding music in a hurry.  I ran a mini stereo from an optical decoder over to my computer and recorded with audacity.  I literally made those 3 songs in the 2 or 3 minute chunks of time I was waiting for my levels to light.
• TimeLapse – It was my first time doing a timelapse, and I find it super valuable for reflection on the weekend.  Being tired and under the gun, so much of it is forgotten.
• Prep Work – I took several hours before the compo to do a test app, secure a way to do music, stockpile food and tea, practice making a skybox, and work out relative sizes of things.  My game I work on daily uses meters as the base unit, and my ludum libraries use inches, so I wanted to make sure the sizes came out ok.

What Didn’t:

• Bug Chasing – I blew hours chasing a problem with dynamic lighting which ended up being a very simple logic error.  Pix (the xna shader debugger) wasn’t helping matters as it crashes on load for this game for some reason.
• Wheel Re-inventing – I spent a lot of time on basic code that I have to write for every game I make.  Audio stuff comes to mind but also game state and basic menu stuff took hours.  I should have that stuff in library form so I can focus on the gameplay.
• Virtual Machine – I decided to put my art tools in a virtual machine.  I’ve recently reinstalled and have been trying to keep my development machine clean.  This worked for awhile, but as the maps got bigger it became too slow to be practical.  So I lost some time reinstalling some art tools on my main machine.
• Theme Paralysis – In this and the last time around, I failed horribly.  Ordinarily, as with any game designer or even game player, if you utter a single word of english I can come up with a dozen game ideas around it.  This and last time I was completely stumped and had no idea what to work on.  I just started creating and hoped I would think of something.  Eventually I forgot the theme entirely and just started making fps stuff.  Having slept and had a day to reflect I really regret this.  I’m not sure how many of you saw Chris Hecker’s GDC talk about “An appetite for sameness”, but it really struck a chord with me, and yet here I am, making yet another fps.  It’s more painful when you consider the context of the event, a festival of creativity.

Main Menu of Tiny Card World

I am really glad that I finished my first entry within time! It was totally worth it and the feeling is indescribable. I can’t wait to try out all these games!

If you want to know whats the outcome of 30+ hours and too much caffeine check it out:

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=12344

My first Ludum Dare Compo submission.

Had problems with creativity, so ended up something being shoehorned into the theme.

Link to game: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=12927

Seeing as I actually have a level loaded in my game, I thought it might be a nice to update the blog with a screenshot. Finished tiles in Pickle, created a quick test level using Tiled, and then spent several hours swearing at Visual Studio whilst integrating TiledLib. There was nothing wrong with the library, but I decided to rearrange all of my code to access parts of code from other places. I went from GameComponents to a traditional singleton pattern, and now a interface / services system. Got there in the end (hopefully), and after all that fuss, it only took 4 lines of code to import and render my test map <3

I guess I should get working on some gameplay now… there needs to be some kind of character in here. Unless you just want to stare at a crap background?

…not that I’d really call it a framework – it’s a basic 2D graphics class, and that’s about it. I wanted to refresh my 2D knowledge, and I’ve still got a lot of code to do before even starting on the game design this weekend, but I might as well submit what I’ve done so I don’t have to write it again. There’s some basic graphics for an idea I had, but I’m not going to be using any of that for my Ludum Dare project.

http://dl.dropbox.com/u/459339/XNA_EngineTest.rar

Feel free to pick it apart and comment on it, and any advice regarding how to structure a full XNA (or any) game would be appreciated. I’ll admit, I’m scared about the next 72 hours, but it should one hell of a journey.

Since I didn’t want to rewrite a whole bunch of code next weekend, I decided to tidy up and release this bunch of code.
It’s some helpful code that allows for easy sprite handling in XNA 4.0.

Features
-Easy sprite creation (just CreateSprite(name, position) and it’ll automatically render it from that point on)
-Changing position, scaling, rotation is also easy
-Depth system where deeper sprites are always rendered behind less deep sprites
-Automatically loads the Content/Graphics folder for you so you can just refer to the images by name
-Basic layered sprite support (multiple sprites combining to make one sprite, for example a base body with armor and a weapon overlaid on it)
-Basic animation support
-Licensed under Creative Commons Attribution 3.0 Unported, so you’re free to modify it or use it commercially

Code includes a simple example project.

DLL download link (MediaFire, 7.43 KB)
Source download link with example (MediaFire, 92.74 KB) (Microsoft Visual Studio 2010 solution)

Basic documentation

How it works
-Create a folder ‘Graphics’ with at least 1 image in it in your Content folder. The folder or any of its subfolders must not contain any non-graphic files.
-Put a SpriteFont in your Content folder with the name ‘Default’. It will be used as font for GTexts and the log.
-Call SpriteEngine.Initialize in the constructor of your XNA game class (note that it MUST be in the constructor, NOT in Game.Initialize()), after setting Content.RootDirectory.
-Call SpriteEngine.LoadContent in the LoadContent method of your XNA game class.
-That’s all the initialization it needs. Call SpriteEngine.Draw in your Draw method to actually have it do something. Note that it does not clear the screen for you; keep GraphicsDevice.Clear in there.
-If you want to use animations or ‘camera scrolling’, call SpriteEngine.Update in your Update method.
-From now on you can use SpriteEngine.CreateSprite to create sprites in your game. It returns a sprite object, which you can use to change its position, rotation, image, etc. Use SpriteEngine.EraseGObject to erase a sprite, or SpriteEngine.Nuke to erase everything.

Classes
SpriteEngine – Main class. Most of the functions you need will be in here.
GObject – Base class for displayable objects (Sprites and GTexts). Contains basic information like position, scale and depth.
GText – A displayed string that can be moved around and has a depth, much like a sprite.
Sprite – Class representing a sprite, containing basic information such as its position, images, rotation, scale, etc.
LayeredSprite – A sprite composed of multiple sprites. Uses a simple layer system where when the sprite is drawn, all of its sub-sprites are drawn at its location instead.

Details on what each property and method does can be found in comments in the code, I’m too lazy to type them all out.

License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
You are free:
* to Share — to copy, distribute and transmit the work
* to Remix — to adapt the work
* to make commercial use of the work
Under the following conditions:
* Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Have fun, and good luck with your games.

I’ve quickly hacked in a Fireworks show at the end of my game as my nod to the New Year’s Eve celebrations.

Trust me, it looks better in motion

[GAME LINK]

Finally got my timelapse up for Voxterium

Found out I’m not good with video editing software.  Just another thing I’ve learned from this compo…

I would like to start a list of Entires into the Comp/Jam that use the XNA framework:

I have only checked the first fifty odd on of my list, please add a link to your submission to the comments and I’ll update this list daily!

Update: This list now has 62 entries, is mostly complete and has been sorted to allow easier navigation.

I have created this list in the hope that we XNA developers will be able to sample each others games and provide much needed and valuable feedback to each other.

Phil’s made a nice gameplay walkthrough video for our game Braille:

Here is our double timelapse for Braille: