Messages

Well, it's part of my coding-style and I think it does improve readability.

Style is like taste, it's down to the individual. And in this case I think a good code-editor should accept all different styles.

God, I feel so stupid... Hehe, and I was wondering why my code wasn't working...

This is a really easy-to-make mistake though, and really, really hard to spot and correct, maybe it would help if the auto-helper text (which shows parameters, etc.) would show even if there's a space in between the last letter of the function-name and the opening bracket. It didn't show, because I always have a space there.

[EDIT: the one below (#1) is actually my fault. See posts below...]

Two tiny little glitches:

EDIT: the one below (#1) is actually my fault. See posts below...
1. when you feed DrawingSurface.DrawImage wrong coordinates, 'DS.DrawImage ( sprite.Graphic, -1, -1 )' for instance, the game crashes and reports "invalid sprite-slot number specified". This can be pretty misleading.

2. when I hit F1 while the cursor is on DynamicSprite.ColorDepth (somewhere over the ColorDepth-letters), the help page gives me a 404. This doesn't happen with any other elements, so I suppose there's a wrong link or something.

[Little update:]

Exactly. I'll investigate that, though. Thanks for the food-for-thought!

Little update: I'm currently working on a better shadow-system. If it fails, I still have the old one to fall back to (which was working and looking just fine already). What I'm trying to accomplish is getting rid of that shadow-overlapping-phenomenon - if two or more shadows overlapped each other with the old shadow-system, the overlapping part would be drawn even darker. That's not realistic, if shadows from one light (sun) overlap each other, they are not "added up".
      So, the new system basically consists of one empty dynamic-sprite that covers the whole screen. Every unit then draws its shadow (as long as its actually on the screen, of course) onto that sprite, which is then tinted to look like shadow and drawn. This way, if two shadows overlap, the overlapping part should be exactly as dark as the single shadows are etc. It's not there all the way, yet, but I'm pretty sure I'll manage to get it to work properly these next days.
      Also, I have changed the colors of the selection-marks, the health-bar and the selection-rectangle (which you draw to select multiple units), I wasn't satisfied with that bright-almost-white-look, they are now dark grayish, parts are almost black, plus the healthbar over selected units looks a bit "rounded" now. I don't want to post another screenshot this soon, but I'll make sure to show it off in the next image-material.
      Last but not least, I have started improving some sprites, the factory-building you can see on almost all screens looks better now.  You can see it has changed from the oldest screenshots to that newer one. Now it has changed even more, though slightly. I'll try to not only add new, but also improve existing artwork until it all looks as good as I think it should, even if it takes a lot of passes on some stuff.

I'm not too fond of that video-tutorial idea. Well, in the end it's "the more help, the better", but there's a flaw in the logic here: those users that aren't willing or capable of reading a small text on how to import characters and get started aren't really the folk we can use around here (remember, AGS isn't for everybody - it's not a simple click'n'play game-creator and doesn't try to be one). Will those patienceless users ever start reading the manual?

Since the map is static, draw it using three steps:
1. draw a sprite that's generated once from the level data, showing the complete map.
2. draw the units on top by iterating through them and placing the pixels at their respective map positions
3. draw another sprite on top to add the fog of war. This sprite starts out all black, is kept in memory and updated with transparent pixels whenever the player "removes" the fog of war in the game.
If the map isn't static, you only have to update a few pixels in the original map sprite. This shouldn't happen often, so again, the cost is pretty much zero.

That's exactly what I'm doing right now (for the latest screenshot, step 3 was commented out, that's all). The rest is already working in this way and really not a bottleneck for slow-downs anymore.

To improve trigonometric performance, use an array holding e.g. sin(0.01) to sin(1.57).
Then derive cos and tan. Reading a variable should be several times faster than calculating a trigonometric function.

Luckily, I get around without using trig-functions. What I'm doing is more like look-up tables than raytracing.

I've just taken a closer look at your screenshots and realised that your tiles are 25x25 while your map uses 4x4 tiles! That's unusual but luckily doesn't invalidate the suggestions I made.

That's the old screens (back when I had a "resolution" for the radar-map), at the moment I have 25x25 sized tiles on the main screen and I pick a background color on the radar-map for every single pixel on the map (100x100 pixels).

@HammerBlade:

I think I got what you mean, now. Fog-of-war does show up on the radar, but the background of the radar-map is always going to be drawn, because it's non-static, without recalculation, which is very, very fast. The units are really quick to plot as well, so I think it's actually faster to just iterate through existing ones and draw that pixel than it is to check for each one, whether it's under fog-of-war or not... That last part is what you meant, right?

Thanks for the feedback, everybody!

Use the File-functions to create a file (maybe called "config.cfg" or something) that stores the int-value of brightness the user chooses and whenever he changes it and starts playing the game, the game stores the value in the file. When the game loads, it loads the old value from the file.

Tell us if you need help working with files, but you should try it using the manual first, it's not that hard with the given examples in there.

Weeh, the thread was kicked off the front-page but came back, thanks a lot for that, guys!

Anyways, here's a new screenshot, notice the variety in the desert-tiles and the shadows, also, the flying units now have fire coming out of their thrusts when they move:

@HammerBlade: the problem with your suggestion (if I'm understanding it correctly) is that the radar-map has to be updated for the whole map and not only for what the player sees. Especially when units move around that are NOT in the player's view, it should show that movement on the radar-map. If you meant something else, do not hesitate to respond and clarify, please, I'm always open for ideas and I'm sure that I'm not yet doing everything in the best and most effective way.

@SSH: that's interesting and will definitely come in very handy once I try my hand at implementing the path-finder. I'm still concerned that it will run really slow though, but, as I said, the only way of finding that out is implementing and checking. At the moment, I also have another solution: I could allow the player to manually "draw" paths that the units will follow. This is not as good as a real pathfinder, but somewhat of a compromise. I'll try all different solutions out later in development.

Struct-within-struct support as well as pointer-to-struct support have both been discussed several times before, but AFAIK haven't really been feasible due to internal limitations. Hopefully this new version of the editor will have cleared some of that up.

Clearly pointer-to-struct support (with pointers-to-structs being allowed within custom structs of course ) would be the most flexible and powerful solution in this case. Perhaps now that CJ has finished his revamp of the editor he could take another look at the current status of this request.

I know, offtopic (mentioned before), but I just HAVE to throw this in once again: that above would be the only left part of functionality that I miss in AGS... big, big time. Although it clearly isn't necessary for most simple adventure games, especially the new OO-aproach to modules/scripts etc. would hugely benefit.

Anyways, coming back to the topic, I have two small additional ideas/suggestions:

#1: would allowing the user to overload functions like in C++ be possible? This would mean the coder can define functions with the same name where the parameters are different? This can always be worked-around etc. but it'd be nice to have. Example:

Code: ags

// in "Renderer.asc"

function CRenderer::DrawPixel ( int x, int y )
// draws a pixel
{
      // draw pixel using int-type coordinates
}

function CRenderer::DrawPixel ( float x, float y )
// draws a pixel
{
      // draw pixel using float-type coordinates
}

Again, I know this can always be worked around, but I'm just pointing out the elegance of such an approach, I realize this might be low-priority though...

#2: People have discussed different ways of structuring the Script-tree in the side-window thingie, my suggestion here would be to sort by type like this:

Code: ags

- Scripts
      - Script Files
            Renderer.asc
            Tile.asc
            Sprite.asc
            Particle.asc
            GlobalScript.asc
      - Script Headers
            Renderer.ash
            /* etc. */

This is how it's handled in MSVC 6.0 and it seems like a very clean and usable solution.

[Little update:]

Little update: I have been able to get some work done on the following aspects...

• improved radar-map (see first technical essay for information) - put short, it's not as blocky as the screens anymore, it works pixel-perfect for both units and terrain and it works faster...
  
  
• improved unit-movement - through a series of rather complex algorithms, units now move better in groups and shouldn't get stuck in each other or anything, this helps a lot in-game...
  
  
• units can idle now - every now and then (semi-random interval) they'll look to the left or right a little bit (they won't make a 180° turn for example, that doesn't look good, it's fixed to a maximum degree left/right, so they only move a little - they could make several full turns if you wait long enough though)...
  
  
• units can actually die now - well, currently they just disappear - I still have to think about how to realize explosions (or similar)...
  
  
• added some variation for the desert ground-tile - it looks a lot better now, no comparison to the old look at all, you'll see the difference in the next shot; when a level is drawn in the editor, the desert ground is calculated automatically and varied randomly, still (similar to the editor in StarCraft) you can change the look of single tiles if you want to force them to be one special variation...
  
  
• money- or resource-counter (right upper corner of the screen) now dynamically counts the money; when you gain "credits" it doesn't just show the new amount instantly but blends to that number by counting through the difference - for example the player starts out with 500 "credits" for testing purposes at the moment, when the game begins, the counter starts at 0 and quickly counts up to 500 and when the player builds a tank (costing 200 right now), it doesn't instantly subtract that amount but rather count down in like two seconds.
  
  
• started developing the editor - it can create new maps, load, edit and save maps which can be loaded by the main project already, eventually this will allow me to create more complex maps with more terrain-types, objects and little doodads.
  

That's the progress so far - concerning your questions about game-play, I'm able to tell you that I probably won't be able to add a real campaign (with scripted events etc.), because that would be very hard to store in the level-files, it's probably going to boil down to combat-mode only (you choose a map and play against one or more enemies) although it's possible that a simple campaign will exist in which you battle against an increasing number of increasingly good AIs (no guaranty though).

I can't promise that it'll play like StarCraft, Dune 2, WarCraft 3 or C&C 1 or any other part of the series for various reasons (pathfinding, complexity of tech-tree, application-speed etc.) just as you won't expect a common adventure made with AGS to play and feel exactly like a great top-notch commercial adventure-game such as Monkey Island 1 or DotT, but the core-elements are there and I'll try to make the best game out of the technical features that I can.

Once I have more features to show-off I might create a trailer-movie or something. I'm thinking about that because it could show off some of the work in real-time and some effects really don't show in static pictures.

[Little update:]

Little update: I have finished including shadows and air-units. This turned out really nice, actually. Take a look at this excerpt from a show-off shot:

You can see the tanks are flying at the moment...

It doesn't only look nice and adds a feel of depth, it also works very ergonomically - drawing these shadows doesn't require any new artwork or anything, the volume is created on-the-fly with a second dynamic sprite, the tint-functions and the possibility to draw images with transparency. Shadows "stack up" at the moment (when they overlap, that part of the shadow gets even darker) which is not really realistic, I think, but it actually looks nice and fine to me and flying units even throw shadows on ground units and buildings which is very important to create that sense of height and depth.

As I mentioned, it allows units to fly (well, it only shows they're flying if there's a shadow) - the units actually move up or down a bit every now and then as you might have noticed they do in games such as StarCraft to emphasize their height and how they hover.

Of course, flying units will not collide with stuff on the ground (terrain stuff such as slopes or trees and bushes) or units and buildings on the ground, however they still collide with other flying units - logically.

I will actually allow players to either turn shadows off (for slower machines, should increase performance when controlling lots of units), make them absolutely black (which will be slower than the previously mentioned option, but at least a bit faster since the game doesn't have to draw the shadows with transparency) or to have them look realistic (which is what you see in the shot above, the slowest but best looking option). Shadows aren't that expensive, though, on my somewhat dated machine (P4 ~2.5GHz, 6 years old) they don't slow down that much in comparison.

What do you think? Any other ideas for effects or functionality? Do the shadows seem good to you? Any feedback is appreciated as always.

Don't mean to stray too far from the topic, but couldn't one create a screen-sized GUI which just resembles a white rectangle, make it appear first, over everything else, and then fade that in. That should give a brightness control that works on everyone's system, in full and windowed mode. Shouldn't be too hard to implement either.

[TECHNICAL ESSAY #2: Pathfinding]

Thanks, your interest in this project is much appreciated!

TECHNICAL ESSAY #2: Pathfinding

This is the only problem I'm having right now, although I can calm you down by saying that it's not that bad - I have it working in an at least playable state right now already and I might be able to (it's gonna be hard though) solve this after all.
      Okay, so I have units and I can move them, but they won't move smartly. If I have one or more units in location A and want them to move to location B - where A and B are separated by a body of water or a steep slope or maybe even a building or another unit - they'll move to the edge and stop there. What they should do is what is called "pathfinding" - they should find a way around the obstacle and take that route. That's not always perfect either, as that path might lead right through an enemy army, outpost or base, but that's just how most recent real-time strategy games work.
      AGS has implemented pathfinding for characters nicely as you developers probably know, so no user has to really worry about the somewhat complicated world of A*-algorithms and the like. There are reasons, however, why I can not use these already implemented solutions: first of all the project doesn't use characters to display units (that would not be suited at all), it uses the dynamic sprites in order to theoretically display millions of them, second of all, pathfinding in real-time strategy games is different from pathfinding in adventure games.
      Let me clarify that last bit: while it's sufficient to use one algorithm in an adventure game where only very few characters are moved around simultaneously, almost all real-time strategy games use several methods (one for short distance, one that is somewhat less fine but faster for more units over longer distances, etc).
      Anyways, back to the project. Using the implemented pathfinding-routines in AGS won't be possible, if I'm not mistaken, so there are two options: implement your own or just make the user define the paths himself. The former is hard to do and will most likely slow the game down a whole lot (maybe it's worth a try if I have enough time, though - I could try to optimize this; for example when moving a lot of units, only give the first twenty units the order to move, so the game doesn't slow down as much, then give the next twenty the order one frame later etc.) and the latter is what I'm doing right now - it works, but it isn't not all that comfortable. I guess I'll see.

[TECHNICAL ESSAY#1: The Radar-Map]

Thanks for the thumps-up so far.

Okay, as promised, I want to keep you guys informed with brief essays or something - concerning the progress of development or technical details, just information that I deem interesting to share with you game-creators.


TECHNICAL ESSAY#1: The Radar-Map

This essay will explain the radar-map in the project. Now, you can already see it working in the screenshots in the first post, that means I've already implemented it and that's true (I didn't fake or photoshop it), but there's a slight problem with it: it tends to run slow.
      That's not something you wouldn't come across when you program a game like this, in fact, it'll always slow-down here and there. Too many time-expensive algorithms are necessary at every corner - all you need to do is find the bottle-necks and optimize the hell out of everything: try or invent tricks for improving performance - which might boil down to using smart math, like keeping away from too many trigonometry-functions (sin, cos, tan or similar) or too many square-roots, but sometimes more is necessary (some quick examples: frustum-culling, which means I don't draw any tiles that aren't on the screen at the moment, or just effective drawing, which, in my case, means I don't draw tiles that are in the fog anyways).
      But let's get back to the radar-map: it's easy to do a map like this with a simple background-color (roughly representing the terrain) and then to plot all units owned by the player green and all enemies red. But what I wanted was a map that actually showed you the terrain. As I put it in the text-part of my original announcement, I wanted the player to see all the objects and terrain-elements on the map (could be water, hills, cars, houses, slopes, canyons, you name it) that aren't traversable (at least by a unit on the ground, flying units are possible, not yet implemented though), so that he or she can plan the way he or she is going to take when commanding his or her units. This is not necessary (one could move the camera by placing the cursor close to the screen-edges or holding the cursor-keys down in order to find out a good way, but that wouldn't be very comfortable), but I wanted to take that problem from the player - plus, every recent real-time strategy title featured this. Additionally, if you imagine building a base in a safe corner, surrounded by steep slopes that are not traversable, you'll feel all safe and cozy - you'd probably want to see those barriers (and the respective openings that you'll have to block with your strongest units, because that's where you're gonna get attacked) on your map; how would it feel if the map didn't show that tactical situation?
      Okay, so I implemented this feature. And it ran slow, which is no wonder. The radar-map is 100x100 pixel sized. Every pixel on that map has to be checked against the "real" map, that means 10000 calls to a somewhat expensive function every frame. Runs at one or two fps, way, way too slow.
      Now, first I implemented a variable that determines the sharpness of the map. As you can see in the screen-shots, every pixel on the map-background that resembles terrain is actually 4x4 pixels big. This means four times less action and a much faster game. People with faster computers could up this variable to 1, which would give them pixel-clear radar-images, people with less computing power can change it to a higher value and run the game nicely, still.
      This works easily, but isn't beautiful, which is why I'm working on the best solution right now: since terrain is not destructible, I'll load the map into memory (array) and not recalculate it at all. I'll report back when I have that working...

Thanks a ton for the motivation so far!

I will be updating this thread with additional information, short essays or something regarding the development, new screenshots and maybe a tech-video showing progress so far.

[INTRODUCTION]

DO YOU REMEMBER A PROJECT CALLED...
[size=9]T[/size]ROOPERS?

INTRODUCTION

Three years ago I started my first project with AGS that wasn't a simple adventure - no, it was going to be a real-time strategy game. I didn't know all that much about programming back in the day, but the project got some pretty positive response (every now and then I still get a message about how it's doing), but in the end it came what had to come: I couldn't finish it.
      So much for the past - now I have decided to pick up the old horse again and take a good ride on her: it's back! But not only have I matured and learned in the meantime, AGS has done, too. Only with the more recent feature-additions of AGS 3.0 have I been able to build up the courage to give this another try. The feature list is similar, although I'm currently taking more influences from StarCraft as opposed to the heavy Command&Conquer-ness that was going on in the old version from 2005.
      I have a pretty decent working tech-demo pretty much done right now, which implements almost every single feature that is going to be in the game, so that's pretty good progress already done (I waited quite some time with this thread in order to keep the interested from having to wait for years - and to follow the forum-rules, of course). The majority of work now has to go into developing content (because if I learned one thing from my previous little doodad, Revelations, it's that a game can not appear well to a big audience if it's only technically impressive, it has to be a good game as well - well, duh, could've figured that one out myself in retrospect, but I guess I just didn't) - speaking of content, here is the list of features, which helps you to build your own picture up of how the game is going to look and feel like, it's followed by three screenshots to take the picture you just build up in your mind and rip it into pieces:


LIST OF FEATURES

• Build units and structures, select them, move them and let them attack - just like in most recent real-time strategy games (includes features like queuing build-commands for units, grouping units into teams using numbers 0-9, selecting units by drawing a rectangle and adding or removing single units by holding CTRL when clicking)...
  
• Use workers to gain resources to pay for new units, structures, upgrades and technology...
  
• Play against a computer-enemy that will hopefully act remotely intelligent...
  
• Get a quick overview of the battlefield on the radar-map, it not only shows you units and structures, but also the general shape of the terrain underneath them, so that you can successfully lead your troops through those narrow canyons...
  
• Different terrain-types, lots of different units and buildings (exact numbers are not clear yet)...
  
• Fog-of-War effect to make the game-play a lot more interesting...
  
• Music and sound-effects (format of music is not yet decided)...
  
• Editor to create own levels...
  

SCREENSHOTS (PARTIAL AND FULL SHOTS)

Newest:

Older:

Please keep in mind that nothing is final yet, that means the name might be different, there might be more than one resource, the graphics may change and - as you read above - the exact number of unit- and structure-types isn't yet fixed either. Please use this thread to comment and criticize constructively, tell me what you think, suggest units or technologies...

Here's my entry.

The series would open up with a short, funny opener - a scene in which the basic subject of the following, 20 minute episode is introduced (a technical problem with the police car, a new villain that needs to be defeated, family-problems, etc.). That opener would be anywhere in between 30 and 75 seconds long, then the intro-scene kicks in with the same scenes for every episode and my music. After that, the episode would really start.

For the video-material used in the intro-part to every episode, I could imagine a car chase, then in the more relaxed part of my song, maybe a scene with Lance out of his car, talking, then fighting. Just a montage of some stylized shots.

I think I got the 80s-vibe down pretty well.

Proximity: my game, Revelations, wasn't nominated in "best programming" either, although it was a very challenging project to realize with AGS - it's a jump'n'run styled action-title with levels, an editor, guards that patrol see you, etc. Nelly Cootalot, on the hand, was actually nominated for "best programming" although it clearly is a simple adventure game (and a great one at that, no offense intended, please), yet I do say, it couldn't have been exactly very challenging to program, after all it's exactly what AGS is made for.

It's not fair, but that's popular vote. You don't see me or everybody else here whining over these things. I wouldn't have mentioned the above if you hadn't given me a reason to.

There is a free tool called "bmp2avi" which will convert simple bmps into avis (well, who would've thought?) - google for it, it'll be A LOT less work.

Remember, even if your movie is only 30 seconds long, at 3 or 4 fps (which will look crappy as hell), that equals 90 - 120 single images. Getting ALL those into AGS, sorted, then displayed after each other is gonna be... well, I'll spare you the rough expressions, you get the idea.

Plus, with that tool, you're actually gonna get a real movie and not a *.exe.

OR, you could just obtain a real video-editing tool and record directly into that, then use all the professional ways of editing, cutting and producing video-material in there, I just don't know of any free ones out there that are worth the space they need on the hard-drive.

The roof may be a little low, but what's making this worse is that your camera is positioned and angled in a somewhat unaesthetic way. Move it lower and then try to angle it in a way that the image doesn't show a huge chunk of (boring) ceiling, but rather something close a 50/50 between floor and ceiling - in other words: if you imagine a crosshair right in the middle of your image (that would show where the camera is pointing at), at the moment, that crosshair is pointing somewhere at the ceiling, lower that.

Also, what are you using to render (looks somewhat like the editor from Unreal Tournament to me, with a direct screenshot from the tool)? Try to get the program you're using to enable anti-aliasing. That'd help a lot. If it can't, then get a program that allows better rendering (Blender, google for it).

About textures: try to scale them smaller. Especially both stone textures on the objects to the right are scaled way too big. Also, the wooden blocks on the ceiling. And the floor.