Game development and site

Hi!

Glad to hear from you and getting some feedback!

I have only one comment regarding question 6. I actually made some of the graphics for Time Breaker, the pad and the droid for example

programmers art

Feel free to contact us if you have any more questions or if you want some feedback yourself!

regards,
hObbE

[quote="hObbE"]Hi!

Glad to hear from you and getting some feedback!

I have only one comment regarding question 6. I actually made some of the graphics for Time Breaker, the pad and the droid for example

programmers art

Feel free to contact us if you have any more questions or if you want some feedback yourself!

regards,
hObbE[/quote]

I'd be happy to throw some pirate quest feedback at you if you want.

heh programmers art rules

I'd love if you wanted to give feedback on our upcoming demo. I believe you gave us some on the previous last year. I'll let you know when it's out. Or you'll probably see it on gamedev.se.

[quote="solidbenny"]
...how come you decided to leave alawar and distribute yourselves? don't they help to market the game? did you consider realarcade, reflexivearcade, popcap and so on..?
hey I'll buy pirate quest I like the price. just enough.
[/quote]

Well, I guess we wanted to do our own thing, we wanted to try an idea that you should be able to sell games that are not completed yet for a lower price... The customer gets free upgrades after that... So the we release games like Pirate Quest that are playable but not polished for a low price and work on the games we get payed for...

We have not really started to market this yet, Since we are new at selfpublishing it takes some time to get everything working.

[quote="solidbenny"]
ok. thought so. using the time breaker engine I assume? how do you find
the performance on drawing lots of tiles? its difficult to batch well. we've used almost every technique we know of to batch and cut polys to get decent framerates. wasn't like that in the directdraw times
[/quote]

TB was built on an "engine" that was very complex, so we learnt a lot from that and have built a much less complex engine for our new games...

As batching is concerned, I use the same texture for all tiles and build one mesh every frame with all tiles and draw it in one draw call...

[quote="solidbenny"]
how was the process of creating a company? I imagine it to be tons of work. it would be great if I could ask you for tips when we come that far..
[/quote]

I guess hObbE could answer this one better than me, since he is the one owning the company

[quote="solidbenny"]
Feel free to look at http://www.solidcore.se/roadclub for screenshots and
oh and do you know how Gridur would feel about making a few character portraits for our game? I know he's busy but we really need help creating a couple more (2-3) for the game to have enough.[/quote]

The screenshot looks very nice, I want to play now!

Do not steal Gridur

Daniel

[quote="dntoll"][quote="solidbenny"]
...how come you decided to leave alawar and distribute yourselves? don't they help to market the game? did you consider realarcade, reflexivearcade, popcap and so on..?
hey I'll buy pirate quest I like the price. just enough.
[/quote]

Well, I guess we wanted to do our own thing, we wanted to try an idea that you should be able to sell games that are not completed yet for a lower price... The customer gets free upgrades after that... So the we release games like Pirate Quest that are playable but not polished for a low price and work on the games we get payed for...

We have not really started to market this yet, Since we are new at selfpublishing it takes some time to get everything working.
[/quote]

ah good idea. so pirate quest isn't 100% yet? the price will be higher if you buy when it IS 100% I assume?

I did notice a few things that could be nicer but if it isn't ready I understand.

[quote="dntoll"][quote="solidbenny"]
ok. thought so. using the time breaker engine I assume? how do you find
the performance on drawing lots of tiles? its difficult to batch well. we've used almost every technique we know of to batch and cut polys to get decent framerates. wasn't like that in the directdraw times
[/quote]

TB was built on an "engine" that was very complex, so we learnt a lot from that and have built a much less complex engine for our new games...

As batching is concerned, I use the same texture for all tiles and build one mesh every frame with all tiles and draw it in one draw call...
[/quote]

Yeah, we'll do the same thing with version 2 of our engine. Take everything you've learnt and build from scratch using the old code where possible.

This is interesting. as far as we've understood you can only have one set of texture coordinates on each vertex which makes it impossible for two polygons using the same vertex to have different coordinates and therefore can't map different parts of the texture. we only have one texture but batch and draw all polygons using the same part of the texture after each other... I think we've misunderstood something here that slows us down considerably. I would be great if you could shed some light on this

To sum up, if we have a situation with two quads side-by-side made by 6 vertices, the two in the middle would have one texture coordinate each. How can the two quads show two completely different parts of the texture if that's the case?

[quote="dntoll"]
[quote="solidbenny"]
how was the process of creating a company? I imagine it to be tons of work. it would be great if I could ask you for tips when we come that far..
[/quote]

I guess hObbE could answer this one better than me, since he is the one owning the company
[/quote]

