Tell us a little about Wicked Dead.

Well, the game starts where life ends.

You are dead – and instead of going to heaven or hell, you’ve gone to a place called Wicked Dead. You are Wicked Dead! Here, you get a chance for a new life. You need to enter the gates and complete
objectives and battles. For every level you complete, a new one will open – but if you fail a level,
you’re bumped back 2 levels. The goal of the game is to complete level 100 – then you are given a new life!

In the levels you will need to do wicked stuff. If you die you die very painfully, but get reborn
and can improve your stats. Yeah, you read that right – you can only improve your stats by dying! So
deciding whether to complete a level or die is sometimes a hard decision.

Energy is your life-force – you need energy to enter a gate and complete the objective. No energy means no fun. You regain energy over time though, so don’t worry. You also have a stat called ‘pain’ – when you die, your pain goes up. If you have a pain rate higher than 90 you will be unable to access a gate because you are so scared and have so much pain that you can’t do anything (so don’t die too much!). Pain goes away over time.

One thing to remember while playing Wicked Dead: not everything is what it seems! There are many tricks in place, and you will also meet other people in the gates.

What gave you the initial idea for Wicked Dead?

I was playing a game with some friends and we were losing badly. I was
dying all the time and I thought, why don’t they make a game where death is
rewarding? And then I started with an idea to make a game which rewards
dying. My first idea was that you needed to try losing, the one who dies first
wins. When I read about the competition I started working on that idea and
then Wicked Dead was born. I changed it a bit, you get better when dying
and you sometimes need to win and sometimes need to lose. Also, luck
is something you will need. And lastly, I like to fool with people so thats also integrated into the game.

What language did you write Wicked Dead in? What are you hosting it on?

I used PHP, along with XHTML and MySQL for the database. I have a lot of experience with them,
so it was a logical choice. I’m using the same shared hosting provider I use for all of my sites.

What was something that went well during the contest? What was something
that didn’t?

Well the first 2 weeks went well, there is really nothing that went bad in
terms of programming. Only thing that took some time was balancing out the
stats and items. But thats something I always invest a lot of time in.

The thing that went bad was time! During the last two weeks of the contest, I almost
didn’t get time to work on the game! I even forgot to upload my last changes
before the competition ended. But it was no big deal – the basic idea was in place,
and the update only added pvp and more levels.

Do you have any plans for Wicked Dead, going into the future?

At the moment I dont have much time to work on it, but I’m working on it.
In the future more levels will be added and also a Minion minigame with
aura stones. There are only a few and people will fight for it with their
minions. Upgrading their base and creating minions or towers. The next gate
levels will get more complex, more paths to follow, more choices and more
tricks to fool people. I’m planning to make 100 levels, but at the moment there are only 18 ready to go – so there’s still a lot to do. I’m not planning to advertise it yet in
the near future, maybe somewhere in the summer. I first want more levels
ready. The problem is that I can’t make them as fast as people can play
them. And after all, I’m making it for fun.

Have you played Wicked Dead yet? What did you think of it? Let us know in the comments!

Tennis Masters is planned to be an online tennis management game. The
game puts the players in charge of managing their own academy of
tennis players and making them stars. The idea of the game originated
in August 09 and active development kick started in October 09. The
game is currently being developed by a team of two, using PHP as the
coding language.

What went right?

We decided to enter BBGameZone’s Competition 2010 to complete a
Browser Based Game in a month. The competition deadline was an
incentive for us to complete the game. Before the competition
deadline, we had a rough base code that was ready. We attempted to
leverage the existing code base to complete the game quickly. During
the one month period, we put in a lot of effort in the Match Engine.
The Match Engine of the game is the core of the game and would be
responsible for simulating the matches. Since we realized that the
game would be judged based on usability, we decided to work on the
Help Manuals, so that the user would not be left clueless when
visiting the site.

What went wrong?

As evident, since we did not complete the game in time, there was
plenty that went wrong. As both of us happen to be new dads, we had to
balance the time we spent on the game with the new responsibilities in
our lives. There were times when communication was lacking between the
two of us. As we were nearing the deadline of the competition, we
realized that we would not be able to complete the game and decided to
take it a bit easy.

