Blog for Gary Preston at GarageGames.com

Shelled! Online Soft Launch

Gary Preston — 2008-06-27T15:40:58+00:00

I'm proud to announce the soft launch of Shelled! Online to the GarageGames community. This is your opportunity to get your hands on the game prior to the official public release in a couple of days.

Complete single player missions to test your skills, then compete online with other tanks in 6 different multiplayer game modes.

Custom design your tank for battle online:

Forums are now available for discussing Shelled! Online, organizing a game, or just bragging about your long range mid air kill ;) Feel free to report bugs and technical issues in the forums or here as well.

Shelled! Online 2.0.0 - Download Now!

Shelled! A Postmortem

Gary Preston — 2006-12-17T23:38:12+00:00

This postmortem is also available as a PDF for those that would like the original formatting and image captions. For the rest I've done my best to retain the formatting in the below blog.

As I'm also planning to post this on my blog too, please forgive any explanations that seem obvious to GG regulars.

Shelled! A Postmortem - By Gary Preston

"Shelled! is an artillery combat game in full 3D that allows up to 8 on-line players to blow each other to bits! Fire a variety of earth-moving explosive turtle shells including nukes, spreads, and more! With classic Scorched Earth inspired game play" - www.shelledgame.com

RedThumbGames began development of Shelled! in January 2005, I joined the team roughly four months in with Shelled! not only being my first TGE based project but also the first real game I'd worked on. The prospect of getting my teeth into a real project was both exciting and at the same time very daunting.

THE TECH

Shelled! was developed using the Torque Game Engine (TGE). For those not familiar with TGE, it's a C++ based engine (some Asm) along with a custom scripting language known simply as "Torque Script".

Torque Script takes a little getting used to, not in terms of its language which is very C like and easy to pickup, but its tight integration with the engine. This integration turns out to also be one of its strengths, if your game were a house, the engine would be the bricks and Torque Script the mortar that holds everything together, the vast majority of our game play logic was script based.

The script code runs several times slower than C++ code despite being compiled to byte code on first use, thus first reactions would be to bypass it and code everything in the engine. This would be a mistake, the productivity gain scripting brings should not be underestimated. It's quite surprising just how much you can script without any noticeable performance impact, besides, it's always possible to move the more demanding script code into the engine during an optimization phase.

That isn't to say Torque Script is perfect, I'm sure most people that have worked with it could come up with a list of extra features they'd like to see, then again you could say that about any engine/development environment.

A few months after joining the Shelled! team I was made aware of Torsion, an IDE created for editing and debugging Torque Script by SickHead Games. Without doubt productivity increased considerably. For debugging ease alone, I'd strongly recommend that anyone working with Torque Script evaluates Torsion.
It really goes without saying how critical source control is for any project especially those done remotely. We used CVS for most of the project switching to SVN nearer the end.

During the last few months of the project we also setup Mantis for logging all reported bugs from the latest beta test. In hindsight we should have had mantis up and running from the start. The effort in co-ordinating who was fixing which bug and whether a bug had been fixed or not was greatly reduced. It did take a little more time up front to get bugs logged, but the later time savings were more than worth it, even more so if your project team is split across several timezones.

WHAT WENT WRONG

OUT FEATURE THE COMPETITION

From the off Shelled! had a clear goal, to recreate the fun factor of the classic Scorched Earth game in 3D with simple controls and game play. Early on we lost sight of that goal.

Several months into development the game had it all, flying tanks, deformable terrain, loads of weapons, various planets sporting different gravity levels, tank power ups and a wind system that would occasionally change direction and affect shell trajectories, to mention but a few. What we didn't have, was accessible game play.

The game was too cumbersome, it had too many options, the number of clicks needed to go from loading the game to actually firing your first in shell in anger was bordering on the insane. Selecting a level required setting min/max bot skill level, min/max wind speeds, fixed or varied wind direction, planet gravity, terrain type, allowed weapons, points/money for kills and a host of other options that whilst some may find useful, for the majority it was just over whelming.

Looking back it was hardly surprising the early versions of the game met with an amount of criticism during the first public viewing. In short order the game was ripped apart and just about every major feature ripped out and game controls overhauled. The user interface was stripped and reduced to a fixed set of simple options. Now the user could get from main menu into an actual game in just a few clicks.

LEARNING CURVE

TGE is a sizable chunk of code, the learning curve of which is fairly steep. This steep learning curve was compounded by my initial mindset of wanting to understand how everything worked before making changes. This is probably due to my Information Systems background, where significant time was often spent understanding new systems before any changes were made.

