When the date comes, I dont know how but it left about 10h to complete the games when I hit the Ludum Dare contests xD

Well, this time I knew that I wanted to make a different game , it resulted into this

you can play here:
http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=10960

some explanations…
The game needs two people, I think it is important to play with other person from time to time, with this videogame I want to help people to get friends more near

I made this game with ShiVa 3D engine, one of the 14 best game engines out there right now…well, time for you to evaluate!

The Side Factor is a local 2 player turn based strategy game. It explores the idea of creating a strategy game with a minimal number of unit types, in this case only 1. The core mechanic is shooting through things.

What went right

1. Paper prototyping – We used a Chess board and some folded pieces of paper to iterate over the concept of shooting through things. Originally we played with a rule that you could capture enemy pieces by straddling it on both sides and shooting through it. That was abandoned in favour of gameplay where players never lost any pieces.
2. Audio design - One of the reasons why I entered the jam instead of the compo was to work with a fantastic audio designer, Gordon McGladdery. I spent a lot of time implementing it and adjusting the animations so it felt right.
3. Visual design & polish – Gameplay was completed on Sunday so I spent all of Monday polishing it. It’s one of the prettiest games I’ve made in a game jam. Below is a series of progress shots from the end of Saturday, Sunday, and Monday.

What went wrong

1. The Theme – Minimalism is not a great theme when you assemble a team ahead of time to create a highly polished game. Instead of focusing on aesthetic minimalism we tried to explore it through gameplay. When I created the instructions on the website I realized even though there was one unit type the rules weren’t that compact.
2. Playtesting – It’s really difficult to playtest a 2 player game by yourself and writing an AI was out of the question.
3. Publishing on Android – One of my goals was to release this on the Google Play store. It runs surprisingly well on my Nexus S but still needs some optimizations, buttons need to be bigger, and support for different aspect ratios. It’s still in the cards but a post jam version with playtesting and tweaks instead.

Play Now (Unity web – Mac/Win/Linux binaries too!)

It’s been a full year since my last LD…  ::sigh::  But it’s great to do it once again!

This time I made Runaway Money, a party game about being invisible and stealing money.  Sounds kinda fun, right?  Does it also sound kinda strange that a multiplayer game would use invisible players?  Yeah, me too.  I had to think a while to make sure it was possible.

As it turns out, it is and it’s pretty fun.  Give it a try with your friends!

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

So I know that this website is mostly for games and stuff but last night i decided to try and do some networking stuff. So i sat my butt down in front of Eclipse, coded for about 2 1/2  hours and finished a simple chat server and client and started having conversations with my self. If anyone is interested in the source code ill upload it for you. Basically i am hoping this will be like a stepping stone  to making multiplayer games   .

SCREENSHOT:

kix

What I did in 16h

I made my game for Ludum Dare #24 in less than a day. It caught me by surprise, I read the news that the contest had begun the second day and sat at my computer and started drawing textures for models, Run the Game Engine Shiva3D and then I composed a simple scenario and I remember that I was very clear about what I wanted to do, a kind of evolution of planets, something dark with a touch of Mario Galaxy

What went right

I built up the scene, get some free sounds modified and a simple music (atmosphere) and wrote the AI’s, behaviours and HUD scripts in the speed of light, but something bothered me and totally stucked me , a common math problem with free rotations in 3d axis.

What went wrong

The final hour arrived and I had to post the game with 2 bugs: camera and control, users started to test the game and all they said was good things but complied about the bugs, so I kept working on the game until I got a version with less bugs, without the gimbal lock in the control and a better camera, still to be improved…

What a lovely community

I was very surprised with so many comments, when I started to rate the games, I found there was lot of fun games, mine is more like a weird experience said some guy ,I love the touch of humor the users distillate here in the Ludum Dare, I was so used to getting bad reviews of my games in other networks, that this experience of have opinions of people with such passion and professionalism really left me overwhelmed and makes me think all this has a really good purpose to work and deploy a good game for the people, and I love to create new experiences, emotions and travels to other world, those kind of stuff, thank you !

