carlfoxmarten: (podium)
I've been playing The Saboteur for a few years now, but what's caught my interest up again recently is the fact that I now have an XBox 360 game controller for my PC, which makes certain aspects of play easier.

If you haven't heard of it before, a quick summary is that it's a third-person shooter with a good story, set in a very accurate depiction of France during World War II.
Parts of it are almost like Grand Theft Auto, but it's less frustrating, or so I understand.

Despite some glitches (mostly visual, some gameplay), I still find The Saboteur to be a very enjoyable game.
Collect cars (either found on the side of the road, or stolen from their rightful drivers) and earn additional perks to make your way through France more easily.

Probably the most surprising aspect of the game for me is the fact that it's been so faithfully recreated.
I've seen several movies now that have at least some parts of it set in France and I find myself saying things like "Yup, I've seen that," and "I think I know where that is."

A truly weird feeling, seeing as I've never been there...

The plot never changes, and is somewhat linear, but it's fun to come up with different ways to approach each mission and target.
That is the one reason I like this game above all the others, because it's essentially open-world, you're not tied down to a handful of ways to complete the missions.

Where the game controller comes in handy is for driving vehicles around.
The keyboard being purely digital makes it a little tricky to drive, especially during some of the races, without a fair amount of practice ahead of time.
(fortunately, or unfortunately, there's a lot of driving around to get to the various missions, targets, safe houses, and arms dealers, so you do get a lot of practice in)

Surprisingly, the XBox 360 controller's two triggers are actually analogue, which means that I can directly control the vehicle's speed, making it easier navigate the city streets to my next target.
Unfortunately, it's still difficult for me to tell which button does what when I'm wandering around on foot, in addition to the fact that my aim is far more accurate with a mouse, so I have a handy flat surface near my keyboard tray to drop the gamepad on when I step out of a car.
(the nice thing is, the getting-out/getting-in animations are long enough that I actually have a fair amount of time to fully switch from keyboard/mouse to gamepad and back, which means I have no issues getting out of a car to interrupt a firing squad)

Unfortunately, the one issue I've been having with it is the in-game map, which makes it a pretty major issue.
You use the in-game map to see where you're supposed to be heading for missions, or where to find the nearest arms dealer is and mark a waypoint, which lays down a line for you to follow when you're driving a car.
The problem is the fact that, for some strange reason, the layer the map is on is not the same layer that the targets, safe houses, etc, are on, and they don't move together!
(one of the layers moves faster, causing me problems when I'm trying to figure out where I'm going)
I haven't figured out what causes this, but it has to be something related to the screen resolution in some way.
Guess I need more research into this...
carlfoxmarten: (podium)
Well, it's been a while since I used this journal to post about the status of my Android games, so it's probably about time now.

I have two of these on the go right now.
The first is called “Dig Site&rdqou; and is a connect-three matching game where you slide the lines of objects around instead of swapping them.
The second doesn't really have a name just yet, so the working title is “Electrical Connections’. In this one, you work against the computer, trying to connect two electrical bars to each other by putting smaller bars between posts, while the computer tries to block you after each of your moves.

Dig Site work has stalled due to the extremely high amount of graphical code that needs to get massaged to have things working well.
Currently, it's playable, automatically stores your game, has four levels of difficulty, and needs far better graphics than it has right now.

Electrical Connections is currently only a Java prototype, but has passable graphics (for a prototype) and will detect when the current game is over, who won, and will start a new one on the next mouse click.
Currently I'm somewhat stuck on the computer's AI algorithm.

The game has to choose the best place to put a blocking piece based on the grid as it stands after each move the player makes.
This is in no way a trivial operation, as I have to take into account both the best move the player can make as well as the best move the computer can make.
If the best plan of action the computer can make requires more moves to complete than the player's best plan of action, then the computer needs to block the player's next perceived move instead of its own best move.

Despite the fact that I was able to articulate the above, it still hasn't gelled in my head in such a way that I can put it in code.
I think I need more time in front of a whiteboard so I can closely examine what makes this algorithm tick and how it needs to work.

This is particularly important due to the fact that it's this algorithm that will make or break the entire game.
It won't matter if the graphics are awesome, the sound effects perfect, and the music (if any) fit together well.
If the algorithm is too hard or too easy, the game won't be much fun.
carlfoxmarten: (podium)
Well. Last time I mentioned my adventures at the Spiral Knights Auction House, I was at about three hundred thousand Crowns (the in-game currency).

Just after that post, a friend I had on Steam realized that he isn't playing Spiral Knights any more, and traded his entire tradeable inventory for all the Team Fortress 2 metal I had.
So I got a huge influx of Crowns, Crystal Energy, and tons upon tons of Materials.

The trade didn't contain too much in the way of Crowns, but there were piles upon piles of Materials that I've been slowly selling-off.
This means that I currently have a little over eight hundred thousand Crowns! =^.^=

Hmm, not really sure what more I can add here, aside from notes about the seemingly random fluctuations of material prices.
Any questions or comments?
carlfoxmarten: (podium)
I thought I'd give you guys an idea of how prices change in the Spiral Knights Auction House.
(unfortunately, I don't have any idea why the prices change, just that they do)

A good example is Red Shards.
Up until the last three days, Red Shards were selling for anywhere from 20 crowns each up to 75 crowns each, and I was selling out pretty quickly by pricing mine at 65 crowns each.
Within the last three days, somebody appears to have started buying them up a little faster than normal, which means that, for the most part, I kept finding the cheapest ones were around 100 crowns each, so was still selling pretty quickly at 95 crowns each.

Another example is Beast Scales.
Up until recently, they were priced around the 240 crown mark, now they're selling quite quickly at 300 crowns each.
(not much of a change, but enough for me to notice)

On the bad side of the scale, however, is Sharp Fangs.
Originally selling moderately quickly for 95 crowns each, they're now hovering around 40 crowns each.

In other Spiral Knights-related news, one of my other Steam friends hasn't been playing SK in a while, and so traded his entire tradable inventory to me for my Team Fortress 2 metal.
Now I have plenty more materials to sell! =^.^=
carlfoxmarten: (Default)
Spiral Knights is a cartoonish RPG-style game where you fight beasts, gremlins, slime monsters, mechanical contraptions, and more on your way down to the core of a planet, earning in-game currency (crowns) and materials used for crafting along the way.

If you play for a long time, you can amass quite the collection of materials, and if you don't use them up yourself, you can post them to the Auction House to make some more money.
(though there is a 10% fee on the final sale price of anything sold through the AH)

Play your cards right, and you can make quite a bit of crowns buying materials posted at ridiculously cheap prices (when people are dumb enough to post them that low) and sell at higher prices.
I think I had a week once where I made at least 20,000 crowns a day, from trading at the Auction House alone, not including the money I made from my forays into the planet itself.

Unfortunately, you also have to be wary of changes in the market.
If prices go up, you'll do fine. But if they come down, you could run into some problems.

For instance, Bushy Tails had been selling for somewhere around 900 crowns when I first started trading them, so I'd load up on them when I could just so I could earn that much more money.
Then the price slowly started to go down, and I was able to buy them for 600 or even 500 crowns each, but still sell them for 800 crowns, which made a profit of about 120 or 220 each.

Unfortunately for me, the prices have dropped still further, with the vast majority of Bushy Tails selling for between 500 and 700 crowns, leaving me with almost ninety Bushy Tails that I'm still trying to sell.

The good news is that I have lots more materials available to sell, so I'm not really hurting for in-game money.
Just today, I again broke the 100,000 crown barrier again.
(for reference, the highest I ever got was around 350,000 crowns)

Another example is Red Shards. Somehow I managed to pick up 400 (not all at once, of course) for the ridiculously-low price of 10 crowns each.
I'm now selling them for around 65 crowns each for a very nice mark-up of around 50 crowns per shard sold. =^.^=

Also, it's apparently a good thing that I'm on a prepaid cellphone plan, and that I don't use up much in the way of minutes on it.
Three Rings, the company that produced Spiral Knights, has quite a variety of payment options, and even includes payments via cellphone, so I can use up my extra credits to buy in-game energy, which I can then sell for even more in-game currency.
(each month, I add $10CDN to my cellphone plan to keep it from expiring, and when I have $20 or more left on it, I buy about $5-worth of energy. It's a useful - to me - purpose for the extra credits, instead of wasting it on mobile games I won't or can't play)
carlfoxmarten: (Default)
Sometimes I surprise myself with how quickly I can put together a small program.

Case in point: Yesterday I was playing an online Scrabble-like game called Popotamo, and had been using an online word-search tool to find the highest-scoring options (the longest words, in this case), but kept running into problems when the board got pretty full.

So I decided to grab a copy of the SOWPODS dictionary (the dictionary used by the game I've been playing) and try to write a simple program to provide suggestions based on the tiles I had already, as well as providing an option for specifying constraints for the words.

As it turns out, it was actually a rather simple program to write, taking less than four hours to complete, most of which was spent trying to figure out how to design the User Interface.

Originally, I'd written it in Python, an easy-to-use scripting language, but realized that it's not a very fast language, nor is it terribly portable.
So I decided to rewrite it in Java, which took less than two hours, most of which was spent trying to remember how Java does GUIs...
However, the advantages Java has over Python were threefold: First, it was fast, which is great when processing long lists of words. Second, it is entirely platform-independent, which means that it can run on any type of computer that has a Java implementation. Third, the program can be packaged up into a single file, which means that you don't have to fiddle around with the dictionary file, because it's wrapped up in the single file.
(also, if I so chose, I could embed it in a web page, but I've decided against that for the moment)

Anyway, I was quite surprised at how fast it came together, and once I've found an appropriate place to host the file, I'll be posting a link here so others can use it too.
carlfoxmarten: (Default)
In today's modern age of computer programming, extremely few projects start out with nothing to base their work on.
This means that just about every programmer, whether they realize it or not, has an immense library of code they can pull from.
Due to the cross-platform compatibility we've been striving towards in recent years, that library is even larger.

One of the many ways to think about this is to imagine that all the code available to the programmer as parts that can be connected together.
If all the pieces the programmer needs are readily available, then it's simply a matter of plugging them together, with maybe a few lines of code for each connection that must be made.
(of course, it does require knowing what to use and how they fit together, but that's what documentation is for)

Where this breaks down, however, is when something isn't handled by the code available.
When the programmer needs to write a new section of code that does more than just interface between two other sections.

This is where I am right now on my Dig Site game.
I've decided that a particular feature would be a very good idea, and would mean I wouldn't need quite so many different block types/shapes/colours as I would have otherwise.

Unfortunately, this means I'll need to add a whole bunch of code that is based on concepts that I'm still a little fuzzy on.
Namely, probability tweaking.

Up until this point, it has been entirely random what block types are added to replace matched blocks, and the likelihood of each type getting chosen has been equal.
Now, I want to make the game harder by picking block types that are less useful to the player as play goes on.

This means that I need to figure out what block types would be most useful to the player and make them less likely to show up.
Not only that, but I don't want this calculation to have much effect at the start of the game, and gradually increase its effect the longer the game is played.

It's taken me a day or two to figure out the logic needed behind the setup, and another couple of hours to make sure that the code was right.

Unfortunately, I still don't know if it's anywhere near right yet, as I'd stepped away from the computer about half-way through writing this section, and when I came back, the computer had "kernel panicked" on me.
(the Linux equivalent of blue-screening)

Fortunately, I had saved what I'd managed to complete up to that point, so I won't have to rewrite anything yet.
I'll take another crack at it tomorrow.

Also posted to my Tumblr blog.
carlfoxmarten: (Default)
In much happier news, work on my Dig Site game is progressing very nicely.

It took me a day (only! Yes, this surprises me) to add support for checking to see if the board contains any valid moves.

I've delayed adding this before because I thought that it would be overly complicated, take too much time to run, and/or be nearly impossible.

As it turns out, the code is actually relatively simple (so far as concept goes, anyway), it doesn't take much time to run, and it was actually easier to write than I thought.
(most of the time was spent figuring out how it should be structured and what checks should be in place)

In addition, I've added support for some form of difficulty levels, which I'm managing by increasing the number of block types the higher the player's score gets.

This also means that I need more colours for block types.
Last time I tried to add more colours, colour was the only way to tell some blocks apart, and certain colours were difficult to tell apart.

I was thinking that it might work to overlay black outline versions of the tiles I'm thinking of using over top the coloured rounded square I have right now to give it a flavour of what I've been working towards.

Still not sure about it, but it would solve a couple of problems I have.
carlfoxmarten: (Default)
A Refreshing of Direction.

My Android game will be delayed a bit further, as I've been reminded that the best indicator of how successful a game will be is how much fun the designer has playing it.
(particularly, does the designer still play after it's been released?)

I've detailed how I hope to extend game-play in my Tumblr article, though I'll also comment on it here in case somebody wants to provide me some feedback.

My original design had the game awarding the player fragments of artifacts at random during play.
Once you had enough pieces to put one artifact together, you could sell it to the museum (or before, if you were desperate), then use the resulting money for "power-ups" and bonuses.
Some power-ups I've thought of so far include hammers (breaks a single block), bombs (destroys a radius of blocks), paint brushes (changes a block's type), and hint bonuses.

All of this is going to take a fair amount of time to code up, so my official release date has to get pushed back significantly.
(all the better to get a good product, you know)

Progress!

Feb. 11th, 2012 03:29 am
carlfoxmarten: (Default)
Today I showed my mentor my current progress on my Android game, and was quite encouraged by his response.

He is a proponent of the "release early, release often" methodology, as that acts as a bit of free advertising for developers and their software, and prepares the public for the upcoming complete release.

I was kind of surprised just how short the list of things he thought I should do before releasing the game was: Some additional feedback for failing to make a match, sound effects (to help with the feedback), and something to make the game fun.

The tricky part is the last one, but it could be as simple as a cool animation for the blocks getting removed.
Another option is for the score to be tracked in a global highscores list, which unfortunately needs a server on the internet to keep track of such things.

I'd like to add a cool animation for blocks removed after a match is made, but I'm not quite sure what to do.
Another game I've played breaks each block removed into four pieces and throws them around in a nice shower of pieces, while a version of Tetris I wrote a few years ago (and never released) has each block spin and shrink.

After I get this version of the Dig Site game up to proper speed, I'll need to get a credit card.
In this case, a disposable one will not work, as Google needs a full credit card so they can pay you.

I also just spent several hours adding what should have been an easy feature: Animating the line when it slides back after failing to make a match.
I suspect the reason it took so long was due to the number of mistakes I made previously in the development, such as using flags when I should have used state variables.

Anyway, development continues.
Plus, you can tell when you've reached an interesting point in the development of an application when you pass up playing games to work on the program...
carlfoxmarten: (Default)
I told you it ran on my tablet! =^.^=
(picture included)

It has a long way to go before it'll be ready, but at least it works!

The list of things that I have left to do on it feels a little long:
  • Add support for using the navigation buttons as well as touch.
  • Swap out the coloured squares for images.
  • Make it harder to erase the last-saved game.
  • Add options for level-of-difficulty before starting a new game.
  • Add a method for increasing the difficulty as play progresses.
  • (optional) Add sounds.
Maybe it just seems long...
carlfoxmarten: (Default)
I think the "weeeeeeee!" factor has died down by now, and I've started actually using my new tablet for real now.
Though I haven't done any real "work" with it, mostly playing games and browsing the web...

First, a couple of gripes.
Since this was such an inexpensive tablet, it uses a pressure-sensitive screen instead of capacitance, so it's not quite as accurate as it could be, but with the advantage of using almost anything I want for a stylus.
Also since it was so inexpensive, it's running a very old version of Android (1.5 versus the latest 3.2 or so that they're up to now), and as my development kit only goes back to 2.1, I can't write software for it that way.
(it's also underpowered, but I can live with that, for now)

As for games, I've found a couple that I find fun to play:
I've found a note-taking application called Note Everything that I've found easy to use.

The web browser I'm rather disappointed with, though.
I use browser tab a lot, and the built-in browser doesn't handle that very well.
So far, I haven't found a good replacement either.

All in all, a little disappointing, but still workable and quite usable.
carlfoxmarten: (Default)
Mine, that is.
(I don't think Cyan Worlds has done anything further with the Myst series recently)

I finished Myst 3: Exile a couple days ago. I'd forgotten just how easy it was to beat.

I had to use a guide for one puzzle. In Amateria, the puzzle with the large balance beam, I'd forgotten which weights to use to keep the beam balanced.
(it was particularly annoying because I'd solved it myself, but forgot to save my game, and it crashed on me a while later...)

Next up is Myst 4: Revelation, though I'll be waiting a bit before I start that one.
carlfoxmarten: (Default)
I can now say that I own and have beaten every game in the Myst franchise.

The last game that I hadn't owned for the longest time was Myst IV: Revelation, and I was having the hardest time trying to find a copy anywhere.
Even stores that had PC games from ten years ago did not have a copy of Revelation at any of their locations.

I had almost given up on finding a legal copy and thought rather hard about downloading one illegally.
It was available through various Amazon-supported shops, but I wasn't about to pay $35 or more for a game that was over ten years old.

Eventually, my brother found a copy in a dump bin somewhere for about ten dollars, and called me to check and see if I wanted it.

Now, a couple of months later, I've finally finished the game.

Makes me a bit nostalgic now.
I think I want to go back and play the whole series over again...
carlfoxmarten: (Default)
I know, I know, I should be posting this to my Tumblr blog, but I thought I'd post it here first, as the comment locks are rather restrictive over there.

This past Friday, I'd showed what I currently have off to my mentor, an instructor at my university's closest campus, and got rather positive feedback on it.

He pointed out several very helpful things that I hadn't thought about, like putting the highscores page right in the main menu, some alternative suggestions for handling scoring, several very interesting "bonus/penalty" concepts, and recommended that I write a very simple story to help answer some questions players might have about gameplay, such as "Why am I doing this?", "Am I doing this legally?", and the like.

The story doesn't have to be anything very large, it could even fit on half a page.
Something like "You are an archaeologist at a dig site in [insert area here], looking for relics and artifacts to take back to the museum that hired you." may suffice, though I'll have to think about this for a bit first.


Posted via m.livejournal.com.

carlfoxmarten: (Default)
I had quite a productive day yesterday.

I'd been having problems figuring out the best way to recognize the matching blocks, as it's something I've never come across before.

Something that helped me was realizing that I may need some of that information while drawing, so caching the information was a good idea.
This means that I have two functions that work together to remove matching sets of blocks.

The first one checks for all matches and stores its results in temporary arrays while we wait for the logic to decide if it wants to start removing them.
It assigns each grid cell a "set number" that all adjacent cells that match will have, as well as storing the number of cells each set has in another array.

That data is then scanned to see if any set has at least three cells in it.
If so, we have matches that should get removed as soon as possible.

The removal function is fairly trivial as well, though it took a while to get right.
It scans through the whole grid, checking to see if each cell is supposed to get removed.
Each cell that needs to be removed gets blanked out with null values as markers so we don't accidentally miss any removals.
We then drop each existing cell that is above an empty space down as far as it can go, and fill the remaining in with new cells.

It's working rather well, too.

However, I think there's a bug in there somewhere that causes it to remove more cells than necessary.
Sometimes when I'm sliding a line around, I know for certain that I'll only create a certain number of matches, but it removes far more than that.

If I have you on Facebook or Google+, I've already posted screen shots so you can see them.
I probably won't be posting much of this on DA or FA, as I'll be releasing this under my real name, but I might post a couple of screen shots when the game is finally released for advertising purposes.
carlfoxmarten: (Default)
Of course, that could be its real name as well, but I haven't got there yet.

I've gotta watch what I'm doing a little more closely, so I don't introduce new bugs too easily.

One of my screens has to listen for events that get triggered when the screen gets created, changed or destroyed, and I've put a bunch of setup code in the onCreate() method, so it made sense to put most of the setup code in there.
The problem came in when I put the code that added the screen to the list of things called for those events into the method that was called by them, essentially creating a catch-22 situation.
(code that would set up the calling of the method in the method that was supposed to be called by the system. Very annoying)

Next up I need to decide how I'm going to lay out the stuff on the play screen so I know where things are supposed to go.
(I have to do different things for wide screens versus tall screens, for instance. And square screens are another matter entirely)

I'll be posting updates here roughly once a week, or more often if I finish something important.
carlfoxmarten: (Default)
But I sure do enjoy hanging out on campus.

I had some very nice chats with a few of the instructors I've gotten to know during my years at the university, one of which was very informative, useful, and could go a long way towards either getting a job in the computer games industry or making a small name and associated income for myself as an independent game developer.

Last time I had a chat like this with this instructor, I apparently didn't quite get what he'd said, but this time I think I have it.

I'm going to try writing a "connect-three" game for Android in four to six weeks and release it for sale on Google's official Android Marketplace for the low, low price of ninety-nine cents.

A "connect-three" game is a category of casual game where you have a grid of objects and you have to match three or more of the same 'type' of object to remove them.
For example, Bejeweled and Chuzzle are two examples of connect-three games.

So far I've managed to install the Android developer kit and have started working on a very early prototype, mostly learning how things actually work.

Once I've figured out how things are supposed to go together, I'll work on adding the basics of gameplay for fine-tuning things.
After the game logic is relatively complete, I'll work on the actual graphics to be used.

Right now I'm thinking about using an archaeological theme for the game, matching artifacts like-for-like to obtain points.
(I'd been originally thinking about cutting the artifacts up into tiles and make you put them back together in the grid, but I don't think that's going to be very fun just yet)

Yes, this means that my other projects are more-or-less on hold right now, but I don't think they'll suffer that much for it.

Watch this space for updates and poke me if you think I've been away too long.
carlfoxmarten: (Default)
It's rather anti-climatic, actually.

After finishing the story missions, I get the rolling credits and triumphant fanfare, but after finishing all the story missions and free-play targets, nada.

I've spent over a week playing this game, working through all the missions, and taking extreme pains to avoid triggering alarms, with nothing more to show for all that hard work.

Granted, the main point of the game was the story missions, so I can't fault them too much for that, but it would be nice to get some sort of reward for all that extra effort.

I have to say, though, that I'm seriously tempted to play through the whole thing again so I can get more of the perks earlier.
Some of them would be really handy to have for certain missions, especially the rocket launcher that holds seven rockets.

However, I now have two games that I haven't even opened yet, so I should probably wait a bit before jumping back into France.

The two games I haven't played yet are Dragon Age: Origins, Ultimate Edition (which includes all the expansion packs), and Dragon Age 2.
(I playtested EA's latest snow-boarding game recently, so DA2 was my reward for that)

I'm currently installing DA:O, but shouldn't try playing until I definitely have some free time, and not right before bed...
carlfoxmarten: (Default)
Apparently, I'm really enjoying The Saboteur.

According to the statistics it keeps, I'm 78% done the story missions, while only 39% done the free-play targets.

I guess that means I need to take out more free-play targets...

However, I do have some questions about the free-play targets, especially the ones that look like jumps or a pile of pipes.

I've tried bombing them and nothing happens, as well as (attempting) to drive a truck off one of them, and it stopped square on the jump, like it was parked there.
(I just checked a couple of forums and found out they're merely "trick jumps", so I'll have to try again when I have a vehicle)

Today I haven't played because I felt I've been playing too much, so I've spent most of the day working on projects and such.

Maybe later...

Profile

carlfoxmarten: (Default)
Carl Foxmarten

August 2017

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
272829 3031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 06:54 am
Powered by Dreamwidth Studios