In conclusion, although we did not complete our game in time, we
really cherished being part of the game making competition. We plan to
start our beta season in April and would be happy to see you join and
help us build a better tennis management game. The demo website is at
http://demo.tennismasters.org and our game development forum is
located at http://dt-games.net/gamesetmatch

• Qorporate Quest
• Wicked Dead
• Demons
• ModularGaming
• Duel Arena

Due to unforeseen circumstances, all of the other entrants were forced to drop out (including yours truly). Better luck next time!

If you were interested in participating in the contest, there’s a new contest on to build a small game within 24 hours (spread over up to two weeks) – can view view the thread on bbgamezone if you’re interested.

If you were one of the participants in the contest (whether you finished or not), get in touch! I’d like to talk to some of the other participants about their thoughts on the contest and their entries.

• The contest runs for one month this time (instead of 2 last time) – it starts today, and ends on the 18th of february.
• Competitors are allowed to enter the contest in the middle, although they may start at a slight disadvantage.
• You must start with a new game – the only exceptions are old/ancient games that you haven’t worked on in a long time (subject to judge approval), or games that were entered in the last contest and placed lower than 5th when it came time for judging.

Right now, there are no prizes for the contest, as it’s solely for fun and reputation building – but that’s not to say that by the end of the month, there won’t be any.

Interested? Take a look at the forum thread for more information, and good luck!

1. What first got you into browsergame/PBBG development?

   I’ve been interested in game development as far back as I can remember; it’s been the only career that I’ve ever considered, to be honest. All of my projects in the past have been small, but now I wanted to write something which could reach a wider audience. When you consider technologies for delivering a multiplayer game, browser-based games shine. Everyone has a web browser, there’s no downloading required, the tools are powerful and the process is well established.

2. What made you choose ASP.Net as a platform for Booze Quest?

   I chose ASP.NET because I have experience in C#, which is the codebehind language I use for my pages. I’m also a big C# fan; I think object-oriented languages speed the development process and result in more stable code. I understand that the newer versions of PHP are OO, but I was already going to have to learn HTML, MSSQL etc. to produce this game so I decided not to add PHP on top of everything else.

3. What was your most significant challenge?

   Time, easily. Time was a huge weight on my back the whole time – I had two months, during which I had to produce projects for school and survive finals. It was tough to find the hours to squeeze into the project, and I ended up having to make some hard cuts before the deadline.

4. What was the least significant challenge?

   My game uses a tile-based system for drawing the player’s bar and letting him or her interact with it. Coming into the project I had no idea how I was going to implement that in HTML, but the first system I tried worked beautifully. I never had to scrap any code, and the entire system was done in a few days.

5. What did you spend too much time on?

   Art ate a surprising amount of time. I also used much more time than I thought I would on bugs – both finding and fixing them. Finally, I didn’t do my homework on hosting policies, and ended up surprised when all my database code broke after purchasing a shared hosting account – that was two solid, depressing days of rewriting code.

6. How much are you paying for Booze Quest?

   Well, I use shared hosting, which runs about $12 a month if you throw in the domain name and all. I don’t mind footing the bill at this point.

7. With a time constraint on the development of your game, was there anything you meant to build but had to cut to finish on time?

   Plenty, in fact entire portions of the game play had to be scrapped. Initially, I wanted to make each player’s bar two-story – a bar on the first level and an inn on the second level. Adventurers would rent the bedrooms overnight and provide a secondary source of income for the player. I was about a month away from the deadline when I realized there was no way I was going to be able to write the code and draw all the bedrooms for an inn before the deadline, so out it went. To be honest, once I yanked the inn I realized it was just unnecessary complication and probably didn’t need to be in the game in the first place; I have no plans to implement it in the future.

   What hurt was cutting the player-versus-player combat system before the deadline. Booze Quest is intended to be a player versus player oriented game, and it was a really hard call to not include PvP by the contest deadline.

8. What are your thoughts on the fact that Booze Quest won the PBBG contest? Were you surprised?

   I had a cautious optimism after viewing the other entries in the contest. Tygras had some phenomenal art, Cubicle Battles was unique and made me laugh and Pirates Glory had some awesome game play elements – really all the other entries were top notch. I’m very pleased that I won, but I’m more thrilled that the contest succeeded in getting some awesome new games out on the internet. (I was also secretly rooting for Cubicle Battles. Shhh, don’t tell anybody.)

