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 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)
I never realized just how much knowing about different programming languages would affect my knowledge of other programming languages.

For instance: I learned C, Java and C++ before I attended university, where I learned more about them and programming in general.

While at university, I learned that the above languages were all the same type of language, namely, they're all Imperative languages, which means you give the processor a list of instructions that it executes pretty much directly.

I also learned about two more types of programming languages, such as Logic Programming, which is where you construct a solution to a problem and let the built-in logic solver solve the problem itself, without specifying the exact sequence of instructions, as well as Functional Programming, which is similar to Imperative Programming, without giving you any form of global state, which means that every function returns the exact same result when given the exact same parameters.
(Functional Programming is often used for low-level systems programming, such as for low-level Operating System functions and BIOSes)

I learned about these programming language types by learning about programming languages that implement these types, such as Prolog and Erlang.

While designing the Event system for my Tetris Power project, I started to realize just how using a Logic Programming language would simplify the core of the system.

For instance, many events more-or-less directly trigger other events, like a "block_land" event might trigger a "row_full" event, which itself triggers a "score_add" event, which then has to add a floating score to the screen.

Theoretically, it should be relatively easy to do something like this if I use Prolog (the only Logic Programming language I know at present), though it could be a little awkward in places, due to the extra layer between the game logic and the rendering system.

I'm going to be examining this more fully and even starting a new branch to work on this to see what happens in practice.

More will be posted as I learn about it.

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:55 am
Powered by Dreamwidth Studios