With an engine like TGE this wasn't feasible. Not only due to the sheer amount of code, but also because understanding much of the code requires that you already have a grasp of several concepts unique to the game domain.

Once I'd shaken off the need to understand everything and instead focused on only code in the immediate area of concern, I found my overall knowledge of the engine increased at a greater pace.

CODE WHAT YOU NEED, NOT WHAT YOU THINK YOU MIGHT

A few times whilst adding support for a specific feature I would catch myself over analyzing what was needed and looking for a "perfect" solution that not only supported the current task but also allowed easy expansion in the future. On the surface this isn't a bad thing to do and in moderation can be very useful. However, when you try to be too flexible or always look for the "best" way to do something, you can end up spending hours/days longer adding a feature that will also support XYZ only to find you never needed X let alone Y or Z. All that extra time making it flexible was for naught and the extra fluff may have reduced the readability of the code. Even worse, you may find the feature gets cut a few months down the line.

Coding only "what you need" became an important lesson for me and fortunately one I learnt very early on in the project. Should a feature later be required, then, at that time and not before, refactor and add the new feature. In pretty much every case the flexibility I thought we might need later was never the case and in most cases features were later scaled back or dropped.

USABILITY TESTING

We left it quite late in the project before opening the game to a wider audience of testers. By which time a number of features had been fully implemented and final artwork put in place. Only to then discover the intended target audience for the game were overwhelmed by the amount of options and general control scheme.

High quality artwork was thrown out and the theme changed to a more cartoon style, but the changes didn't end there. Feature after feature found itself mercilessly cut, some of which had taken considerable time to implement over the previous months.

This kind of design change can be minimized by prototyping up front (lesson learnt) however even with prototyping, games are creative works and will under go changes throughout the development life cycle. Features may be dropped due to feedback from testers or cut due to budget/time constraints.

Such a major change in direction so far into development was a hard to do, but once the dust settled and newer "cartoon" style artwork was in place the Josh's decision was vindicated and the game really started to finally come together. Had we not followed the "CODE WHAT YOU NEED" rule, this cutting of features would have been all the more painful.

In hindsight we should have prototyped the main features of the game and done a wider form of testing with people from the target market rather than relying on our own opinions.

CROSS PLATFORM SUPPORT

TGE is a cross platform engine that works on Windows, MacOS and various flavors of Linux. In the early days of development, Shelled! compiled and ran on all three. However it wasn't long before development focused entirely on Windows with the intention of bringing Mac/Linux up to date at a later time. As development neared an end, we had a game that no longer compiled let alone ran on the Mac nor Linux. Bringing the game up to date on those platforms probably wouldn't have taken too long, but it was time we no longer had.

In hindsight we would have been better off keeping Mac and Linux builds up to date either after each feature change or at regular milestones. The time it would take to resolve issues just after a feature change whilst the changes were still fresh would probably have been lower than the time it was going to take to resolve everything a year or two later at the projects end.

In addition testing of new features could have been completed on each OS throughout development, by the end of the project even if we ported the game to the Mac and Linux we'd have been left with a sizable amount of feature testing to do. Any major platform bugs would have then caused a significant delay, where as the same bugs found during development could have been resolved by bringing in a Mac/Linux programmer to work in parallel.

As a result, Shelled! has only been released on the Windows Platform.

AI

I guess this doesn't really belong in the "what went wrong" category, more in the, "if we had more time" category.

With the main emphasis on network play the AI took a bit of a back seat. This becomes quite evident in that the AI will only ever make use of the default shell type. They're incapable of purchasing and making the decision as to when to use different shell types.

Artificial Intelligence is a fascinating subject with a number of techniques that would have been worth investigating for use in Shelled!, time however was not on our side.

NETWORKING

Shelled! is mainly a multi player game and unfortunately one key problem is the requirement of users to have ports open before their "hosted" game will appear on the master server. Although many AAA games have this problem, they also have such a large pool of players that its almost a given that a sufficient proportion will know how to forward a few ports to let them run their own servers.

Unless your game is aimed at hardcore gamers we cannot assume this level of technical knowledge. There will of course be exceptions, but can we count on that? One potential problem being players download the game, click on-line play and see no servers, so they click host and sit playing the AI for a while then decide nobody else is going to join them and quit. It could be that a number of other players were doing the exact same thing and yet none of them were aware of each other.