The game evolves too

After reading and talking with other users I found that my game need a whole new point of view, so, one of them said me that it needed another player, I liked the idea and I turned the game into a multiplayer conquer for evolve experience in Space, dark matter is waiting!

Play and rate this game

So, for our first Ludum Dare ever me and Regus made The Joining, a centrally hosted 2D shooter MMO. Against all expectations, including my own, we made a relatively complete game by jam’s end. Unfortunately a 3-day-mmo is kind of like 5-minute-cake, a cool idea, worth doing to be able to say it’s doable, but the end result is infinitely less satisfying than what you’d get if you put the proper amount of time in. While running around pewpewing evil robots is fun, a lack of players and general aim and finetuning makes it only playable for 5-10 minutes before boredom sets in.

What went right

• We knew our tools. Despite the fact that XNA isn’t the best thing to use to get a lot of people to play your LD game, we decided to stick with what we knew in order to finish in time.
• Teaming up with Regus was extremely enjoyable, we’ve known each other going on I don’t know, a decade and a half now, but we’ve never made a game together. Working together was great, we had complimenting skillsets and we didn’t step on each others toes or had to wait for the other to finish to continue working.
• I’m mostly pleased with the pixel art I did. Pixel art is something I consider myself good at but I rarely get to do it anymore. Being able to do some again was very nice.
• The game is pretty well feature complete and stable. Our code design was mostly to thank for that, until the last day when cleanliness kind of went out the window and some of my rendering functions turned to spaghetti.
• We made an MMO, complete with combat, enemy AI, A* pathfinding and a neat sort of “level up” system. In three frickin’ days. How awesome is that? Worth it just to say we did it.
• I got to remind myself that even if your art and particle effects are only 50% as awesome as you want, it’s still a more satisfying experience to have a bunch of half-awesome stuff and a more complete experience, then an incomplete number of perfect things. The perfectionist in me needed this reminder.

What went wrong

• No music. I’m bad at music and didn’t have the tools or time to modify even an autotracker song. I subbed in ambient sounds instead and it works okay, but not the way I wanted.
• We didn’t actually have time to add some features that would’ve given the game a goal, like a boss at the center, better tuned distribution of enemies, and a global win/lose condition like we planned.
• The game wound up being not very fun. See my opening paragraph for thoughts about that.
• I felt kind of sick after the third day cause I pushed myself so hard and my sleeping patterns are completely shot now.

Overall a lot of things went right, far more than went wrong. Our first LD experience was enjoyable, and taught me some valuable lessons, or rather reminded me of them. And it was a chance to do a few things I don’t normally get to do, like make an MMO and work on pixel art. I consider it a win, even if I doubt our game will be getting top ratings.

We probably won’t work on the game for a post-compo version, I think. Nobody’s asked us to, which is a pretty good sign that it’s not actually wanted. Comment if you think we should, though. I’m tagging this SuccessStory even though the end result is lackluster, because… well, 3 day frickin’ MMO man.

Eniko, signing out.

I can’t believe it, we pulled it off. Against all expectations, we pulled it off. We failed to add the win and lose scenarios, but nonetheless we made a more or less fully fledged massively multiplayer online 2D shooter in 3 days! What is this I don’t even

I present to you: The Joining! Get the zipped build from the entry page or download the handy dandy setup which includes all the required frameworks. (XNA 4.0, .NET 4.0)

The story is that a race of monogendered aliens who join with each other to exchange genetic material have become complacent and reliant on AIs, and thus weak. Now the AIs have gone rogue and you have to once again join with your fellow alien type people to become stronger and defeat the AI overlord! (note: overlord not in game)

The game boasts procedurally generated terrain with buildings, a single central server everyone connects to, chat features, point and click movement and combat, and some pretty particles. No music, but I tried to compensate with ambient war sounds.

Now I have a dreadful headache so postmortems, time lapse and gameplay video will follow later. First LD, and we made it. I can’t even believe it. I’m so happy!

Kind of lame in between all the “finished!” posts, but our jam project is still in full swing. Current features:

