Skip to main content

Posts

Showing posts from April, 2016

Combat system, almost there

Started some basic combat system today, although the foundations were actuallyimplemented yesterday night. Now the player can fight with any NPC, until one of them falls dead. The required item/skill subsystem still isnt in place, mostly delayed by my research about the opetimal solution to store the item definitions. In my previous project, I used an XML file describing the item attributes, not only the RPG related (damage, etc), but also the visual ones, like where does it gets attached. It also had a property system to let objects have complex features, like providing a bonus to stats or skills, inflict/reduce different types of damage, etc. The drawback is that manually editing the XML is tedious and error prone. For this prototype I decided to try something else, like ScriptableObjects. But seems that ScriptableObject is too limited, because it would require a hughe class describing every possible item attribute for all item types. Also, for nested lists I think I will have to

Weekend progress

I had to make a short stop during weekend, because a light migraine that started annoying me on friday. I took that as a warning that I should do something else, and I decided to play a bit Age of Decadence, which, by the way, is not a fantasy game, but a Sci-fi one, cleverly masked. The post-apocalyptic world of AoD is the result of some old war that sent humanity to early medieval ages, although some old technology appears sometimes. Its a a ruthless game, with an incredibly high difficult level, not fun if you want to fight. In AoD, 1vs1 and 1vs2 fights are hard, 1vs3 is plain suicide. You wont be able to complete many quests, simply because you dont have the required skills, and sometimes you will have to change loyalties in order to advance. But, I also found some time to work on the project, and managed to implement a few changes. I had to force myself to halt development until I sit and properly design some way to store item information to avoid making the same mistakes I mad

And this is how it looks

My first project, an open source isometric (in 3D) RPG. Started about a year ago to learn Unity3d, previously made with Urho3D, with an even older attempt in Ogre3D. The current code has an almost working inventory system, with item equip, dynamic dialogs stored in XML, limited quest support, and the isometric camera system that took me some effort to implement in my first days with Uniy3d. The bugs: deferred rendering doesnt works with ortho projection (not my fault, but Unity's), idle to walk animation transition problem, lighting problems, and the combat system doesnt works yet. Almost there: drag and drop items and actions to quick slot bar, save and load, get items from containers and some widget to check ongoing quests. Get the code in Github and learn from it; some of the 3D assets can be downloaded from our OpenGameArt collection , and they are almost commercial quality! Im in dire need of hardware upgrades, so, any donations are welcome.

Inventory system

Im almost there! I have been working lately on inventory system, including the UI part, which required some revision of the actual foundations: the item system and how to use them. After a week of coding I figured out how to properly use UI events, with a few details to polish, but 80% is there. My advice: always use IPointerDown interface and similars. It will save you lot of time and clicks. You can even create the event trigger by code, no need to add it in editor. I used the old project to test and find design errors, to migrate the improved code to TPS prototype later. Yes, the next project, unless the team decides to go back to isometric view, will be a third person RPG. Im working (a lot!) to polish my coding skills and have transferred part of the design and writing tasks to a friend. Which means that I will only supervise the design and write part of the whole game story. There is a large obstacle in the road ahead: legal issues. I wont get into details here, but I can say

When zero budget really means zero... or less

My plans for 2016 included to get myself a new PSU (or a refurbished one) and reach the 8Gb, which seems to be the rule for game requirements lately. More RAM also helps heavy engines like Unreal, and maybe Unity3D would get some benefit from the extra memory. Then my phone broke and I had to take all the saved money, and a bit more, to get a new one. Took me a year and some good luck to save it. Now I found that I also need an Xbox controller. I already have a joystick (was a gift, didnt paid for it), which I promissed myself that I would never sell or trade, after selling my first one in a really low price. Of course, there is no way that I can buy the controller, same as there is no way I can have the PSU and RAM I need. At least, not until I sell my next book, probably delayed until 2018 (by the way, in case you are interested, my first novel is in Amazon , buy it and support a game developer!). The problem with zero budget development in Cuba is that it is really zero budget

Coding marathon

I have been coding for a week, like 3-4 hours every day, and also writing the game script, RPG system, and a few pages in my last novel. I have been trying code in the test project (the one I abandoned) and then doing thi things "right" in the prototype. Im pleased to say that I found how to properly implement drag and drop. The sample was there in my PC, waiting for me to look at it, and it was totally different to the approach I was taking. I was trying to avoid using IDragHandler and the other interfaces, because I thought it was harder, yet, I was wrong. Actually, it is easier. Of course, I needed some basic code I took from the sample, but from there I have learned to implement not only drag and drop, but also mouse button events, mouse enter/exit, etc. All this while keeping control of what GameObject generated the event, via BaseEventData and derived classes. Im working to implement drag and drop in the inventory for The Key of the World, which will take a few day

Working on new project

Well, sort of. I have started coding a prototype, but this time I focusing on laying some solid foundations before I got into other things like gameplay. For example, I took some time to study the correct structure of a project. Still I dont have idea about whats the optimal setup, but at least now the game instance class is a singleton. That allows to test each scene independently; in the previous project I had to start from the main menu to have access to all features. Using this singleton I always have at least some basic systems working. The second feature I started to develop from the beginning is the save/load system. Not very advanced, but I havent worked too much on this besides some limited position/rotation serialization. But the idea is that it evolves together with the project progression. I have been looking for directions to achieve optimal save and load speed/size, yet that info seems to be scarce. And third, but quite important: internationalization! For a reason I

The weapons of the future are not so... futuristic

Even when I have the freedom to decide what kind of weapons are we going to have in the future described in the story of our next game, I wanted to make a little research. After all, 40 years are not so many years, yet they are enough to ensure that technology will change, I thought. In a world were nanotechnology and graphene will rule, military tech has to be different. Well, seems that our future military tech is not going to be so future. Maybe it is classified information, but seems that besides using polymers for cases, we wont be seeing many changes in the next decades. Ammo technology havent been changing a lot lately. Even next gen stuff like flechettes and caseless ammunition is not so next gen, and has been extensively tested and its weaknesses proven, and discarded. Thats the reason why they are not ben used on the battlefield. The real next step: energy beam weapons, are still far from our reach. To achieve lethal results, the laser must focus the target for a long time