9. What plans do you have for booze quest, going into the future?

   I intend to continue actively developing Booze Quest! I’m working on a patch for the more serious issues my players have been bringing to my attention, and then I’m on to getting PvP into the game. Booze Quest will stay my active side project for some time to come.

10. Do you have anything to say to budding browsergame developers?

    For all game developers, I’d say “write down every idea that comes to mind, no matter how silly”. Booze Quest spent about six months as a half-page of scrawl before I fleshed it out for the competition. You never know which of your ideas will mature.

If you want to try out Booze Quest, you can visit http://npcrpg.info.

Booze Quest is a browser-based game written in C# using the ASP.NET framework. The game started about half a year ago as a few pages of scrawled notes. From then, the idea rolled around in my brain and I fleshed out a real design document over a period of several months. When I heard the BBGZ was hosting a competition, I decided to finally take the plunge and give the game an honest shot.

What went right?

- The design document. I wouldn’t have made it thirty lines of code into this project had I not had a solid design doc. The time limitation made it absolutely essential that I didn’t rewrite code or hammer things out on-the-fly, and fleshing everything out on paper beforehand saved my butt. Typically, I tend to write code in my spare time to learn something new and not to actually produce a finished project, so I’m not in the habit of producing documentation for personal projects.

- The beta testers. I’m blessed with some vocal beta testers who really acted like a free QA department for the last month or so of the project. I’m still getting great feedback, in fact.

- The humor! Booze Quest’s idea is that it takes a traditional fantasy RPG game and turns it backwards, making you the questgiver instead of the adventurer. I was afraid that nobody would get the overarching joke that is the game, but I received some positive feedback regarding the yuks so I consider the humor as a point which went well.

What went wrong?

- Time management. I suffered from the same problem everyone else did: I ran out of time, leaving some things undone. I had hoped to include player-versus-player combat in the game before the deadline, but ultimately I had to put that portion of the game on hold.

- Balancing was never done. The game was balanced using the “whatever sounds good” method, and the time I had allotted for proper balancing was swallowed up in bug testing. Ultimately, I’ll be adding more content before I take a stab at balancing everything.

- Database code & hosting policies. I never considered where the game would be hosted until about halfway into the project, and that was a big mistake. I ended up going with a shared hosting plan, which put me in a trust environment which broke ALL my database code, requiring a total rewrite and swallowing several days’ worth of time. Next time, I’ll be doing my research and upping test code to a real server early in a project.

What I learned

This was my first browser-based project (first multiplayer project, in fact), so I learned volumes about web technology, web page interface design, database manipulation, and HTML. I learned that you should open as many avenues of communication between you and your players as possible, because they will take advantage and you will benefit. Finally, write down every idea you have for a game! Keep a binder or something and just jot down notes, you never know which of them will mature.

What Went Right

A few decisions that I made early on helped to get Rawrmy “on it’s feet”, for all that there were some setbacks during development. One of those decisions was to use Django, a popular Python web framework, to develop all of Rawrmy’s functionality. Django is geared towards rapid development in the same way that Rails is; both frameworks lend themselves very well to getting something out the door as quickly as possible – which was one of the goals for this contest due to the compressed time frame. Straight out of the box, Django gives you a pre-wired authentication system and admin backend – both of which were immensely valuable during initial development.

Another decision that helped ease the development process was a bit of a harder one to enforce: every feature implemented was droppable. What that means is, for any feature I was developing, I’d set a timer. If it took me longer than an hour or two, the feature got dropped – although I marked it as “come back to later”. Doing this allowed me to trim the fat out of Rawrmy, and focus only on the pieces that would get it to being a finished game the fastest.

What Went Wrong

Time was a massive factor that prevented me from completing Rawrmy. In hindsight, I probably should have taken some time off from my day job, or diverted time from some of my other projects – Rawrmy is unfinished because I was unable to devote as much time as I would have liked to to developing it.

Some things took too long. While I mentioned earlier that every feature was droppable, it was only after I had sunk a few precious hours into a specific(and still broken) feature that I realized I would need to enact this rule. If I had realized how much time I was sinking into non-valuable features at the time as opposed to afterwards, I probably would have had a lot more time to spend on getting the game working(and less time spent chasing down random bugs).