This could be addressed through running a few dedicated servers but ideally we should removing the need for the end user to worry about port forwarding at all. With UDP packets and the co-operation of a master server, it's possible to traverse firewalls and NAT'd connections. Several methods are available but we didn't have the time needed to investigate and implement any. I believe TNL has an implementation ( used by ZAP!? ) a feature that would make a worth while addition to TGE for future projects.

WHAT WENT RIGHT

COMMUNICATION

Communication on remote projects is problematic at the best of times, but add to that an 8 hour timezone difference and incompatible working hours making real-time communication impossible within any kind of reasonable hour and the potential for problems increases.

The alternative, Email and IRC. This wasn't as bad as it sounds, we had a paper trail of feature requests and bugs fixes, in addition feature requests were clear and concise which greatly reduced the chance of differing interpretations.

FAKING IT

The initial implementation of the Tanks and Jets attempted to model forces such as jet thrust, wind, gravity and surface friction amongst others. It quickly became apparent that implementing "realistic" physics (as realistic as flying, nuke wielding turtles can be anyway ;) was simply getting in the way of the game play.

A few people have commented that they liked the physics in Shelled! and yet under the hood they're very unrealistic. Aside from simulations, accurate physics are not that important so long as the implementation "feels" good it shouldn't matter whether you have a cool rigid body simulation that takes into account thrust/mass/gravity or simply a set of fudged numbers.

One example of this is the initiation of flight, the original jet thrust gradually accelerates the tank upwards. However, in the final build we went instead for an instantaneous velocity followed by a gradual acceleration that tapered off quickly. This was done to allow tanks to exit craters quickly yet limit the final height they could achieve.

Another area where game play came before reality was the way tanks conform, or more specifically do not conform to the terrain. This was done for two reasons. First, having a fixed level platform made the AI trajectory calculations easier. Second, and of greater importance. The concept of "trajectory" based game play, getting players to aim above a target rather than directly at it, was already a hard sell for our main audience of players. We'd have only complicated matters if tanks could come to a rest angled against a cliff face and the player suddenly found themselves having to move left/right rather than up/down aim higher or lower.

We didn't want to be "too" apparent that we'd taken this approach and landing a tank on the top of a spire made it obvious that we'd faked it. Again we fudged it, instead of tumbling off the spire we applied a small force in the direction of the largest overhang to push the tank clear. Accurate, no, but it did the trick.

COMMUNITY RESOURCES

These were a mixed bag. On the one hand, we saved quite a substantial amount of time and effort by leveraging the work of the community, however, we also lost time tracking down and fixing various bugs in the resources, many of which went unnoticed for some time. In several cases the resources were later removed in favor of custom code. Although we still saved time by initially using resources to quickly test a concept and as a basis for more customized code.

Notable exceptions that remained in the final build were resources such as Ben Garney's Commander Map and Stephan Zepp's terrain deformation code both of which saved us a great deal of research and implementation time. Neither resource remained untouched however, we made substantial changes to the terrain deformation code to tailor it to our needs. Such as ensuring any objects in the vicinity had their cached collision sets invalidated to ensure they fell into craters. We also added a crater impact texture and abused the "updateGridMaterials" code to play nicely with tiled terrain.

The Garage Games community as a whole
are a great asset to the Torque Game Engine. Both in terms of supporting each other through forums and IRC as well as taking the time to produce resources, which, when carefully selected can greatly aid development.

JOURNALING

Once again the choice of engine paid dividends. TGE has the ability to record and play back demos of your game to help remind other gamers of how you gracefully nuked them out of existence, however, a less commonly used feature is journaling.

Journaling records all the input the game receives whilst running allowing a game session to be replayed again at a later time, but unlike a demo, you can replay the session from within your favorite debugger. If beta testers are having strange crash bugs that you can't reproduce, make them play the game with journaling enabled and send you the resulting file. Fire up visual studio and replay the journal in debug mode, go make a coffee and when you come back the debugger should have broken out just before the event that causes the crash to occur.

Journaling helped track down several major bugs within Shelled! Although we never needed beta testers to send in a journal file, the option was there and would also help remove any ambiguities that an emailed bug report could contain.

NETWORKING

Using Torque allowed us to make full use of its great networking support. There were a few teething problems but these were more down to inexperience with the networking side of the engine. We also spent a little time testing Shelled under fairly high packet loss and latency's of up to 200-350ms, with only one exception, the game still played well. The exception being the purchase screen which was re-written to use client side predication based on the clients last confirmed Cash amount.

CLOSING THOUGHTS

