Showing posts with label flash. Show all posts
Showing posts with label flash. Show all posts

Saturday, March 11, 2017

Presents Panic Unity 1 - Project plan

I have been trying to decide what to do as my next project. As tempted as I am to use libgdx or Haxe I have found that when looking at my CV rather than saying 'wow, this guys has lots of finished projects in multiple different engines/languages' potential employers say 'bah, I want someone with lots of experience in the one I am using'. Unfortunately apart from Flash that's not something I have and I am not comfortable with blagging. It seems Unity is a good way forward so I have decided to do another Unity project. I want it to be a small project so I will just port another of my old Flash games that I think will work well on mobile.

The game that I have decided on is Presents Panics, a game I created about 10 years ago as a mash up of Tetris, Super puzzle fighter and Same Game. At the time I really liked the game - it has depth and multiple ways you can play and win.

Of course the game has issues and it didn't set the world alight when I originally released it. I am hoping that I can keep what I view as the original game's strengths but fix or at least smooth over the problems it had. In my view the two main problems it had were the controls and the progression.

The controls: In the original version the game used both the keyboards and the mouse. The keyboard to move and rotate the pieces and the mouse to remove them once they had settled in blocks. Obviously as the creator I had gotten used to this and had no problems with them but new players often didn't understand or like them. Since I don't have access to a keyboard on a mobile I couldn't keep the old controls even if I wanted to. I will experiment once I have something running but I think it will work well with swipe to move, tap to rotate or explode. It will be simpler and more intuitive, I hope. Of course until I have a version up and running it's hard to say for sure.

The progression: The original game goes for a very Tetris style progression. You play until you lose with the game gradually getting faster and harder, whilst the score multiplier increases. It's pretty basic and unsatisfying. There are no concrete challenges and it ends up feeling like a slog. It's not just of it's time, it's of 10 years earlier and when you compare it to the scientifically engineered addictiveness of something like Candy Crush it feel positively stone age. I am not sure what I will do here, I just know that I need to do something. Some ideas I have:
  • Have discreet levels with a score players need to reach and a limit on the number of presents they get to reach the score. Maybe  predefined starting presents already present.
  • Change the number of blocks sent down from 4 in an L shape to just 2. This would mean that if I could make sure that you always get on colours present the level should always be clearable. this might make it too easy though. This would open up the types of game mode available - I haven't player Dr Mario in 15 years but I think this is close to what they do.
  • Bombs and other power ups that destroy rows and columns. Spawned when you destroy larger presents.
  • Still have a 'rush' mode that is like the old one.
  • I could go full candy and have a currency that you collect in games that you can spend on boosts/power ups.
  • Make it less Tetris twitchy and more of a strategy game. This would mean that instead of speeding it up I would give the players less blocks to achieve the objectives so you feel like it's about planning rather than just being fast.
The only other question I'm asking myself is, should I bother? I have no illusions on whether this will be popular or successful. It won't be no matter what I do unless I am willing to spend some serious time/effort on both the polish and on marketing/pr and even then I don't think it has enough to it for it to be successful. I have to look at it as being 90% a portfolio piece so maybe I should just bog a fairly bog standard version with limited additions.

The other remaining questions is how much effort I am going to expend in trying to monetise the game. I feel like if it's going to be a portfolio piece it needs to look and feel like a real pro game and that will mean extras, though probably not iaps. In the end I will probably just stick some ads and maybe if I do boosts I will offer them for reward ads. It has to be easy and quick. 

I have all the assets, though they will need some work to export them for unity. I will need to redo the ui as the aspect ratio has changed and I want it to look more sparkly. I am hoping to complete the project working part time in 4-5 weeks. If it takes longer I won't mind too much if it genuinely improves it.

Friday, August 31, 2012

Really basic level generation

Level generation is, in my opinion, one of, if not the most important element of a Roguelike. Different methods of level generation produce levels that feel very different, ranging from box stamping to more organic tunnelling methods. To take advantage of this I want my game to use several different methods to generate the level, giving different areas different feeling that go with their theme.

This is my first, very basic attempt at level generation. All it does is stamp boxes into a grid map randomly, with no logic. It then tries to create corridors to connect up all of the room, simply by tunnelling through from one box until it reaches another. After that it cycles through the tile and creates doors in places where there are two tile between walls.

It doesn't do the interesting things yet, like place mob, item, treasure etc. Also I'm planning on using a tile editor programme to create a load of bespoke rooms with interesting layout which will then be randomly place. Still, I'm quietly happy with it so far and I'm hoping I can add to it and make something that can create genuinely cool dungeon layouts..

Give it a play, though be warned that it's all brute force computing, completely non optimized, so if you choose a huge map with lots of small boxes it may take a long time to finish. (the text on the top left is actually a button)


Wednesday, August 01, 2012

Why I'm doing it in Flash


I'm planning on creating the whole game using Adobe Flash, with the mobile versions being publish with Air. I may even do a downloadable desktop version, also using air.

I would be lying if I didn't admit that a major reason I'm using Flash is because I'm a professional Flash developer, so AS3 is a language I'm completely comfortable with. I know that I can build complex engines with it and I know it can take it.