• Randomly generated theoretically infinite terrain with houses that have door openings, shelves and tables.
• Being able to log on to the server and seeing other players move around, fully animated.
• Mouse based A* pathfinding mouse movement.
• Auto dirt to grass tile transitions.

Note the depressing lack of gameplay features. I’m pretty sure at this point we overshot and we’re not going to make it in time. Oh well, lesson learned if it’s so, I guess! Still the fact that we managed to get this much done in a server/client architecture in two days is impressive.

Now for an art dump.

And last but not least, today’s dinner:

So, last night me and Regus, after grumbling about the theme for 5 minutes since it fit none of our ideas brainstormed for an hour and a half and then decided to go to bed. Turns out neither of us slept all that well, ghee wiz whoda thunk! We at least bashed out an interesting idea, which implements some features of evolution and natural selection as gameplay mechanics.

Right now I’m nursing my morning (mid-day) cup of coffee trying to wake up and trying not to think of how much time sleeping took up. Then we’ll bang out design decisions and milestones, I think, and get cracking.

One thing I can already reveal; we’ll be going online. YEEEAAAAAHHHHH!

Hey guys,

So one day, I thought, “What could make this game better? What could make it more fun?” The simple answer, of course, was multiplayer. What’s more fun than playing a game with your friends? However, multiplayer in Unity is harder than you think. After several failed attempts, I watched a few simple tutorials, and finally came up with a working… thing. Not really even an alpha… Anyways here it is at it’s ugliest:

Since then, I’ve added tons of stuff, fixed over one HUNDRED glitches, and added a lot of simple features! (Such as Chat, Ragdolls, etc)

I’ll cover the latest update in a new video hopefully posted sometime this week. But for now, Update 1 is here. I hope to continue this update series like Overgrowth Alpha update series, so check back on DontBeNoobish and RobProductions channels for the fastest way to hear about them.

Happy Gaming, Ludum Dare <3

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.

Well the single player portion is going quite well,

When items are in, you will be able to use them to effect other player’s worlds. This might be something like: summoning a buffed enemy, siphoning their life, instantly spawning a few enemies, increasing their world level, etc.

This all depends on if I can get the network online before the deadline, I guess I won’t be sleeping tonight!

Try the early build here: http://dl.dropbox.com/u/13605298/index.html

I probably won’t use this next weekend, but I’m posting this just in case I do want to use it.
GNI is a library to facilitate some simple, easy to use communication between a server and any number of clients.
Please note that this was coded in a relatively short time span, it was not tested extensively, network code is vulnerable to tons of unpredictable bugs, and my experience with netplay development is limited.
What I want to say is, don’t rely on it unless you’re capable of fixing bugs in it, as it might break at the worst possible moment.
The example chat program I wrote seems to work perfectly, though, so it should work. ‘Should’ being the key word here.

Features
-Simple way to send signals from server to client and vice versa, without bothering with minor technical details
-Automatically calls a function when a signal is received, a player connects, or a player disconnects

Download
Code includes a simple chat server project and chat client project as examples.

DLL download link (5 KB)
Source download link with example (19 KB) (Microsoft Visual Studio 2010 solution)

How it works
Small packages of information called GNIDatas are sent through the library. When received, it’s reconstructed as a GNIData struct.
GNIData consists of a key-value pair, with the keys or values being shorts (16-byte integers), strings, or nothing.

Server
-The server class must inherit from the library’s GNIServer class.
-Call StartServer(…) to start the server. You can have it check for incoming signals automatically, or choose to do so manually by calling Update().
-Override OnDataReceived(GNIData data, uint source) to interpret signals. It’s called from Update when a full GNIData has been received. ‘Source’ is the clientID of the client that sent the signal.
-Override OnClientConnected(GNIClientInformation client) if you want something to happen when a player joins. (The client is automatically added to the client list.)
-Override OnClientDisconnected(GNIClientInformation client) if you want something to happen when a player disconnects. (The client is automatically removed from the client list.)
-Use SendSignal(…) to send a GNIData to a client, or BroadcastSignal(…) to send a GNIData to every client.
-Send empty signals (datatype and valuetype ‘none’) if you want the server to automatically detect if a connection has been lost; otherwise it won’t notice until it fails to send a signal to it.

