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)


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)
Well, in a preliminary form, anyway.

It finally works on my Android tablet!

Not entirely sure what was wrong, but removing the code that loaded up a couple of images used for buttons made it work, somehow.
(could be my order of operations, not sure)

Next, I need to streamline my testing process, as I have to change things on one machine, copy it through another computer to put on an SD card, then put the SD card in my tablet, install the latest version on the tablet, then (finally!) test it out.

If it doesn't work, I have to launch another application that lets me see the debugging logs, then try to figure out what went wrong, and start the whole thing over again.
(not the best development chain, I know. However, I can't use my card reader on my desktop machine for some reason)

I also need to add back some form of score-keeping (so players know how well they're doing), as well as some form of levels, and state-saving, so you don't get a new game every time you leave the game for whatever reason.

But it works! Woot! =^.^=
carlfoxmarten: (Default)
Whatever my normal is...
(no! Seriously! Sometimes I don't know what my normal is!)

So, now that my sister is married off, I'm next in line by age.
Fortunately, my mother has said that she'll hold off on nagging me to get married until I get a job, so I'm relatively safe on that score for now.

What I hope to work on this week is my Dig Site game for Android (you can visit the official blog for my projects of that sort on my Tumblr site), redoing some of the fan-art I've been in the process of creating for Darc Sowers' Codename: Hunter comic, and trying to have another look at moving back a version of Ubuntu.
(I've found altogether too many reasons to avoid Ubuntu Oneiric Ocelot, it is no longer something I know I can easily ignore)

If I think I can, I might try working some more on my Prolog adventure game framework.
My interest has been piqued after a friend expressed interest in the language's current status.
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

carlfoxmarten: (Default)
I've created a Tumlbr account for the projects that I'll be releasing publicly:

Note that this has my real name attached to this, not this one.
(I use Carl Foxmarten for my artistic pursuits)

I'll be posting updates at least once a week until Dig Site is released, then I'll be using it for some other projects of similar scope.
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)
Carl Foxmarten

August 2017

272829 3031  


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

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