Lack of direction was a problem with Rawrmy. I have to admit that when I first decided I should enter the contest, I didn’t have any idea what I would build a game based on – and I believe this was one of my biggest problems. John Munsch had clearly been planning out his idea for ‘Big Villain’ for quite some time, and was therefore only waiting to do the development on his game. Multiple other entrants were also in the same position; the fact that they had already planned out most of their game gave them a massive advantage, because they could get started developing while I was still attempting to come up with a concept for Rawrmy.

When I initially entered the contest, I also had a team member who would be creating all of the written content for the game. However, after a week or so, my partner disappeared – and I still have yet to hear from him. This was another setback; the initial idea for Rawrmy was heavily text-based, and while I’m sure that I could have written the content myself, it would have distracted me from getting the game running and polished.

What I Learned

When you’re entering a contest with a short timeframe, you need to have a firm idea of what you’re going to build – it doesn’t neccessarily have to be large, but you need to have that idea and stick to it. Changing gears in the middle of a project will kill it – Rawrmy lost a good week or so’s worth of development time when my partner disappeared.

When you enter a contest like this, you need to be prepared to make the commitment. You need to be willing to commit development, monetary, and any other resources neccessary to get your game done – and while I was able to half-commit on most of those things, it’s not enough. The next time I enter a browsergame contest, I’ll make sure that I’ve got my other projects cleared out of the way for the duration, and can therefore focus only on the contest – instead of getting distracted by other things.

All told, I had a positive experience entering the contest – even if I had to drop out at the end. I learned a lot about my own development practices, and what I can do to improve in the future – which is enough of a win for me.

If you’re interested in seeing what Rawrmy was like, you can check it out at rawrmy.com.

While the time allotted for the contest was more than adequate, too many distractions came up that prevented me from spending enough time on Rawrmy to make it a serious contender for the contest at all. While I am still hoping to polish and deploy Rawrmy for the 11th, it will no longer be as a serious contender in the contest; merely as a prototype.

In addition to deploying Rawrmy on thursday, I will also be posting a post-mortem of the development process – detailing what worked, what didn’t, and what I would have changed.

With that in mind, I have been working to build something like a quests system into Rawrmy – essentially, there is a large over-arching storyline with the player is part of(sort of like Kingdom of Loathing, although nowhere near as developered). Unfortunately, it turns out that designing a flexible quests system is a lot of work – and as a result, while there are quests in place, I have had to build them in a much more rigid form than I would have liked to. Essentially, I have created an enum of the different steps in the story, and I am storing which step of the story the player is on in my User Profile model:

class STORY:
	STARTING,FRIDGE,TOASTER,OVEN,BATHROOM = range(5)

	story_step       = models.IntegerField(max_length=25,default=STORY.STARTING)

Checking which step of the story the player is on is then done by our view:

if profile.story_step == STORY.STARTING:
	profile.story_step += 1
	profile.save()
	return area_template(request,'couch','starting.html')

While this works, it’s not quite what I like – but the deadline for the contest is looming, and I will not have time to rewrite how the quests system works.

At any rate, progress is slowly being made – while I have had to strip out a lot of the features I would have liked to have, I should at least have the beginnings of the game playable by the deadline.

I’ve been struggling for the last few weeks to try and find a way to make combat ‘fun’ – while it’s a big part of a lot of browsergames, it’s a part that (I think) could use a little bit more polish in most of them. Fighting monster after monster after monster isn’t fun – it’s only a means to an end. I think that even the boring parts of the game should still be fun. With that in mind, I set out to build a combat system that would achieve two things:

1. Be a combat system.
2. Be fun.

After thinking and pondering, I believe that I’ve finally come up with a system that works(and you’ll probably be able to figure out how it works in the screenshot below).

Rawrmy's refreshed combat system

A little bit more time was also spent fleshing out the different areas of the game – and they’re what I will be working on now. I am afraid that my schedule has been getting busier and busier, lately – which means I can’t devote as much time to Rawrmy as I would like to. While I am still hoping to have something releasable by the contest due date, I don’t think it will be quite as strong an entry as I would have liked.

Completed this week:

• Combat system refresh – the combat system is now a little more fun to use, in addition to more challenging for players who have gotten to the higher experience levels.

Still to do:

• Content needs fleshing out – while this combat switch has made Rawrmy ‘feature complete’, it hasn’t made it solid yet. There needs to be a lot of polishing done in regards to content, areas, and the way that in-game items work.