When things go wrong, you find yourself having to work even harder to solve the problem. That extra effort tends to make those events easier to recall. I believe this is why a lot more appears to have gone wrong with the project than right. In reality the two were probably well balanced, mistakes are just easier to remember.

What I personally took home from the project (aside from a neat Shelled! branded mug) was a deeper understanding of the engine as well as a greater appreciation for what goes into making a complete game, although I still feel like I've only scratched the surface of TGE in many areas. Perhaps most importantly, I've realized just how much I didn't know I didn't know about game making ;)

Did we manage to make a fun game? I think we did. The final decision is of course up to the players, head on over to www.shelledgame.com and give the game a whirl.

Gary Preston
Lead Programmer

PROJECT VITALS

Development software: 3D Studio Max, Visual Studio.net 2003, Subversion, Mantis, Torsion
Engine Used: Torque Game Engine
Development Hardware: 2.8GHz HT P4, 1Gig Ram, 256Meg GF6800
Release Platform: Windows

Length of Development: ~2 years
Avg. Programmers: 1-2
Artists: 1 (for part of project)
Release Date: 14th November 2006

Free Download: http://www.shelledgame.com

VGCore Score: 8.8 / 10
VGCore Review: pc.vgcore.com/reviews/445.html
Game Tunnel: www.gametunnel.com/gamespace.php?id=306

GID j - Black Pixels

Gary Preston — 2006-04-10T01:03:30+00:00

NOTE: Full write up can be found on my blog, see end of post for links to the blog entries.

Originally I had planned to do a TGB based GID however Tom mentioned I should do an XGS GID at some point on irc and I thought what the heck.

A GID is hard enough to complete when you know the toolset you're using so I thought I'd have to scale back my goals and I mean really scale back. The goal, to display a single pixel on a PAL tv using the XGS game console. This would probably prove to be quite a challenge considering my limited knowledge of the XGS hardware (zero knowledge of the video hardware) and very little experience with the SX52, but it sounded like a fun challenge.

For those that havn't heard about the XGS, its a console with the main purpose to learn the details of how hardware works and ways of designing game consoles. At the heart of the XGS is the SX52 microprocessor capable of running at a whopping 80Mhz with 292bytes of RAM and 4k EEPROM for program storage. (The XGS has an extra 128k SRAM onboard but that was beyond the scope of my project since I didn't have time to learn both the video hardware and SRAM hardware interfacing).

Plotting a pixel doesn't sound like too hard a task, but then the more I read about how the video hardware worked, the more I realised that perhaps I hadn't scaled my goals back far enough. With the XGS you create video in software, by that I mean you have to generate the waveform that is sent to the TV eg this:

in code.

Generating this signal involved counting the cycles each machine instruction would take to execute and knowing that one cycle @ 80Mhz takes 12.5 nano seconds. So by counting clock cycles and adding extra instructions via lots of loops/nops you can get very accurate timing, although the counting proved tricky with a few cycles out resulting in the follow TV output

Still after a lot of reading (mainly the SX52 manual :P) I managed to get a filled yellow TV screen and with a little more tweaking a nice yellow block in the center. The image I captured is very washed out, you'll have to trust me that it does look yellow on the tv

This in and of itself caused a few headaches since to generate the block I did what amounts to an IF in asm and checked whether the current scanline was greater than 97 but less than 109 in which case we could output the colour yellow, otherwise output black. The problem been these two < and > tests introduced 3 branches into the code and with timing been critical down to the cycle I had to ensure all 3 branches took exactly the same amount of time to execute, which resulted in the following ugly code:

    ; black for 141 pixels (2037 cycles) and color for 12 (174 cycles)
    mov RE, #VID_BLACK                ; 2

    ; color for 12 pixels (174 cycles)   
    cjb scanline, #97, :skipcolor1        ; 4/6
    cja scanline, #109, :skipcolor2   ; 4/6
    DELAY(2037-10)
    mov RE, #TEMP_COLOUR                            ; 2 setup pixel colour 
    jmp :color                        ; 3

:skipcolor2
    DELAY(2037-12)
    nop 
    nop
    jmp :color                        ; 3
:skipcolor1
    DELAY(2037-6)
    nop 
    nop
    jmp :color                        ; 3
:color
    DELAY( 174-5 )

    ; black for 141 pixels (2037 cycles)                           
    mov RE, #VID_BLACK                              ; 2 setup pixel colour 
    DELAY(2037-6)            ; inc following jump

    djnz scanline, :scanline_loop   ; 2/4 (extra 2 from 4 is unaccounted for!)