The other reason is that I'm using Flash, and a reason why I personally think Flash it one of the best choices for building apps, is that I can produce an android, ios, web and desktop version with the same unified codebase. I'll obviously have to do some different UIs for the mobile vs the normal size version, but hopefully nothing too onerous as long as I enforce some strict apis. For me this is a huge deal. Even if I spent the time learning objective C or java, like lots of people have suggested I should 'for when Flash dies' there's no way I'd be able to do multiple versions in different languages. Flash means that for the main game elements I can develop for the flash version then just rebuild the other version without having to worry about getting all the changes carried over, because there will only be one codebase.

The only thing that remotely worries me about doing the game in Flash is the saving the game aspect. In theory it should be easy - I can use sharedObject, which should be able to save whole complex data objects. In practise in a previous project I've found sharedObject to not be %100 reliable. I managed to fix that issue by converting everything to primitive data type before the save, then back again, but it's not something I want to do if I can help it, and I'm hoping the issue has been fixed (it was infrequent enough it may have just been one flash player build.)

I briefly toyed with the idea of learning, then doing the it using HaXeNME, but in the end I decided I'm probably already biting off more than I can chew, so best not compound it by adding in a new language, especially one that's so niche and new. If I run into problems I'd be worried about finding answered, and anyway I don't see myself getting more work on the basis of knowing it.


Saturday, July 21, 2012

What is a roguelike?


Wikipedia says ‘The roguelike is a sub-genre of role-playing video games, characterized by level randomization, permanent death, and turn-based movement. Most roguelikes feature ASCII graphics, with newer ones increasingly offering tile-based graphics. Games are typically dungeon crawls, with many monsters, items, and environmental features. Computer roguelikes usually employ the majority of the keyboard to facilitate interaction with items and the environment. The name of the genre comes from the 1980 game Rogue.’

There are Roguelikes in many different genres, from fantasy to sci-fi to crime and realism, though fantasy is by far the most common. I toyed with the idea of doing a space marine themed game, but in the end decided on fantasy, largely because I want to make a big deal out of magic and that makes more sense in a fantasy setting. I was also told that there is a bigger audience for fantasy than for sci-fi games.

Frequently all it takes is for a game to have one or two aspects for people to call it a roguelike. I’ve heard Terraria, The Binding of Isaac and Diablo called roguelikes because they  feature randomly generated levels with at least the the option of permadeath. I guess this would mean that my really old (AS1!) game Doomed could be considered a Roguelike since it plays like a low rent version of binding of Isaac.

My game Doomed has randomly generated levels, character progression and one life.
It's a Roguelike!


For me the critical aspects are the randomized, tile based levels, the turn based gameplay, the character progression and the permanent death. I’m not going to have asci art, though my art will be functional and it’s got to be entirely mouse driven, since it has to go on mobile which has no keyboard.

Thursday, July 19, 2012

My Roguelike indie project


I’m a flash developer with more than 10 years experience making web games and other rich web application type stuff. Previously I’ve been able to find time to create my own games in my spare time but in the last couple of years I’ve been too busy to do my own stuff, due to work/family commitment, plus also playing too many games when I do have free time.

This has meant that more and more I feel like I’m being defined by what I do for my job, and though I do get the occasional games project where I get to exercise some creativity I’m increasingly finding myself doing jobs where I am Just A Programmer. It’s kind of depressing, and also it leads onto more of the same dull technical work.

I know quite a few people who are doing indie games and it just seems much more interesting a fulfilling and long term I really, really want to move in that direction. I just need to find the time to do some of my own work and the mental toughness to turn down freelance work when it gets offered. As much as now may not be a good time, what with a new baby and the expense of living in London, I’m can't see when there ever will be a good time, short of winning the lottery, and I’ve been putting it off for years. I’m allowing myself to coast until my current contract finishes, trying to do some groundwork in my meagre spare time, then I’m hoping to take 1-2 months off to try to get something done, with more time allowed if what I’m doing is promising.

I’ve been weighing up which project to go forward with and I’ve decided to go with a Roguelike, specifically one tailored to mobile devices using Abode Air to publish it. I’m also planning on doing a cut down pure flash version for the web, mostly to try to drive traffic to the app versions.


Friday, August 28, 2009

Bug Squad post mortem




I made and release this game a month ago, but I've only just had time to write it up here.

It all started about 4-5 months ago when there was the first swine flu scare. I had an idea for a dumb game about shooting pigs and got it as far as being able to shoot circles with other circles. I then got a contract and forgot about it. After that was finished I had a bit of time off and finished it off. I decided to keep it as a dumb game about shooting pigs and concentrate my engergies on the production values.

I think I succeeded in making a game that looks really nice and has rocking music, but I'm not so happy with the gameplay. It works to a point, but I think that I may have over-simplified it. I was aiming for a combo building high-score game and it's works as that, to a point. The mistake I made was than I didn't make it short and snappy enough (check out Boomshine for a good example of this) to work as this type of game. Also it has a huge problem in that if you don't go for the combos it's possible to survive for a really long time just by being click happy, but that if you do this it's a fairly boring game.


I did put it on the forums at flashgame license and I got some good feedback, but no-one picked up on the last point, and I was too close to the game to see it myself. I only realised after the game had been released when I was showing it to my family, and I actually got to watch them play. I'm absolutely gutted about that because it would have been fairly simple to have cut down the shot speed and thereby eliminate this as a viable mode of play. This just shows the huge limits of bedroom development. I'll have to make sure I can watch people play any subsequent games before putting them out.

Given it's drawbacks I can see now why I was unable to get what I would consider a decent payment for the sponsorship, and I'll just have to take it on the chin a try to learn the lesson for my future projects.