Posts Tagged ‘xna’
Gonna be in for this one… after missing the last two (sad face).
Using this LD to say goodbye to XNA, probably try and port it over to monogame once completed.
Also throw some paint.net, sfxr and FL Studio in the mix.
Using my 2D starter project, with basic gamestates and such, P32D.
Going to follow my traditional Ludum Dare plan of attack
- First Hour : Panic because I have no ideas for the theme
- Next 2 Hours : Start working on the game
- Next 43 Hours : Continue working on game
- Last 2 Hours : Finish working on the game
Gonna attempt to stream some of the dev time as well, if all goes smooth… don’t want to spend those precious minutes working out streaming problems…
First off this was the first Ludum Dare that my team and I have competed in. We decided to enter the 72 hour jam as a team so that we could create a more complete game than if we had entered the 48 hour compo. Initially we had a large team planned but a few people dropped out last minute which left us with 3: Myself and my friend Paul from University as the programmers, and our housemate Leela, who has never created any animations before or been involved in creating video games at all, as our artist and animator. So how did it go?
What Went Right
A lot went right to be honest. Like a few others we were expecting ‘End Of The World’ to win the theme vote. As such we’d started having a cheeky think about what we’d do if that came up the day before. ‘You Are The Villain’ took us by surprise a bit. We were a bit stumped for a bit but Paul came up with the main idea and we had decided on the sort of game and rough features we wanted after a few hours. I feel that the game fitted in with the theme quite well. We didn’t want to create the obvious you are a thief/bandit/zombie/vampire type of thing because we knew that many people would be going for that. As such Mother Nature as the villain was a little more left of field but we felt it was justified. After all she is trying to take down the entire human race in the game. Interestingly some of the criticisms we have had from the game is that people can’t see how Mother Nature is the villain and therefore how it fits in with the theme – If exterminating an entire species doesn’t make you a villain I don’t know what does
We got a lot of the features we wanted into the game. When we were first discussing the game we were talking about upgrades, different types of enemies, different landscapes and all sorts of different features. We were realistic about what we could achieve in 72 hours though and we managed to whittle this down to the core features, leaving other ideas as things we would add on if we had time (which we didn’t J) The game’s features are therefore fairly Spartan but they are the core mechanics and any other features would be built off of them. So we feel they enable the game to be played out as we had envisaged it.
Gameplay is one of the areas where we could have done a bit better. However I believe it is still enjoyable, if a bit short. We wanted to lock down our features on the Sunday So that we could focus on refining the gameplay and building levels on the Monday. Unfortunately it didn’t quite work out that way. We had a discussion on Monday morning about whether to hard code in our levels or to build a simple level editor to streamline the development. Paul was in favour of hard coding as he believed it would take too long to get a working level editor up and running AND then to create the levels. I believed I could knock up a level editor in a couple of hours and that it would save us time in the long run. I also thought that hardcoding would mean creating less interesting levels and more problems if we wanted to move things around after testing how it played. As it turned out it took me almost twice as long as I’d thought to create the level editor. Nevertheless by around 4pm we had a working level editor which could place our tiles and objects, set tile passability and so forth. It took Paul a short amount of time to create the level he had designed with it after that so I believe this is something that worked out well. I also believe that if we decide to enhance the game post-compo then this decision will pay off.
A few criticisms have been aimed at the need to invest early on or be swarmed by enemies in later levels. But this was a design choice. You can spam comets for the first couple of waves and get by but after that it becomes very hard to make it to the end. If you look at RTS’ such as AOE you will see a similar design pattern. You can build a barracks, spam the militiamen and send them over to the enemy. Whilst you might do damage initially you won’t do enough to finish the enemy off and they will be investing in their units. When they have better units they will destroy your militiamen then come and destroy you! Our game requires you to think a little and make an investment in the early waves to help you out in the later waves. Waiting and buying a volcano early on helps you out enormously!
I was particularly impressed with the artwork. As I’ve mentioned Leela had never made any sort of animations before or created graphics on the pc. On top of this she could only take part for about 2 days due to coursework commitments. So I was very impressed with what she produced for us in such a short space of time. The graphics fit in with what we had envisaged. They are bright with a good amount of contrast. The artwork she produced for the menus was my personal favourite.
The sound is something that only made it in at the last moment. I had created a simple sound manager on the first day but we didn’t have any sounds to really test it with until the last day. As it wasn’t central to gameplay it was left until the end as a less important feature. Nevertheless we all knew how important getting good sound into the game would be for setting the right mood and atmosphere. Once we had sourced some sound effects from online suddenly our comet impacts and lightning and so forth came to life. Our other housemate David, who couldn’t take part until the Monday night created the main theme and in-game music for us in a couple of hours and that really made the difference as well. Overall I am satisfied with how the sound turned out given the limited time we were able to spend on it.
What Went Wrong
Our biggest problem with the theme was that we didn’t realise that there was a bonus goat theme! All through the jam we were wondering why everyone was making games with goats in it but we’d just completely missed this extra aspect of the theme!
As I’ve said we would have liked to have added more features into the game. In particular a couple more weapons would have been good to have in. A hurricane/tornado was one we wanted to do but thought it would be a bit tricky on the art in the time we had so it was dropped. An upgrade system was something we really wanted to get in as well. This would have meant being able to upgrade the radius of attack for different weapons or their damage and so on as a trade for resources. We were hopeful that by limiting the number of weapons we had we could still keep the upgrade feature but it had to be dropped due to time constraints.
Whilst I like the gameplay it is also the area we are most disappointed with. Not so much in terms of how the weapons work and so on but more in terms of the levels themselves and this is all due to time constraints. The biggest issue is there is only one level with 5 waves. These waves are all too predictable. What I mean by that is that when the level starts all the humans spawn at a fixed time interval and all together. When we originally envisaged the game I wanted the waves to come down in groups. So rather than a continuous stream of people running to the spaceship you’d have little groups running together. I also wanted these groups to be separated a bit rather than all coming down at a fixed interval. Again this was all a case of running out of time. Another aspect that never really materialised was the points system. Although you earn points for kills this doesn’t actually mean anything to the game. We wanted to add in a highscore screen or something so that the points had a purpose but never had the time.
My biggest issue with the artwork was a lack of content. Again this is all about the limited time our artist had. We are missing animations in places which had to be replaced with static images instead. For example our volcanoes are static when idle when we really wanted them to be gently puffing out some smoke and ash. Our comets don’t animate when they fly just when they land. I don’t feel this has a huge effect on the gameplay but it would still have been good to have those animations in the game.
A lack of sound and music was the key problem although I think we managed to scrape in an acceptable amount at the end. Sound is a key component in games (amazingly I’ve played some ludum games without sound at all) which was demonstrated for us when we started putting the effects in the game. The game really came alive with the sound of comets exploding and volcanoes erupting and so on. There were other issues as well though. Some of the sound effects aren’t as loud as others, some go on too long or not long enough. When the music repeats in the menu it is not seamless as it should be. I would also have liked for you to only hear the sound effects emanating from the part of the game world you’re looking at, with all others either faded out
Most importantly though was the game ultimately fun to play? I believe that it is. One of our biggest criticisms was that the game does not last long enough which I will agree with. But that was a result of lack of time rather than design. I think that had we managed to create a few more levels the game would have entertained a bit more. Nevertheless I believe that it is still a fun game as it is. Whilst I have a few regrets over some of the features lacking in the game I am on the whole very pleased with how our game turned out. None of us had ever actually completed a full (largely bug-free) game before. The entry for our last game was riddled with bugs and almost unplayable. It left us very frustrated at the end with the time we had invested into it. But that was 2 years ago when we were starting out as programmers. This time I believe we have created a full game which is fun to play and looks and sounds good. It has also left me excited and looking forward to the next ludum dare. Can’t wait!
I had a blast with this Ludum Dare, mainly because my tools were in such good shape. All the work I had done on my libraries beforehand let me focus on content creation for the most part.
What went right:
Helper classes – I made a bunch of helpers before the compo to automagically handle sounds and particles and static objects in the map. Saved tons of time.
Update entities – Really saved the day. Allows you to change entity objects in the map without rebuilding.
Acoustic guitar for music. I couldn’t remember how to play, but just tried random stuff and fixed it all in audacity
What went wrong:
On map building I only had one major mistake, and that was losing an hour or two to leaks and map errors on the third level attempting to create a windy branchy maze by duplicating and rotating. Brush maps tend to break when you do that.
I also had a bug where a switchable light set to on wouldn’t be on if you built the map with update entities. I chased that one for awhile.
Sleeping in small chunks. Didn’t really work that well. I usually set the alarm for 4 hours, but only once was actually awakened by it. Usually I just woke up on my own and got back to work. I’d always awaken feeling refreshed, but I’d be tired again after just a few hours.
My “full build” button doesn’t actually save the final product. You have to “Save Zone” after. Several times I forgot, and couldn’t figure out what was wrong.
My alpha sorting broke! I was so mad. I spent a lot of time on that and even tested it in my warmup!
Story – I might have left too much unexplained. Is the apprentice the lover? Is the prisoner a man or a woman? What happens at the end? Also if the power is out, how did the first door and the elevator work? Also if you don’t hit the triggers in the right order it can tell you stuff you already figured out, or reference stuff you might not have seen if you missed picking something up or hitting a journal trigger.
Stuff I want for next time:
I’m planning on making a game specific entity class creation tool. This would allow you to specify what fields and default values an entity would have in a gui, then at the press of a button it would automagically edit quark’s entity file, and maybe even generate some C# code as well.
Pathfinding – I have some basic A* code but it isn’t integrated with anything.
Terrain integration, working on this in another project. BModel style mini bsps for landscape objects like rocks or ruin chunks, or full buildings with portals that look out and in.
Doom3 style gui screen surfaces. These would be great for making interesting puzzles.
So I managed to finish my super-simple game about a contract killer in a timely manner.
Here is the link for my entry: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=8403
The game was almost done yesterday, so I had a whole day to just polish it. Aiming really low payed off for me nicely. I just hope it won’t get too bad ratings due to its simplicity.
Unfortunately I still couldn’t make music for the game, I have to practice it before the next compo.
Here are some screenshots:
I see there a lot of games submitted already, I can’t wait to try them out!
And for those of you who are still working hard: Don’t give up! You can do a lot in 2 hours!
So the first day is over and I think I’ve made enough progress to be able to finish tomorrow.
This time I wanted to aim really low, because in the past I felt overwhelmed with the complexity of my game ideas and I wasn’t able to completely implement them in time. I’m also trying to improve my graphics skills, so it was better to have a game with the least amount of code possible.
I didn’t want to make a game with a stereotypical villain (aiming for world domination, commanding an army of minions, kidnapping people, etc.), instead I made the player have a villainous occupation – as a contract killer.
At the beginning of each level you get a picture of your target(s) – early in the game you only have one per stage, later you will have more. You have to memorize the targets’ appearance, find them in a crowd of people, then kill them with your rifle.
Once you fire your first shot the police will make their way to the scene as indicated by the progress bar at the top of the screen. You have to finish the job before they get there, otherwise it’s game over. The game is endless, each stage will have a bigger crowd, and you’ll have more targets to hunt down.
The code is almost complete, but I will still have to make sound effects, music, backgrounds, title and game over screens, etc.
Anyway, I wish you luck with your games, as I can’t wait to play them. There have already been some really cool looking games presented here.
So this is my first attempt at Ludum Dare… so far it seems to be going okay!
I woke up incredibly late after a night of no sleep. Then I crawled out of bed and started brainstorming ideas until inspiration struck in the form of a Mitchell and Webb comedy sketch. So the overall idea for the game is that you are pitching your genius plans to a board of investors and have to ‘deal’ with people as fear and doubt gets the better of them.
By about 2pm I’d managed to wrestle with my C# classes and get my XNA game working in the most pre-alpha sense:
I’ve since then started improving how the game looks and works, I’m going to add more traps and things and put in an end-game mechanic soon… but I’m gonna take a break for a few as I’m feeling pretty knackered. Here is a video of it as it is right now – the people start to panic more when the people around them start dying.
Heck… even if the game isn’t done for the competition submission… I’m still enjoying making it.
I don’t have much time this weekend but I’ll try to find a few hours to make simple-simple game. This would be my 4th LD if I remember correctly.
Tools are almost the same:
And here’s my workspace. As you can see, I’m currently away from home (“studying” engineering
Good luck to you all and of course – have fun!
I might get a late start since I have some stuff to tie-up for my actual main project, which is bringing the board game Hive to Xbox. Been working on that for 14 months and it should be released ANY FLIPPING DAY! We’ll see.
Will be streaming here most of the time: http://www.twitch.tv/bluelinegames
Languages: Either HTML5 or C#/XNA. Kinda depends on what comes to mind, based on the theme.
IDE: Visual Studio Express (if C#), or Notepad++ (if HTML5).
I’ll probably do the Jam instead of the contest if we find collaborators at The MADE.
This will be my 3rd shot at the 48 hour compo.
My only goal is to be able to make a better game than I did the last 2 times.
Tools I will be using:
- XNA with C# in Visual Studio 2010
- Paint for basic pixel art, Paint.NET for more advanced raster graphics, Inkscape if I decide to use vector graphics
- Bfxr for sound effects
- Renoise for music if I have the time (I never do)
This time I decided against using a base code, I’ll build everything from the ground up. I hope it works out alright.
Anyway, I wish you all the very best with your game making endeavors and I hope we won’t be wiped out in the looming apocalypse, so we can do this again next year.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
- 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.
- 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.