Hi there, right...
while I have always been making Perling with it in mind that it will be on multiple platforms, I've not really tried it other than running it as HTML5 or XNA (for Xbox). HTML5 is quite slow (expectedly) but it functions completely as expected.
When Monkey started supporting the PS Vita I very quickly tried it and got the game running with literally no changes required which is amazing. Unfortunately while on the most part the Vita SDK is good, the support for joypads is poor. "Out of the box" you cannot emulate the analogue sticks of the Vita system unless you are testing on an actual PS Vita. Some clever chap over on the PS forums has made a Pad Server that lets you stream in the state of a PC joypad and go from there, but really this shouldn't be necessary and the sooner Sony sort this out the better. That said, once the Pad Server is running, the game runs perfectly, so that's reassuring when/if I get a PS Vita.
Before I had even started Perling, I had planned for it to be playable with touch screen controls. While I don't actually like touch screen "virtual stick" like controls, realistically, it's what I have to aim for if I want any chance of releasing Perling on mobile devices. So I implemented some great Virtual Stick code for Monkey and got the game working very easily again. It stutters a bit (especially when using the SetColor() command) but it works entirely without intervention. Monkey makes it very easy for you to say "For this platform do this... but for Android, do something else". This is great for scaling between different targets. So I can basically say a particle explosion has 50 particles for all platforms, unless it's Android, in which case only make 10. I have a global "Control" class that handles all of the input and it's been made to handle the various platforms without the main game logic needing to be aware of it. Until I attempted running this on Android it was just sat there doing nothing, but I am actually quite proud of myself for having the foresight to implement it in the way I did, I know it has saved me a lot of grief now!
PC / Mac / Linux
While I know I can get Perling working on a PC using XNA, I've not actively made any effort to get the game running on Mac or Linux. I was aware the GLFW target would allow for these platforms, but because GLFW runs like a dog on my PC, I've not really pursued it. I had hoped that someone would make a BlitzMax target and then I would just use that (I want to use BlitzMax for Ninjah as well). In the past week MonkeyMax has become a feature complete BlitzMax target for Monkey This is great news because it gives me confidence in distributing games for PC, Mac and Linux now. I love that I won't need to rely on any .NET or XNA frameworks for the game to run and I can bundle all of the assets in to the executable as well.
Last night as a trial I installed the MonkeyMax target and successfully got one of the included demos running. I have Linux installed on my PC, so I will have to give that a go and I am currently attempting to get OSX running in virtual box, but I am not having so much luck just yet!
I was going to write about "finding a theme" as well, but this post is too long as it is
while I've still barely scratched the surface, I've been making lots of progress with Perling. Until now I've been working on things with very little focus on planning and basically been messing around with things when and if I've wanted...
On the 16th of August I wrote an article describing my experience using Monkey to make an XNA project. I was quite critical (though I believe fair) about it and closed by mentioning that I was sure all of the issues I had were just because Monkey was still in development. This is pretty much the case and I will go through the areas that I previously had a problem with.
In part 2 we optimised the object iteration process to perform as few checks as possible, finally we need to code the part that causes objects to react to interactions with other objects.
Continued after the break
In part one, I got to the point where we were able to iterate through all in game objects and check to see if they were overlapping.
This is great, but in its current state every single object will check itself against every single other object every frame. On a small scale this isn't a problem, but really we want to limit checks as efficiently as possible. I admit I am definitely naive to how much processing a "standard spec" computer (whatever that means) is capable of these days, but I always feel slightly uncomfortable if I don't at least attempt to optimise things. Years a go, I spent a whole day implementing what I thought was an amazing way of reducing CPU usage for a uni project (Pogo Fred). When I was actually able to run the optimisation in its entirety, it made no improvement whatsoever, in fact, it actually slowed things down ever so slightly. I didn't feel bad for trying and failing, but thought maybe I should give computers more credit!
To optimise these checks, we have to dismiss objects for checking as quickly as possible. I do this on a number of levels which I will go through below. Please click "Continue Reading" for more.
Before I start : Not that I think anyone actually takes anything here as a source of advice but... this obviously may be a completely stupid and incorrect way of doing things. All I will say is, it is a solution for a problem I have when programming with Monkey while at the same time being aware of how Xbox games created through XNA really do not like garbage (as you might be aware from my previous posts about Ninjah). I'd also like to state that I'm not writing this in a "hey, everyone should check this out" kind of way, more a "I've ready plenty of useful posts and it's only fair to contribute as well".
Ninjah is a really simple game, the amount of interactions between in game objects is minimal. To the point where I can list them...
- Ninjah against Level
- Ninjah against Coins
- Ninjah against Exit
- Rope against Level
- Bullets against Level
That's it. That's literally it. The code very specifically did these things. I went through each level block to see if Ninjah was touching them, did the same for each coins, did the same for the exit. Then I checked the rope (assuming it was out and not yet attached) against each level block and finally I checked the bullets against each level block (if bullet over wall, remove bullet).
Perling (now just a working title because I don't like it any more...), could potentially have 100 different object types and they could all interact with each other. So there could be 100 x 101 check combinations (the extra 1, is the level itself) and even if there are just 5 of each object type that's 100 x 101 x 4 checks (4 being 5 - 1 because you don't check an object against itself). That's 40400* checks for interaction per frame. (* There is almost certainly more to my some what crude calculation, but it's fine for an understanding of how many checks it'll do)
So, how do you check all of these objects? Hard coding it would lead to the below...
Ok, first check all the player objects against all the coin objects. Now check the player against all gem objects. Now check against the sparkly objects, and now the boxes, and now trees..... OK now check all the coin objects against the gem objects, and then the sparkly objects and then....
... nah. Click "Read More" to continue.
So what's been going on? In short, nothing
The last post spoke about procedurally generating a world map. I was going to use this for a game I had planned on making years ago, Virtual Evil. However, I soon realised I wanted to make a game that as best as possible made itself. So no fantastic story, no scripting, no plot, just a (hopefully large) set of rules that let's the game make its own random entertaining scenarios.
As mentioned before, I really enjoy making components of a game (for example a certain type of enemy), however I really struggle actually implementing them in a reasonable way (I still have no real idea why). So the plan is to randomly generate as much as possible automatically. An example might be an enemy that is scared of water so avoids rivers/lakes and when set on fire it targets similar enemies and runs at them. It's up to the level generating function to decide which enemies and tasks happen in each level.
Instead of having levels 1,2,3...100. The player will select levels by name, either by very specifically writing a name in themselves letter for letter (it could be a word, phrase, or random jumble of letters!) or by using the included level name generator that spits out such gems as "Unsightly Bumpy Minister" or "big screeching fight".
My previous attempts at level generation relied on drawing everything, so to summarise "draw some trees, draw a river and then draw a town", it seemed almost child like and while I think it had its charm, it was crap. I knew that Perlin Noise existed but because I didn't entirely understand it, I ignored it. Having found a PHP implementation of Perlin Noise, I decided to have a closer look and found out it wasn't quite as scary as I first thought (that's not to say it isn't brilliant still!). Being more comfortable with PHP than any other language, I was able to actually understand what was going on (or at least understand what the code was doing on a per line basis) and I decided to rewrite it in Monkey which allowed me to generate levels from within the game.
"So you should be just about done now right?"
Hah, not even close. I've been really lazy for the past month or so and would say I am barely started. I still don't know exactly what I want to add, so I have no idea of scope yet either! I bought a new computer with the notion "A faster computer means I will be able to develop and compile things quicker", unfortunately and if I am honest not unexpectedly it has been "Now I have a computer capable of playing all the games I've been buying from Humble and Steam bundles that I was previously unable to. Oh and Minecraft, I can now play Minecraft". You know what though? It's been fun!
I installed Monkey, Visual Studio C# and Jungle IDE on my new PC earlier this week and am now ready to carry on when and if I see fit. I'm not too fussed about setting myself targets at this stage, but it would be nice to be at least doing some work.
For anyone interested (hi Shereen!) Ninjah is still plodding along making sales on Xbox Live Indie Games and recently hit the 5,000 sales mark Originally I had said I would be really chuffed with 2,000 sales (a number I plucked out of the air), so to see the number going up a bit each day still is fantastic. There's still a niggling feeling that there is plenty I could make better, I guess I should just use this as inspiration to make a better version. I would love to make it available for the PC, but am a bit concerned about protecting assets I've licensed, notably the music which currently would just be included as a WMA file with no encryption. If it were my own music I wouldn't mind, but I am weary of hurting those who made the music.
There we go. Thanks for reading (all 3 of you)
I've written up some bits on the 2d map generation I've been messing around with.
While I spent most of the weekend being tired and lazy, I did manage to make quite a lot of progress on the level editor. As mentioned before Monkey isn't great for file writing, so I am currently making it in BlitzMax. I had assumed it would take a little bit of time to get used to it again because I hadn't used it for quite a while, but it all came back to me relatively quickly! More after the jump!
So Virtual Evil (I used to like that name, I don't anymore >:/ ) will be a sort of RPG game. To me an RPG is a top downish game (like Zelda 3) where you run around opening chests and boxes collecting things while talking to people and performing quests. There will obviously be a story but I personally don't find these to be the driving force in an RPG, it's more about completing interesting quests and being a bit of a completionist! I quite like the story in it's very simple state right now and I hope I enjoy evolving it.
Click continue reading for more