Topic: Nintendolife Users' Game Development Thread

OK, quick update!

I've switched back to the original tile perspective, and have settled on that. I implemented an extremely basic menu, which can be seen at the start (and will be improved later) and also implemented scrolling around.

To illustrate the scrolling, I made a quick video:

EDIT: The scrolling is actually smoother than the video makes it look. You get the idea, though.

Well, I may be talking to a brick wall but I'll keep going anyway!

Tonight's work involved reorganising some of the code in order to accommodate 'levels', as such - without getting too technical, the previous updates had the tiles hard-coded into the game. As such, switching between levels would be quite difficult.

I've now got a level object that is external to the game code itself, which will make life easier down the road. The information for each level is simply held in a text file and is loaded up when the level begins. This makes it simple for me to create and edit levels, without needing to recompile my code every time I make a minimal alteration (such as the tile layout etc.)

To commemorate this momentous occasion, I made a Nintendolife level:

I'm still working my way through the basic code, but it's starting to shape up. It's becoming recognisable as a 'game', as such, which is nice to see - it's my first one, so I'm pretty much winging it at the moment. I'm dreading having something come up in the future that will force me to rewrite huge chunks of code, but I'm trying to anticipate what I'll need in the future to keep rewrites to a minimum. I think I should really sit down with pen and paper and plan out how the game modules will work and relate to the other modules sometime soon, too.

Hopefully I'll have some more progress soon!

I like it.

Thanks Void!

After a bit over a week of not touching my game (I went home to Australia for a short holiday) I'm back into the coding. I've added in 'characters' (no stats or anything like that just yet) that can be moved around the battlefield by clicking on them and then clicking elsewhere.

There is no logic to this movement at the moment - i.e. no restrictions on which tiles can be moved into, how far the character can move and the like - but that will be added once the game is more fleshed out, and the mechanics have been developed.

Looking good! I'll try to check the development now and then!

I see, I was wondering what happened.
And could we see a picture of these? And like I said on the previous page, you should probably decide on a setting first, and then creating the mechanics will be easier because it limits the number of reasonable type of thingies you can do.

Yeah, this. I would assume developing a game before writing a scenario would be like starting to shoot a movie without a script.

This is a dumb idea I've had for a while but this turn based strategy game should in fact, be about a development blog. It's so indie it would have to work.

Yeah, I can agree that it's dumb, but it would be classified as indie, so I bet it would get enormus amounts of praise for mocking the industry, or something, I really don't know, since the idea just doesn't compute to my brain.

He should just make the most nerd pandering game ever. The main enemy will be EA employees and your team will be random 8-bit ripoffs. And there will be a mindscrew sequence for no reason.

To some extent, yes, but I'm still working on the underlying engine rather than the gameplay (i.e. displaying graphics, handling keyboard and mouse input) so it's not so critical to have things fleshed out right now. I'm trying to think ahead so that those additions can be made fairly easily later on (e.g. to move a character around, you click the character then click the destination square. That calls a function that determines whether or not the destination square is a valid destination - checking for things like if it's already occupied, if it can be stood on etc. I've written the part that moves the character around, while the function - that does all the logic checking internally, and simply returns a true or false - can be written later once the mechanics of movement are figured out)

If I keep things 'modular' in that way, it's not too hard to add things in as the game is developed. Obviously I need a plan relatively soon, but I don't think it's a great idea to stick rigidly to the original game design without allowing for features to be added or removed, depending on how fun they are. Also, if I keep some modularity then it helps me with reusing the game engine for other games down the track if I want to do so.

I'll add some pictures or a video of the character movement tonight!

OK, firstly a couple of quick screens to show what happens when you select a character (in this case, the red box):

Once it's selected (left-clicked on), it begins flashing by fading to white and back to its normal colour:

If you left-click on another valid tile, the box will move there - my next step is to animate that movement (currently it just jumps to the destination).

Now this highlighting wasn't as trivial as it might seem - look away now if you don't want care for technical discussion!

So, to display the characters I clip the relevant frame from a large sprite sheet and stick them on screen in the appropriate location. All good so far. To achieve the flashing effect, there were two options I thought of. The first was to create a duplicate sprite sheet in which all of the character sprites were coloured in white. I would display the normal sprite, and then over the top of that I would display the white-coloured sprite with a time-varying opacity to make it flash. Not too hard, but it's a lot of manual work to update the "white" sprite sheet every time the "master" one would be updated.

The alternative, which I went with, was to have an automatic highlighter which was done by manipulation of individual pixels. SDL, the library I'm using, uses "surfaces" to show all the sprites. You have a master surface - the screen - and "blit" all your other graphics onto that screen. Once that's done, you update the game screen to the latest state.