okay I'll wait for his answer then

[quote="dntoll"]
[quote="solidbenny"]
Feel free to look at http://www.solidcore.se/roadclub for screenshots and
oh and do you know how Gridur would feel about making a few character portraits for our game? I know he's busy but we really need help creating a couple more (2-3) for the game to have enough.[/quote]

The screenshot looks very nice, I want to play now!

Do not steal Gridur
[/quote]

heh nice to hear. we'll do our best to complete it soon.

hey I'm just boooorrowing him a little Seriously though, I'd only ask for as little as I can get. I will of course not take time from your projects. It's up to him and you to decide if it's okay. If not, I understand.

ah okay. that makes sense. it's a balance there I guess. we don't have so many different "tiles" since we're drawing like 3-4 terrain types. we use trianglelists for scenery objects.

so basically you created an "enskild firma" or do you all have a "handelsbolag". heh why are we still writing english? anyway I assume you can't just divide up the earnings however you like if everyone isn't part of the company somehow.

so each of you sometimes do stuff by yourselves through spell of play? and all help each other out more than working together? thats a very good idea. I assume you all have full-time jobs so you survive

do you feel like alawar did enough for the big share they took or do you think you can spread the word by yourself and earn more in the end?

very good idea to let people support you from the beginning when it is playable and pay less the earlier you dare to spend the money do you plan to just release your own stuff over the hub or do you think it can be something that many developers can share?

alright I'll write down feedback while I'm playing. I bought pirate quest today painless procedure. good job. there was a spelling error in the product information email and it was a bit short and boring but I suppose it was a quick thing

I gotta say I really like the exploration part. It really makes the game worth playing. I usually don't look twice at match-games or many casuals at all. oh and music and sound is good. the music sequences are a bit short though.

otherwise the only things I've found so far is that the main menu background is a little sketchy, the match-3 boards could use some more objects around them to liven them up a little. just the terrain tiles look a little boring. I can see the issue of cluttering up the screen when there's already lots of objects on the actual gaming board but I think something can be added successfully without compromising cleanness.

also some inconsistencies and alignment issues on buttons but I'm sure you know it all already.

hmm okay, I suppose you could change the vertexformat. At the expense of memory of course. and it gets a whole lot more complicated. would you use several texture stages or would each triangle somehow know which texturecoordinate to use in which case... well I don't think we need to go into it. it works fine as it is.

regards,
Benny

Hmm did I never reply to this. I should have called myself Chaosmind.

Well, okay I guess it works if the money goes directly to hardware and software and not to individual persons.

I got the impression Handelsbolag was the best alternative for 2-4 people but I guess AB is the way to go if you're serious. The problem is the 100.000.

Being unemployed for a while and having lots of time and then working for 5 months I found it very hard to work on the game while having a fulltime job. How do you keep the motivation and energy up to both work fulltime, maybe overtime and get home and code even more? Maybe I'm just too bored of Roadclub because of the last phase to do them both and a new project would give me more energy.

Very good points regarding the publisher. We'll probably do it that way with Roadclub and see what happens and take a new decision next time.

Having deadlines definitely helps if you want to get it done fast. We probably want to take some time to design the engine from scratch taking everything we learnt the last decennium into account before the next game though.

I'll play some more PQ soon. See if something else comes up. Are you working on PQ at the moment?

Well, back to work on the demo for me

Yo!

Yes motivation is a big factor. I can be very hard to feel motivated to work more after a whole days worth of work. I agree with toll that the best motivation is feedback and getting your product out there.

Getting real feedback also makes you focus on what is important to improve in the game. Often you spend countless hours on some motivation draining feature that no real player think is important. So releasing your game from day one is paramount!

Also releasing your game will help you find bugs and problems early, which is a good thing. Nothing is more motivation draining than working for a year+ and then the game does not work on 50% of the PCs.

During the development of Time Breaker we had a release cyckle of two weeks. That is every two weeks we released the game, collected feedback and planned what to work on the next two weeks. This methodology of working is called "iterative software development" and is one of the better ways of developing software in general and games in particular imho. Popular processes that use this method is (Rational) Unified Process and eXtreme Programming. There is much to be said about these processes but the core is that you don't know for sure what to do until you have some real end user feedback, and the only way of getting that is by releasing your product.

As someone said "for a software to be in development is a very unnatural state".

Using the Hub as release platform we are now trying to be even more iterative and always letting the end user get the latest version without the need to download or install the game "manually".

My advice for you is to release the game now, even if it looks/feels/plays like crap Be brave!

/hObbE

Yes, getting a good amount of feedback is really hard. Early versions of time breaker was mostly friends and colleagues that where "encouraged" read forced to play the game. Later on the regular "community" of testers grew and our publisher always took the time to send us good feedback (that is one of the main advantages of having a publisher)

