Peons – Conclusions

Well time is almost up, deadline is tomorrow, but since I don’t plan on adding major modifications to my code,I’m going to wrap this up tonight.

Implementation wise this was a nice experience, javascript is definitely a versatile language mostly because it enforces little to no restriction on the code. Unfortunately this also means that this responsibility falls on the programmers’ side. Now in a reasonably sized project that doesn’t have to be split into components this wouldn’t be much of a problem because you’ll most likely have all the information you need in local scope, there’s no need to share information across components. However things get a little interesting when you need to juggle information from one scope to another.

Someone once told me that in this line of work you need to have an iron will to resist the urge of taking the easy way out when implementing a feature. He was talking about hardcoding, but the same principle applies here. Basically when confronted with the problem mentioned above, at first I tend to believe that I took the correct approach in the form of a hierarchical state machine with two layers, the main program that “knows” everything and commands the lower layers based on information received each iteration and then there’s the components.

The peace lasted until I had to implement the AI when my determination to do the right thing was shattered into little pieces when I realized it would need about the same amount of data the first layer had, so I fell into the dark side and took advantage of the fact that javascript assumes a global scope for every variable unless specifically told not to by declaring them inside a function block.

Overall the game runs smoothly on every hardware I tried it on including a HTC Desire (1 Ghz) and a Intel Core 2 Solo (1.4 Ghz) by which I mean that it’s probably safe to assume that it will run smoothly on most hardware (if not any) that can run HTML5, but that is most likely the merit of the great teams that work to make javascript blazing fast rather than my own seeing as the AI uses a plain B* algorithm for pathfinding and the position for a wall is computed by running 98 passes for each available wall position, but overall I’m happy with the result.

Unfortunately there are two other features that I didn’t have time to add, but I felt would have been interesting to have in this prototype mainly a minimax to provide a bigger challenge (the AI isn’t moronic, but it’s not really that hard to beat either) and the possibility of playing over a network.

Now until I find a reliable way for everyone to download the sources, they are available upon request from me, so just drop a comment telling me where you’d want me to send it.

Short Version

Javascript is nice, this project was a good learning experience, if you want the game leave a comment telling me where to send it.

Peons First Iteration

Well as expected this project wasn’t that big or hard to make, so the core mechanics are now implemented.

The fact that I coded this in HTML5 really did help a lot, more so because of Chrome’s built-in javascript console that showed me where I got something wrong, but having to code this in javascript was a bit let’s say tempting. It’s very easy to hardcode and rely on global variables for everything, but in the end I think I got it (mostly) right.

Anyway with the UI and game mechanics out of the way it’s time for the AI and maybe some flashy stuff.

I won’t release a beta just yet, but I am however going to tease you with some preview screenshots and possibly a video on youtube showcasing the functionality later on.

PAWN_Block

I guess it’s my turn to write about the technologies I’ll use for this month’s theme.

When I first stepped into the world of game programming, the very first tool I used was Dark Basic Professional which taught me allot of the skills that I know use. Soon after, I switched to DarkGDK, a powerful, yet simple, SDK that focuses on Game Development, in order to learn C++. With the AID of DarkGDK I developed allot of games and prototypes through out the years. Heck, thanks to it I was able to prototype an FPS game which got me my current job, so I think I owe it to “TheGameCreators” to use their Tool for this months theme.

My current goals for this challenge are simple: Keep it clean, keep it simple, make it shiny in the end. I plan on writing clean, and heavily documented, code which can latter be used by anyone in their projects. Since DarkGDK mostly wraps “complex” DirectX functions and handles most of the messy stuff, I find it to be a perfect tool for prototyping, allowing me to focus more on the Design aspect of the challenge. Another bonus is that it’s functions are pleasant to the eye and can be easily followed by anyone, so my source code will be accessible to all.

My IDE of choice is Visual Studio, a good friend in need and a perfect “lover” for when I’m developing on the Windows Platform. Besides the IDE, I will also use Paint.NET, a free and Open Source, image editing software in order to edit, or create, the sprites and tiles that I need (maybe create, since I’m kinda planning on using the tile set provided by LostGarden [dot] com for their Cute God challenge).

As @Radu said in the previous post, I too plan on releasing another Work-in-progress post, maybe near the end of the week, with screen shoots and previews of the game. Till then, I’ll leave you all with a, first, screen shoot of what has been done today, just to be one-step-ahead of him. Enjoy.

 

 

Peons Initiation

Like @zapakitul said it’s time for a followup with the technologies used for peons

I was always curious about the capabilities of HTML5/WebGL so that’s where I’ll start. Based on what I have seen up until now it’s pretty much a great framework for rapid prototyping because with a bit of careful coding you can basically use the same code for a wide range of devices like notebooks, mobiles etc.

I’m also going to use some functions provided by Phonegap to make the porting process as easy as possible

And last but not least, I tend to think that the IDE you work in is about as important as the technology you choose to use and after some consideration I settled for FlashDevelop because it’s lightweight and pretty much straightforward.

I’m probably going to do a second follow up as I implement the game to share my experiences with these technologies, but for now let the coding begin.

Peons

The theme for this month is: Peons. Both of us have to design a game revolving around moving a peon (one per player) on a board. Further details, and rules, bellow:

Settings:

The game takes place on a 8×8 board.

Between any 2 tiles there is a groove.

On the board there are 2 peons.

On the side there are 14 walls.

Rules:

There are 2 players, each controlling one peon.

Each player starts out with 7 walls.

The players take turns during which they can:

            o Move the peon

            o Put a wall in a groove

Each player must make a move during their turn

A peon can move one tile each turn.

The peon can only move in 4 directions (up, down, left, right, no diagonals)

The peon can only move on a tile if there is no wall between his current tile and the one he wants to move on.

Each wall blocks 2 tiles at once.

Walls are not allowed to block peons completely (players must still be able to reach the other side after putting down a wall).

The first player to get on the opponent’s side wins.

All contestants are free to add other gameplay elements in order to spice the game up with further challenges, but the basic set of rules must be applied. Both me and Radu will write a follow up post containing details about the set of tools we will be using. All that’s left to say is: “Challenge Accepted“!

And here’s a quick mockup concept:

The mock up concept is using tile graphics from the CuteGod prototype challenge.

Break Design Challenge

Break Design Challenge is a game design challenge between me (@Zapakitul) and Radu Chivu (@Radu_Chivu). The AIM of this competition is to develop, on a bi-weekly basis, a game prototype based on an idea/concept that we choose.

1. Both games are to be designed after work hours.
2. The theme of the challenge must be chosen before any actual work is done.
3. The tools used by each individual must be specified beforehand.
4. Both games and their sources are to be released at the end of the challenge, regardless if they are completed or not.
5. A post-mortem article must be written and released.

The idea is to challenge and develop our creativity while tracking our progress. Everyone is welcomed to participate and submit their own game prototype, as long as they adhere to the rules specified above. Any tools, sdk’s, api’s and GFX can be used as long as the license for the respective asset allows the contestant to do so.

Tomorrow we will post the Theme for our first contest, as well as details regarding the tools that we shall use.