Client
-The client class must inherit from the library’s GNIClient class.
-Call StartClient(…) to start the client. It WILL NOT check for incoming signals automatically; call AutoPoll() to have it do that. Alternatively, call Update() whenever you want to check for incoming signals.
-Override OnDataReceived(GNIData data, uint source) to interpret signals. It’s called from Update when a full GNIData has been received. ‘Source’ is always 0 and meaningless in the client.
-Use SendSignal(…) to send a GNIData to the server.
-To be honest, I’m not sure what happens when the client unexpectedly loses connection to the server. It’ll probably throw an exception, so just catch that.

Documentation
Does not exist. If you can’t figure out the code, it’s best not to use it as it might still be buggy.

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.

This time around, I think I’m going to take it easy on the graphics and sound. Instead, I’ll focus on pure story. My plan: a multiplayer, online puzzle game. I’ll be working in PHP, with a bit of JS front-end. Maybe some html and css as a template. I have some interesting ideas for something atmospheric, and connected to the theme Hope to start serving things up to outside users in short order!

2 weeks ago I presented my project for the October Challenge: selling the first copy of my “multiplayer game making tool” CraftStudio, by the end of the month.

CraftStudio is built in C# using XNA and Lidgren. The client runs on Windows only (for now!). The server runs on pretty much any platform with Mono support.

People have been building & painting some dragon models to try and see if the modeling tools are good enough to build a complex model. And to see if we could do better than Notch . Here’s one of them:

A dragon model by @schouillette

So, what have I been up to code-wise?

• Spent a lot of time improving model editing. There are now transform handles which allow editing models by dragging stuff around. I had to go through lots of matrix & projection stuff, but it was worth it .
• There’s now an integrated news system in the client. It pulls news from the master server (which itself gets them from a SQLite database).
• Lots of improvements to the UI framework: smooth scrolling, text layout performance improvements, splitters to allow resizing panes, etc. The whole framework is available on Codeplex under the MIT license. Feel free to use it for your own projects!
• Mostly importantly, I’ve been working on map editing support for the better part of the last two weeks, and I just made a new release available. See for yourself:

An alien space ship map

Since I’m now working full time as an indie, I’ve also started working on setting up a company, but it looks like it will take some more time.

I have looked at payment processing platforms too. I’d love to go with Stripe.com which has awesome developer support and, it seems, a great team behind it. Sadly they won’t be available in my country (France) by the end of the month. I could go with PayPal but I’ve read multiple indie horror stories with selling unfinished products (Minecraft and Project Zomboid, to name a couple). If anyone has advice on this, I’d love to hear it!

I’ve done some work on a multi-threaded server in C# for various things. I plan on using it for my game in the compo. Included in this link is the .exe and the xml options file. It’s fairly simple to use, and it uses TCP for communication. You can set which port it uses, a “greet” message, the interval in milliseconds at which it sends received data to all connected clients, the maximum number of clients, and the maximum message size (in bytes). It expects all communications in byte form. Here it is!

Infection Wars is a multiplayer game where you use an “infectatron” vehicle to bring a population of “protoplasmoid” objects over to your color. There is a (fairly dim) AI to play against, but it’s best if you’re playing splitscreen head-to-head with one or more humans. It supports up to 4 players (with multiple joysticks/gamepads, preferably, or keyboard, or mouse).

It was written using PyGame (no OpenGL), and was my first game development contest entry. For a while, I had been driving around with a license plate holder based on the game.

This came in 9th in both innovation and completeness. I’m still rather pleased at how this game turned out – it’s a pretty simple game with some easy-to-understand but unusual mechanics. A few more hours could be spent on the game to fix a few shortcomings, including the fact that sometimes the protoplasmoids get hung up on walls, and that the AI is regrettably (and nigh-unplayably) dim.