We hope that the Hub will make it somewhat easier for the end user, but it is still a big step for a person to engage themselves and submit some feedback. Right now you pretty much need to register a user in the forums and write something. This is a pretty "scary" thing to do.

We will probably add some feedback feature in Hub to facilitate this process, since the Hub can know what game the user has played the Hub can ask for feedback after a playing session.

Another interesting thing that I personally think is the future of game development is instrumenting. That is collecting measurements from withing the game to pin point what the good and bad thing are. Valve is already doing this a lot. Beeing able to collect massive amounts of quantitative feedback will open a lot of doors!

regards,
hObbE

Yes what to measure during instrumenting is the big question and the biggest challenge for game developers. I think that having quantitative data is paramount to large scale sucess. However, qualitative methods, like watching people play, focus groups and listening to feedback is certainly important.

I actually feel really inspired to add some simple feedback functionality to the Hub now

/hObbE

Yo!

The Hub is updated with a simple feedback feature.

The next time you start The Hub you should get a File menu with a Feedback option.

/hObbE

Hi guys, I just found this thread today, it was a great read

About batching in D3D; AstroCreeps is now D3D9 instead of DirectDraw3 as of a few versions ago. I'm currently using fixed function / DrawPrimitiveUP with triangle lists, and a single texture like Daniel has described. I haven't seen any real performance reason to use vertexbuffers or even indexbuffers (could save some vertices by using DrawIndexedPrimitiveUP of couse). I don't use any dynamic allocation, I've just self-imposed a max triangle / quad count and have a big static array of vertices.

I have found that it makes logical sense to create a Texture class that exposes all the "blit" functions. This class simply wraps a D3D texture interface along with my "vertex array", and handles drawing itself. This is because I'm of course sorting by texture.

I've been playing around with a method of supporting interleaved "blend modes" in my calling code, meaning that I can interleave draw calls to the Texture object that are alphatested vs add-blended in any order. This is mainly because that is how my old DDraw code worked (all 16 bit software buffers and a single lock and transfer to video memory at the end of each frame). This has posed a challenge, but it boils down to flushing the vertices with a DrawPrimitiveUP call each time the "blend mode" changes. This is managed by the Texture object storing the last call's "blend mode", and drawing the cached quads each time a conflicting call comes in.

AstroCreeps thus uses between 2 and 5 draw calls, depending on what is on the screen, and the game itself doesn't need to do any "blend mode scene management". I'm pretty happy with the way this works out, but it probably won't work with multiple textures without a more elaborate scheme, and in that case it might be better to expose the entire internal logic to the game's View anyway. Engines suck

And one last thing, I use nVidias FX composer to "compile test" my .fx shaders. That is I use it to make sure that the shader will compile to the specified vs or ps target. This is nice, because then your program doesn't have to fail at startup due to some crappy syntax error in your .fx file.

Another thing that I've been doing is using a single .fx file for all my different logical shaders, and using techniques as a "shader selector" instead of a profile fallback. This allows me to re-use lots of the global application to shader communication (global variables etc), and share vertex shaders and pixel shaders between logical "shaders" i.e. techniques.

[code:1]
void Texture::Blit(const bool anAddFlag,
const float aX, const float aY,
const float aWidth, const float aHeight,
const float aSrcX, const float aSrcY,
const float aRotation)
{
Flush(anAddFlag);
myRects.Add(aX, aY, aWidth, aHeight, CalcUV(aSrcX, aSrcY), CalcUV(aWidth, aHeight), aRotation);
}
[/code:1]

This is the basic "blit" implementation, which flushes with the call's add flag (I support alpha test blending, i.e. color key, and additive blending), and then adds a rect to the vertex buffer. The adding of rects fails silently if there are too many, but you could easly put an assert in there and size your vertex buffers through trial and error.