It's late and I'm sure the final code (which I think amounts to about 374bytes) will probably have plenty of bugs, but the end result is a nice yellow square on both my TV and PC digital TV card. So on the whole everything seems to be working and in sync.

A much more detailed coverage can be found on my blog including a few extra screendumps of the debugger and the final source code if you're interested.

The one thing that doing this GID has really taught me is how skilled the original Atari 2600 programmers must have been, I have a whole lot of respect for them.

Blog entries:
00101010.figmentgames.com/2006/04/07/gid-j-black-pixels/
00101010.figmentgames.com/2006/04/08/gid-j-attempt-1-snow/
00101010.figmentgames.com/2006/04/08/gid-j-delay-debugging/
00101010.figmentgames.com/2006/04/09/gid-j-signal-generation/
00101010.figmentgames.com/2006/04/09/gid-j-mission-accomplished/

PS For those wondering why "Black Pixels" and not "Yellow Pixels" go search for a blog about "Black Triangles" :)

Monday Jul 18 1:13

Gary Preston — 2005-07-18T01:13:58+00:00

GID#14 entry Ghost Hunter. A T2D game which takes place within a haunted house (although you'll have to take my word for that since it's decorated with programmer art :P ) teaming with ghosts.

Over the last weekend I've been updating my personal blog with details of my GID#14 entry Ghost Hunter. Rather than reproduce the whole thing here, I'll just point anyone who interested in reading about the development to my Ghost Hunter blog entry. Below is a quick summery for those not intrested in the blog.

Ghost Hunter is a T2D game which takes place within a haunted house (although you'll have to take my word for that since it's decorated with programmer art :P ) teaming with ghosts.

The player has a deployable trap that once deployed and activated will suck nearby ghosts into it. The trap holds a limited number of ghosts requiring a trip back to the ghost hunters van for emptying. Emptying the trap will score the player points. Trap all the ghosts without dieing to complete the level and game.

The games available on Linux and Windows (no mac as I don't have one yet). There's an avi for any mac only users, just so you know you're not missing anything good :)

WindowsGhost2D.rar (1.4meg)
LinuxGhost2D.tgz (1.7meg)
View the .plan for this GID entry
GhostHunter.avi

The game itself was quite fun to implement, its just a shame its not all that interesting to play. Still the aim of GID is mainly fun. I think anyone that has an idea for a game should GID it, you'll find out in a short space of time whether your idea really does have sound gameplay. Plus if you can't implement a very basic cut down version in a GID you might want to rethink implementing the full blown MMORPG version :P

Anyhow, I hope some of you check out my blog and leave comments, it will save me having to make up names and posts :/

Monday May 9 22:26

Gary Preston — 2005-05-09T22:26:55+00:00

Saturday 7th May marked the start of GID#12 which I've been looking forward to all week. Unfortunately I was out all saturday night and by the time I crawled out of bed sunday, it was already around 12pm. Since hearing about GID I've managed to miss every event and was determined not to miss this one, even if I only had 12 hours of sunday left to GID in.

Saturday 7th May marked the start of GID#12 which I've been looking forward to all week. Unfortunately I was out all saturday night and by the time I crawled out of bed sunday, it was already around 12pm. Since hearing about GID I've managed to miss every event and was determined not to miss this one, even if I only had 12 hours of sunday left to GID in.

The theme was augmentation, although after about 5 minutes thought I decided I didn't have time to think of a game that would fit the theme. I've wanted to create a turn based strategy game for some time, so I decided to prototype a greatly simplified version. If any of you have every played Konquest that ships with KDE, you'll have a good idea of what my aim was :) At a pinch you could say that your augmenting the neutral planets with your fleets :P

Originally I was hoping to have AI in the game, or networked multiplayer but due to time constraints I ditched those ideas and instead planned on a 2 player (via same computer) only game. The rest of this plan covers the development of my first GID, which even though I did it solo, I have to say I had a lot of fun :)

Linux and windows downloads can be found at the bottom of this plan. Just wanted to add a quick thanks to everyone in the gid irc channel for an entertaining weekend.

1pm - Sunday

Having decided on creating a T2D version of Konquest, I set about creating the main game area. First stop, a quick background created with "The Gimp" (and when I say quick I mean it :P). Amazed by my work of art, I took a well deserved break and had sunday dinner. (Apologies to any artists out there who take offense to me calling my images "art" :P)

14.30 - Sunday