So, in SDL, my character sprites exist on their own surface. Thus, to do the highlighting in an automatic way, I look at that surface and find all of the pixels that aren't equal to my transparency colour - i.e., find all of the pixels that make up the sprite (there is a background colour that SDL removes for the purposes of transparency, so I can overlay graphics on top of each other). Then, with another surface I created of a size corresponding to the character surface, I'd set the corresponding pixels to be white. This would then give the character sprite, and then directly on top of that I would have a copy of the character sprite with all of the pixels turned white. By varying the opacity of the top layer, I could make the character appear to fade to white and back. In theory, this would be fine.

However (there's always a however), in SDL, to do pixel manipulations you're required to "lock" a surface so that it's safe to read or modify its pixels on an individual level. Thus, I needed to lock the surface corresponding to my large character sprite sheet in order to figure out which pixels my overlay layer needed to colour in white. The locking and unlocking of a surface involves copying its contents from video memory to system memory, doing any necessary modifications and then copying it back to video memory - something that takes a lot of time. Thus, I noticed that when I had a character selected the game would run slowly due to having to lock and unlock the character sprite every time the game updated - I found this unacceptable.

To avoid this slowdown, I eventually decided to store all of the character sheet pixel information in a permanent array in memory. This means I can avoid locking and unlocking the character sprite sheet each time, greatly speeding up the game.

Long story short - I found a nice, automatic way of highlighting characters when selected that, while not as easy as I first thought, runs well and taught me a few useful things! (Which is really what one hopes for while coding).

As I said, next up I'll attempt to make characters 'walk' between tiles rather than just jumping there as soon as you click. Hopefully it won't be too hard, but I need to do some basic pathing logic (i.e. how to decide on the best way to get from tile A to tile B, while avoiding impassable squares and the like).

-With my massive eyes protruding from their sockets I say-
"I see..."

Haha - I did say it would be a bit technical!

OK, so I got some basic character movement working. Here's a clip to show you where I'm up to:

(As always, the frame rate of the video is much worse than in real life)

What you can see in the clip is me selecting the character (red cube), which starts flashing. Then, when I click on another tile, the cube runs over to it. I also scroll around and right click to illustrate changing the viewpoint.

Obviously the cube just makes a beeline for its destination square at the moment. I'll need to change that - it will eventually move from tile to tile on its way to the destination. However, as I mentioned last time, that requires some non-trivial pathing logic that I'm too tired to figure out tonight! Also, you'll notice at the end of the video that I move the cube to a water square - I'm just illustrating that I currently don't have impassable tiles set up (eventually, water tiles will be invalid destinations)

I've decided for pathing that I'll use Dijkstra's Algorithm. It's not the quickest pathing algorithm, but that's not a real concern since I'm not doing it in real time - however, it IS accurate (i.e. always calculates the shortest path between two points, which I require) so I'll run with it.

I'll report back how I go soon!

@Wheels2050 Dijkstra's algorithm? That seems more like something you would use in an RTS game.

It's suitable here, too - there may be better ones, but in my quick search yesterday Dijkstra looked OK. Dijkstra is certain to find the shortest path to any tile from any other given one, which is what I need - however, its low speed means than modified algorithms are usually used for pathfinding in RTS games where speed is a concern (the A* being one such algorithm, although I didn't look into it much).

I've pretty much finished coding up the pathfinding apart from a quick couple of changes that I'll make over the weekend. Once that's done, I'll be ready to do proper character movement! (i.e. click on a character, and all squares within that character's movement distance will light up - then any of those can be selected for movement to!)

I see.
_{(And you'll see me saying this alot. )}

Haha, no worries - I'm half doing this just for my own records!

So some success in the last couple of days, I've (almost) finished implementing the Dijkstra path finding algorithm. All I've got left to do are handle some cases where my algorithm will currently break - which is easy, I just need to code it up - and the pathfinding should be good.

I'll put up a video soon, but you can currently select the cube and select a destination tile - the cube will then move to that tile by walking through the tiles of the grid, avoiding any impassable regions and the like. It's working really nicely, so I'm happy about that.

I was pretty tired this morning, so my first attempt at that was a bit buggy and not that neat in terms of the coding. I had another go at it tonight and cleaned it up, in addition to fixing the bugs.

I've also implemented a method of incorporating information about a tile's properties (e.g. if it is able to be moved into, or has edges that can't be crossed) by including a little symbol in the original bitmap. By doing this, I'm less likely to encounter bugs than if I was to keep a separate database of the properties of each tile in the software - this way, when I edit the graphics for each tile I can update its properties as I go. It's easier then to make sure that the properties for each tile match up with what I think they should be.

So how's you're progress so far? Or have you been too busy with other things?