[code:1]
void Rects::Add(const float aX, const float aY,
const float aWidth, const float aHeight,
const Core::Vector2f& uv, const Core::Vector2f& uvsize,
const float aRotation)
{
if(myCount < MAX)
{
const unsigned short BV(myCount * 4);
vertex* v(myVertices + BV);
unsigned short* i(myIndices + myCount * 6);

if(aRotation != 0.f)
{
unsigned char i;

v[0].Set(aWidth * -0.5f, aHeight * 0.5f, uv.x, uv.y + uvsize.y);
v[1].Set(aWidth * -0.5f, aHeight * -0.5f, uv.x, uv.y);
v[2].Set(aWidth * 0.5f, aHeight * -0.5f, uv.x + uvsize.x, uv.y);
v[3].Set(aWidth * 0.5f, aHeight * 0.5f, uv.x + uvsize.x, uv.y + uvsize.y);

for(i = 0; i < 4; i++)
{
v[i].pos.RotateAroundZ(aRotation);
v[i].pos.x += aX;
v[i].pos.y += aY;
}
}
else
{
v[0].Set(aX, aY + aHeight, uv.x, uv.y + uvsize.y);
v[1].Set(aX, aY, uv.x, uv.y);
v[2].Set(aX + aWidth, aY, uv.x + uvsize.x, uv.y);
v[3].Set(aX + aWidth, aY + aHeight, uv.x + uvsize.x, uv.y + uvsize.y);
}

i[0] = BV + 0;
i[1] = BV + 1;
i[2] = BV + 2;
i[3] = BV + 0;
i[4] = BV + 2;
i[5] = BV + 3;

myCount++;
}
}
[/code:1]

This is the add stuff for rects / quads. Apparently I was lying earlier, I do use indices, meaning DrawIndexedPrimitiveUP()

[code:1]
void Texture::Flush(const bool anAddFlag)
{
if(anAddFlag != myAddFlag && (myRects.myCount || myLines.myCount || myTris.myCount))
Flush();

myAddFlag = anAddFlag;
}
[/code:1]

As you can see, the cached add state (myAddFlag) is checked, and if the incoming call differs and there is something to draw Flush() is called, which does the actual DrawPrimitiveUP stuff and resets the vertex buffers in myRects, myLines, and myTris. Finally, I cache the current add state. Lines and Tris work very much like the Rects stuff, adding in a similar fashion.

[code:1]
void Texture::Flush()
{
if(myDevice)
{
HRESULT hr;

if(myAddFlag)
{
V(myDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE));
}
else
{
V(myDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, FALSE));
}

V(myDevice->SetFVF(D3DFVF_XYZRHW | D3DFVF_TEX1));
V(myDevice->SetTexture(0, myTexture));
myRects.Draw(myDevice);

V(myDevice->SetFVF(D3DFVF_XYZRHW | D3DFVF_DIFFUSE));
V(myDevice->SetTexture(0, NULL));
myLines.Draw(myDevice);
myTris.Draw(myDevice);
}
else
{
myRects.myCount = 0;
myLines.myCount = 0;
myTris.myCount = 0;
}
}
[/code:1]

This is the actual drawing. Note the vertex formats, myRects are textured, myLines and myTris are just diffuse colored.

One important thing is that all of the drawing in AstroCreeps must occur between BeginScene and EndScene calls. This isn't really consistent, as the interface to Texture doesn't imply this, but is is an artifact of the current flushing scheme. This isn't really a problem for me, I have control of where the drawing occurs, but it is worth mentioning. Also, at the end of the drawing a final call to Flush() needs to be made on the Texture, to flush all the stuff that has been cached in the final batch.

[code:1]
void ViewManager::Draw(IDirect3DDevice9* aDevice)
{
HRESULT hr;

// Clear the render target and the zbuffer
V(aDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, myView == &myPlay ? 0xff000000 : 0xffff00ff, 1.f, 0));

// Render the scene
if(SUCCEEDED(aDevice->BeginScene()))
{
myCore.myGui.myMouseInsideFlag = false;
myView->Draw();
myCore.myGfx.Flush();
Rects::Debug();
V(aDevice->EndScene());
}
}
[/code:1]

This is the drawing stuff, as sort of explained above. All the calls to Texture are done in myView->Draw(), and myCore.myGfx.Flush() is the final flush call as explained above.

Going along with the new design I proposed in the last post, even more things could be improved.

The interface for Texture::Flush() would be changed as to require a IDirect3DDevice9 pointer. This gets rid of the cached pointer inside Texture (which I think really smells), and sort of implies that the Flush() call is part of rendering and as such belongs within a BeginScene() / EndScene() block.

Of course this would change IView::Draw() to require an IDirect3DDevice9 pointer, so it can be passed to Texture::Flush(), but that is also good, as then you can't call Draw() without being on a call stack where you have a device pointer.

It should be noted that I try to avoid caches like the plague, and using DXUT I tend to use the function arguments to OnFrameRender() instead of the very evil global function DXUTGetD3DDevice().

...which brings us back to the messiness of having to batch / cache stuff at all, but that's just a fact of life with D3D. Oh well, I guess that in my old DirectDraw code, my whole software bitmap implementation in itself is just one huge cache to avoid having to deal with draw call limitations

At SpellOfPlay we have many times ranted about the power of immediate mode interfaces and the inherent evilness of caches in general. I like the irony of trumping my own design by explaining it to someone else