Having spent all of 5 minutes working on Conquest-T2D so far, it was time to get back to work, right after a quick cup of coffee (this happened a lot). I spent a little time adding some neat planets that bear a striking resemblance to an asteroid. I also added a dynamic tile map and populated it with a planet(asteroid) for each player and 5-10 random neutral planets along with a GUI to provide info about the planets.

The planets are all stored as a simset within a galaxy script class. Whilst doing this, I realised I didn't know torque script quite as well as I thought and ended up spending some time reading through the various script resources.

17:45 - Sunday
With the galaxy/planet datastructure complete, planets now had randomly generated production, name, position and fleetsize stats. Two planets were randomly selected to be the players home planets and their starting stats matched. I spent a while making sure the code supported as many players as you want by simply changing a single $Game::MaxPlayers variable, however I never managed to find time to make a gui for selecting the number of players and entering names/player colours, so its stuck with 2, even though the support is there for loads more.

The next screenshot shows the state of play at around 8pm. By which time I'd added mouse selection of planets and display of planet information in the info gui on the right hand side of the screen. I had planned on making a random name generator for the planets, but time got the better of me, so planets ended up been called "AAA1", "AAA2" etc

21:00 - Sunday

Most of the work for the next few hours was spent adding the background game logic. It was around this time I realised the game needed to support multiple orders from the same player in the same turn and ended up going off on a tangent creating an orders list class for each player as well as a order class. Players could now issue as many orders as they wanted, sending their fleets off to colonise or attack any planet on the map.

2am - Monday

I'd spent the past two hours working on the game logic for combat. This was much simpler than I'd expected, mainly due to the way the planets were organised in the galaxy datastructure. The final version of the turn end order processing isn't really fair, since player 1 always has his orders processed before player 2, but it will do.

The final game play element needed before I headed off to bed was the victory condition check. If any player has 0 planets left at the end of a turn, they may have lost. However, an additional test was needed to check whether the player had any ships en-route to another planet, since those ships could feasibly result in the player having a planet again next turn.

12:00pm - Monday

With the game now playable, all that was really left to implement was delayed fleet movements, so that ships take a number of turns to reach a destination planet, depending on the distance from their origin. Most of the day however was spent tidying up the look of the game. I added a few programmer art planets, as well as blended a square of the players colour around player owned planets and a grey square around neutral planets. I also spent a bit of time reading up on the GUI in Torque, which up to now I've pretty much avoided using. The game looked a whole lot better with coloured player names and a splash screen/main menu.

All in all the game took around 16-18 hours over sunday/monday, probably less considering the number of breaks I took. Lesson for future GID'ers, GID + TV = BAD!!! :) Overall I'm pretty happy with final game, it's playable even though it's far from finished. Its missing computer controlled players, networking support, decent graphics/gui and better game play rules. Another few minute work and I could have modified the end turn button to make it fit in more, but there are lots little changes that could be done. Perhaps in the future I'll revisit this and add in network support along with a gui to select number of players :)

The only dissapointment was that I didn't have time to create a better combat system, instead I ended up making combat boil down to the player with the most ships at the planet wins that fight. However finishing a GID is a great feeling :) So all in all, I'm a happy programmer and can live with the games shortcomings :)

Anyhow, heres a few final screenshots.

Game Download
www.figmentgames.com/downloads/gid12/linux-conquest.tgz Linux Conquest - 1.6Meg (tgz)
www.figmentgames.com/downloads/gid12/windows-conquest.rarWindow Conquest - 1.3Meg (rar)

Tuesday Mar 15 18:52

Gary Preston — 2005-03-15T18:52:21+00:00

Well I've had T2D for a week and I have to say I'm impressed with what it has to offer. I'd rather not bang on about all the cool features it has, such as how it handles tile maps/physics/collision detection and does pretty much anything you'd want a 2d engine to do. You can read all about that in the reviews on the T2D page. So instead I'll just point you to my first game made using Torque2D.

It's nothing special, just a clone of the classic pong game. What did impress me was how easy it was to get a complete game (even one this simple) done without knowing torque script up front. I think its a credit to the reference docs and basic tutorial :)

Anyhow, the game took less than a day to complete, which included learning how to use T2D. I spent a little time on day two tidying up the code and trying to do things in a different way.

I'm now working through making a simple pacman clone, well at least working on it inbetween improving my maths skills and playing eve-online :P Hopefully I have enough knowledge of T2D by the time I've completed pacman to make a start on a small 2d project :)

Controls are W,S for player 1 and cursor up/down for player 2. Use space to launch the ball. Have fun :P